Fly-K ist ein A320-Simulator für Windows und wird in Kombination mit gängigen Flugsimulatoren betrieben. Ein zentraler Core rechnet die Flugzeugsysteme. Displays, Panels und Hardware sind Clients und rechnen nichts Eigenes. So gibt es genau eine Wahrheit im System, ob auf einem PC oder verteilt auf so viele Rechner, wie dein Cockpit braucht. Entwickelt von Piloten, die die A320 fliegen.
Fly-K ist ein A320-Simulator für Homecockpits unter Windows und wird in Kombination mit gängigen Flugsimulatoren betrieben. Als Referenz dient uns die A320-214 mit CFM56-5B.
Gebaut ist er um einen zentralen Core, der die Flugzeugsysteme rechnet. Alles, was du im Cockpit siehst und anfasst, ist ein Client und rechnet nichts Eigenes. So gibt es genau eine Wahrheit im System, ob alles auf einem PC läuft oder über dein Heimnetz verteilt auf so vielen Rechnern, wie dein Cockpit braucht.
Was das bringt, merkst du, sobald etwas ausfällt. Ein Fehler wirkt auf die Komponente, und das ECAM leitet seine Meldung aus dem tatsächlichen Zustand ab. Fest verdrahtete Meldungslisten, die bei ungewöhnlichen Kombinationen auseinanderfallen, gibt es nicht. Heute kannst du 56 einzelne Komponentenfehler auslösen und zusehen, wie sich die Folgen durch die Systeme ziehen und auf den Displays ankommen, vom PFD bis zur letzten der 13 Systemseiten des SD.
Fly-K ist noch nicht veröffentlicht.
Was ein PFD ist, musst du nicht erklärt bekommen. Interessanter ist, woher seine Werte kommen: Jedes Display auf dieser Seite ist ein Client, der nichts selbst rechnet. Es zeichnet, was der Core in diesem Moment als Zustand des Flugzeugs führt.
PFD und ND gibt es für beide Plätze, CAPT und FO, und alle vier hängen live am Core. Jedes Instrument hängt außerdem an seinem elektrischen Bus: Ohne Versorgung bleibt die Anzeige schwarz, nach längerer Unterbrechung läuft erst der Selbsttest. Das ist nicht nachgestellt, es folgt der Stromversorgung.
Das PFD mit Beispielwerten eines ILS-Anflugs: FMA, Geschwindigkeits- und Höhenband, Ablagen für Landekurs und Gleitweg, darunter die Funkhöhe.
Das ND im ARC-Modus am Boden: Kursrose, Entfernungsringe und das Flugzeugsymbol. Eine Route aus der MCDU erscheint hier maßstäblich.
Beide Triebwerke laufen: N1, EGT, N2 und Kraftstofffluss, darunter die Kraftstoffmenge an Bord. Unten rechts stehen die Memos zu Parkbremse und TCAS.
Oben das E/WD, unten das SD mit 13 Systemseiten, dazu das ECAM-Bedienpanel. Die Meldungen sind nirgends als fertige Liste hinterlegt. Das ECAM leitet sie aus dem Zustand ab, den der Core rechnet. Deshalb passen E/WD, Systemseite und STATUS auch dann zusammen, wenn mehrere Fehler ungewöhnlich zusammenfallen.
Verbrauchter Kraftstoff, Ölmenge, Öldruck, Öltemperatur und Vibrationen für beide Triebwerke.
Bleed und Packs rechnet der Core mit, auch klemmende Bleed-Ventile gehören zu den Fehlern. Die Aufnahme dieser Seite reichen wir nach.
Kabinenhöhe, Differenzdruck und Steigrate der Kabine, darunter Packs, Ventilation und das Auslassventil.
Beide Generatoren am Netz, Bodenstrom steht bereit. Fällt eine Quelle weg, siehst du hier, wer übernimmt.
Grün, Blau und Gelb mit je 3000 PSI. Die PTU in der Mitte ist mehr als eine Linie: Ihre Logik und die Interlocks laufen im Core.
Tankinhalte, Pumpen und die Gesamtmenge an Bord. Die Zahlen gehen auf, weil der Core eine Tankbilanz führt.
Die APU läuft und meldet AVAIL. Ihr Generator und ihre Zapfluft stehen bereit, die Lufteinlassklappe ist offen.
Die Temperaturzonen für Cockpit und Kabine mit den Temperaturen der einströmenden Luft.
Türen und Frachtklappen in der Draufsicht, daneben der Sauerstoffdruck fürs Cockpit.
Fahrwerk, Bremsen und Bremstemperaturen aller vier Haupträder.
Alle Steuerflächen mit den Rechnern dahinter. ELAC, SEC und FAC laufen nach dem Einschalten getrennt hoch.
Ohne Störung steht hier NORMAL. Nach einem Fehler listet die Seite getrennt auf, was nicht mehr zur Verfügung steht.
Die Reiseflugseite fasst Triebwerke und Kabine zusammen: Verbrauch, Öl, Vibrationen, Kabinenhöhe und Zonentemperaturen.
Die Seite A/C STATUS der MCDU: Referenzflugzeug A320-214 mit CFM56-5B, darunter die aktive Navigationsdatenbank und die eigenen Wegpunkte.
Das Standby-Instrument mit Fluglage, Geschwindigkeit, Höhe und Druckeinstellung. Auch dieses Display hängt an seinem Bus.
MCDU 1 und 2 und das Standby-Instrument gehören ebenso dazu. Wer keine Hardware hat, bedient alles am Bildschirm: Das Overhead ist bedienbar, insgesamt sind es 184 Controls.
Die Aufnahmen dieser Galerie stammen aus der Layoutvorschau von Fly-K und zeigen Beispielwerte. Die Bilder im Abschnitt Systeme kommen aus der laufenden Simulation.
In Fly-K gibt es genau eine Wahrheit: Ein zentraler Core rechnet die Flugzeugsysteme, Displays und Panels rechnen nichts Eigenes. Ein Fehler wirkt auf die Komponente, und das ECAM leitet seine Meldung aus dem tatsächlichen Zustand ab. Fest verdrahtete Meldungslisten, die bei ungewöhnlichen Kombinationen auseinanderfallen, gibt es nicht.
Im Normalbetrieb versorgt jeder Triebwerksgenerator seine Seite des Bordnetzes. Lass GEN 1 ausfallen, verfolge, was daraus folgt, und behebe die Störung danach selbst am Panel.
Normalbetrieb
Der Fehler wirkt auf den Generator selbst: GEN 1 liefert keinen Strom mehr. Im Overhead leuchtet FAULT im Taster.
AC BUS 1 bleibt nicht stromlos: Der Bus Tie schließt von selbst, und GEN 2 trägt jetzt beide Seiten.
Master Caution leuchtet, und auf dem E/WD steht in Amber ELEC GEN 1 FAULT, dazu die Schritte, die jetzt dran sind. Die Meldung ist nicht fest mit dem Fehler verdrahtet, das ECAM leitet sie aus dem Zustand des Bordnetzes ab.
Auf dem SD zeigt die ELEC-Seite den neuen Zustand: GEN 1 in Amber, beide Busse hängen an GEN 2.
Ein Klick auf MASTER CAUT am Panel: Das Leuchtfeld erlischt, die Meldung auf dem E/WD bleibt stehen.
Das E/WD nennt den Schritt: GEN 1 aus, dann wieder ein. Beim ersten Druck auf den Taster erlischt FAULT, und OFF leuchtet. Beim zweiten geht GEN 1 wieder ans Netz: Der Bus Tie öffnet, jeder Generator versorgt wieder seine Seite, und die Meldung verschwindet.
Nichts davon ist als fertige Meldung hinterlegt. Der Core rechnet das Bordnetz durch, und jeder weitere Schalter verändert das Bild wieder.
Du stehst am Boden und schaltest eine der beiden Batterien ein. Selbst die OFF-Leuchtfelder der Batterien haben ihre eigenen Versorgungspfade, und der Core rechnet durch, woher jedes Feld seinen Strom bekommt.
Am Boden kann deshalb die eingeschaltete Batterie das OFF-Feld der anderen versorgen. Das Ergebnis siehst du im Overhead. Solche Details entstehen, wenn man die Versorgung tatsächlich durchrechnet.
Die drei ADIRUs richten sich aus, und wie lange das dauert, hängt vom Breitengrad ab. Der Core rechnet die Ausrichtung und kennt die Restzeit. Du liest sie direkt im ECAM ab: erst IRS IN ALIGN > 7 MN, dann in Minutenstufen. Vor dem Triebwerksstart steht die Zeile in Grün, danach in Amber.
Auf dem PFD ist während der Ausrichtung die Fluglage schon da, der Kurs fehlt noch. Ist sie abgeschlossen, steht auch das Kursband. Für Ungeduldige gibt es Quick Align als Simulatorhilfe.
Jedes Instrument hängt an seinem elektrischen Bus. Verliert der Bus seine Versorgung, bleibt die Anzeige schwarz. Kommt der Strom nach längerer Unterbrechung zurück, läuft ein Selbsttest. Das ist nicht nachgestellt, sondern folgt der Stromversorgung.
Die Elektrik ist mit GEN 1/2, Bus Tie, AC- und DC-Bussen, Batterien, Notstrom und Bodenstrom dabei. Dazu kommen die Hydraulik mit Interlocks und PTU, der Kraftstoff mit Tankbilanz, Bleed und Packs, die Temperaturzonen, Türen und Bremsen, der Flugflächen-Bodentest sowie die APU- und Triebwerksversorgung. Zu den ADIRS gehören drei ADIRUs mit breitengradabhängiger Ausrichtung.
Es gibt 56 einzelne Komponentenfehler, unter anderem Flameout, Pumpenausfall, Lecks und klemmende Bleed-Ventile. Jeder wirkt auf die Komponente, und das ECAM leitet seine Meldung aus dem tatsächlichen Zustand ab.
All das hängt am selben Core. Was noch entsteht, steht in der Roadmap.
ECAM-Verfahren laufen mit STATUS, getrennten INOP-Einträgen, CANCELLED CAUTION und CLR-Seitenwechsel.
Die Aufnahmen zeigen das E/WD mit F/CTL ELAC 2 FAULT und den Schritten dazu, daneben die STATUS-Seite.
Die MCDU hat INIT, IRS INIT, Wegpunkte, F-PLN und temporäre laterale Revisionen mit INSERT und ERASE. Die Route erscheint maßstäblich auf dem ND.
In den Aufnahmen steht in der MCDU ein F-PLN von EDDK über zwei Wegpunkte nach EDDL, und das ND zeigt dieselbe Route im PLAN-Modus.
Alle Aufnahmen in diesem Abschnitt stammen aus der laufenden Simulation.
Du hast abends eine halbe Stunde und weißt, was du üben willst. Dann suchst du dir einen von vier Ausgangszuständen aus: Cold & Dark, Bodenstrom, APU bereit oder Triebwerke im Leerlauf. Ein Klick genügt, und alle Systeme und alle Fehler sind zurückgesetzt, in allen geöffneten Fenstern gleichzeitig. Geht ein Versuch daneben, stehst du mit demselben Klick wieder am Anfang.
Für den Hochlauf gibt es drei Zeitprofile: Referenz, Variabel und Training. ELAC, SEC und FAC laufen getrennt hoch, mit variablen Zeiten. Derselbe Einschaltablauf läuft also nicht jedes Mal exakt gleich ab, genau wie im echten Flugzeug.
Wiederholbar bleibt es trotzdem. Ein Seed legt den Zufall fest: Derselbe Seed erzeugt denselben Ablauf, und du kannst eine Situation exakt noch einmal durchgehen, so oft, bis sie sitzt. Außerdem zeichnet Fly-K jeden Simulationsschritt auf, inklusive aller Bedienungen. Ein Durchlauf lässt sich deterministisch wiedergeben: derselbe Ablauf, mit jeder Bedienung an derselben Stelle.
Die F/CTL-Seite mit ELAC 1 und 2 und SEC 1 bis 3. Nach dem Einschalten laufen die Rechner getrennt hoch, mit variablen Zeiten.
Bei Fly-K rechnet nur einer: der Core. Displays, Panels und Hardware sind Clients und rechnen nichts Eigenes. So gibt es genau eine Wahrheit im System, ob alles auf einem PC läuft oder verteilt auf so vielen Rechnern, wie dein Cockpit braucht.
Alles auf einem Rechner: Core und Clients laufen nebeneinander.
Drei Rechner: einer für den Core, einer für die Displays, einer für MCDU, Pedestal und Overhead.
Sechs Rechner: der Core und jeder Client auf einem eigenen PC.
Das Schema zeigt den Aufbau von Fly-K. Der Core ist der Host: Er rechnet die Flugzeugsysteme und ist mit fünf Clients verbunden.
Die Clients in der Beispiel-Aufteilung: Captain-Displays (PFD und ND), ECAM (E/WD und SD), F/O-Displays (ND und PFD), MCDU und Pedestal, Overhead.
Der Core schickt den Systemzustand an alle Clients. Wo bedient wird, im Beispiel an MCDU, Pedestal und Overhead, gehen die Eingaben an den Core zurück.
Core und Clients laufen wahlweise zusammen auf einem PC oder verteilt auf mehrere Windows-PCs im Heimnetz.
Der Core ist der Host. Er rechnet die Flugzeugsysteme und hält den einen Zustand, der gilt. Ein Client stellt dar, was der Core vorgibt, ob PFD, ECAM-Displays, MCDU oder Overhead. Was du bedienst, geht an den Core, und nur dort wird gerechnet. Deshalb zeigen alle Displays jederzeit denselben Zustand, egal, auf welchem Rechner sie laufen.
Für die Einrichtung gibt es einen Windows-Installer mit zwei Rollen. Als Core-PC übernimmt ein Rechner Simulation, Anzeigen und Hardware, als Client-PC Anzeigen, Panels und Hardware. Ein Client-PC speichert die Adresse des Hauptrechners. Er merkt sich also, wo der Core läuft: kein Kommandozeilengefummel bei jedem Start. Host und Clients sprechen über dein Heimnetz.
Fly-K wird in Kombination mit gängigen Flugsimulatoren betrieben. Die Unterstützung dafür ist geplant und steht auf der Roadmap.
Deine Hardware-Panels bindest du über SIOC an, die Verbindung läuft über UDP. Für den Core ist Hardware ein Client wie jedes Display: Was du am Panel schaltest, geht an den Core, und was dein Panel anzeigt, kommt von dort. Fly-K liest digitale und analoge Eingänge und steuert Lampen- und Ziffernausgänge. Die Lampe an deinem Panel und die Anzeige auf dem Display folgen demselben Zustand, weil beide am selben Core hängen.
Die Anbindung richtest du in frei konfigurierbaren Profilen ein. Ein Profil speicherst du und lädst es wieder, und auf Wunsch startet Fly-K gleich mit dem Profil, das du ausgewählt hast. Weitere Hardware-Anbindungen über SIOC hinaus kommen und stehen auf der Roadmap.
Die Instructor Station kommt. Sie macht aus dem Simulator einen Trainingsplatz: eine eigene Oberfläche auf einem zweiten Rechner im Netz, während im Cockpit geflogen wird.
Zu zweit sitzt ein Ausbilder oder ein Freund am zweiten Rechner. Er bereitet das Szenario vor, stellt dir die Fehler und hat Pause, Freeze und Reposition in der Hand. Hinterher geht ihr den Ablauf im Replay gemeinsam durch.
Allein stellst du dir den Fehler selbst. Du knüpfst ihn an eine Zeit oder einen Flugzustand, fliegst los und hast ihn vergessen, bis er auftritt. Der Fehler kommt dann, wenn er kommen soll.
Szenarien lassen sich vorbereiten und wiederverwenden. Seeds steuern den Zufall: reproduzierbar, wenn du etwas gezielt üben willst, und überraschend, wenn nicht. Die Grundlage dafür steckt schon im Core, siehe Einschalten und üben.
Auf die Warteliste setzenDie Unterstützung gängiger Flugsimulatoren ist geplant. Fly-K übernimmt dann die Systeme und Anzeigen, während der Simulator fliegt. Auch Flugmodell und Autoflight kommen, also Autopilot, Flight Director und Schubautomatik.
Die Instructor Station wird aus dem Simulator einen Trainingsplatz machen: eine eigene Oberfläche auf einem zweiten Rechner im Netz, mit vorbereiteten Szenarien, mit Fehlern, die an Zeit oder Flugzustand geknüpft sind, und mit dem Replay der Aufzeichnung.
Heute arbeitet die MCDU mit Wegpunkten, F-PLN und temporären lateralen Revisionen, und die Route erscheint maßstäblich auf dem ND. Bei der Hardware ist SIOC heute angebunden, über UDP und mit frei konfigurierbaren Profilen. Weitere Hardware-Anbindungen kommen dazu.
Das alles ist in Arbeit oder geplant. Termine und eine Reihenfolge nennen wir erst, wenn sie feststehen. Die Roadmap zeigt dir, worauf du wartest: Trag dich in die Warteliste ein, und wir schreiben dir, sobald es losgeht. Vorher melden wir uns nur, wenn es etwas zu berichten gibt.
Fly-K wird von A320-Piloten entwickelt. Ein Handbuch beschreibt, wie ein System aufgebaut ist. Wie es sich im Betrieb verhält, weiß man erst, wenn man das Muster fliegt.
Im Handbuch steht, welche Schritte ein Verfahren hat. Im Cockpit lernt man, worauf man zwischen zwei Schritten wartet und was man dabei prüft. Ein Flow geht nur auf, wenn jedes System im richtigen Moment antwortet, und ob etwas sofort reagiert oder erst nach einer Weile, entscheidet darüber, ob es sich echt anfühlt.
Deshalb laufen in Fly-K ELAC, SEC und FAC getrennt hoch, mit Zeiten, die nicht jedes Mal gleich sind. Deshalb bleibt ein Display ohne Strom schwarz und macht nach längerer Unterbrechung erst seinen Selbsttest. Und deshalb hängt die Dauer der IRS-Ausrichtung vom Breitengrad ab.
Für dich heißt das: Du gehst einen Ablauf so durch, wie du ihn kennst, und dein Cockpit antwortet so, wie du es vom Original erwartest.
Fly-K kommt von einem kleinen Team, nicht aus einem Konzern. Wer uns schreibt, erreicht die Leute, die entwickeln.
Meistens beginnt es mit einer kurzen Mail: ein Wunsch, ein fehlendes Detail oder etwas, das sich im Original anders verhält. Wir gleichen den Hinweis mit dem ab, was wir aus dem echten Cockpit kennen, und sagen dir ehrlich, was daraus wird. Was Fly-K besser macht, bauen wir ein. Danach probierst du es in deinem Cockpit aus und meldest dich, wenn noch etwas nicht passt.
Wünsche nehmen wir jetzt schon an. Schreib uns an mail@fly-k.com oder setz dich auf die Warteliste, dann erfährst du zuerst, wann es losgeht.
Du brauchst einen Windows-PC. Fly-K läuft auf einem einzelnen Rechner oder verteilt auf so viele, wie dein Cockpit braucht, und auf jedem davon läuft Windows. Bei der Installation wählst du für jeden Rechner die Rolle: Core-PC oder Client-PC. Ein Netzwerk brauchst du nur, wenn du verteilst. Dann sprechen die Rechner über dein Heimnetz miteinander.
Fly-K wird in Kombination mit gängigen Flugsimulatoren betrieben. Die Unterstützung dafür ist geplant und steht in der Roadmap. Cockpit-Hardware ist keine Voraussetzung. Das Overhead und das ECAM-Bedienpanel bedienst du mit der Maus am Bildschirm. Insgesamt hat Fly-K 184 bedienbare Controls. Wer Hardware hat, bindet sie über SIOC an.
Mindestanforderungen an den Rechner nennen wir erst, wenn wir sie belegen können. Wer auf der Warteliste steht, erfährt sie zuerst.
Konkrete Antworten und ein ehrliches „steht noch nicht fest“, wo wir es selbst noch nicht wissen.
Ein A320-Simulator für Homecockpits unter Windows, der in Kombination mit gängigen Flugsimulatoren betrieben wird. Ein zentraler Core rechnet die Flugzeugsysteme. Displays, Panels und Hardware sind Clients und rechnen nichts Eigenes. Deshalb zeigt jedes Display denselben Zustand, und das ECAM leitet seine Meldungen aus diesem Zustand ab.
Für alle, die ein A320-Homecockpit bauen oder betreiben, vom Hardware-Panel am Schreibtisch bis zum ganzen Cockpit im Keller. Wer noch keine Hardware hat, bedient Fly-K mit Maus und Monitor.
Die A320. Referenzflugzeug ist die A320-214. Ob später weitere Muster dazukommen, steht noch nicht fest.
Unterstützung für gängige Flugsimulatoren ist geplant.
Auf einem oder auf so vielen, wie dein Cockpit braucht. Ein Windows-Installer bringt zwei Rollen mit: Der Core-PC übernimmt Simulation, Anzeigen und Hardware, ein Client-PC Anzeigen, Panels und Hardware. Die Rechner sprechen über dein Heimnetz miteinander.
Nimm die Elektrik. Selbst die BAT-OFF-Leuchtfelder haben ihre eigenen Versorgungspfade: Am Boden kann eine eingeschaltete Batterie das OFF-Feld der anderen versorgen. Auch jedes Instrument hängt an seinem elektrischen Bus. Ohne Versorgung bleibt die Anzeige schwarz, nach längerer Unterbrechung läuft ein Selbsttest. Solche Details entstehen, weil Fly-K die Versorgung tatsächlich durchrechnet.
Schreib uns an mail@fly-k.com. Wir sind ein kleines Team, deshalb landet deine Nachricht direkt bei den Entwicklern.
Fly-K ist noch nicht veröffentlicht. Trag dich ein, und wir schreiben dir, sobald es losgeht. Vorher melden wir uns nur, wenn es etwas zu berichten gibt.
Nach dem Eintragen schicken wir dir einen Link, den du einmal bestätigst. Danach stehst du auf der Liste und kannst dich jederzeit mit einem Klick wieder abmelden.