Abhängigkeiten vor Priorität
Ein hoch priorisierter Limit Report kann erst starten, wenn die Nachverarbeitung erfolgreich war. Sobald diese Abhängigkeit erfüllt ist, wird er sofort zulässig – auch wenn mehrere Flüge in der Warteschlange stehen.
Produktives Engineering-System · technische Verantwortung
Flugtest- Datenbetrieb
Eine Plattform, die nach der Landung eintreffende Flugdaten in priorisierte, nachvollziehbare Engineering-Ergebnisse überführt – ohne dass ein Ingenieur jeden Verarbeitungsschritt selbst anstossen muss.
Technische Verantwortung
Architektur, Entwicklung und täglicher Betrieb der Orchestrierungsplattform; Integration von Fachwerkzeugen und Engineering-Logik von Kollegen.
Seit 2022im Produktivbetrieb weiterentwickelt
~15geplante Aufgaben pro Flug
700+Flüge über die gesamte Historie
~50 GBRohdaten pro Flugstunde
01 — Die betriebliche Ausgangslage
Der Mensch war die Ablaufsteuerung.
Die Flugtest-Instrumentierung (FTI) wandelt die Rohaufzeichnungen des Luftfahrzeugs – im Recorderformat Chapter 10 – in TDMS um, das Messdatenformat, das die Analysewerkzeuge lesen. Danach musste eine Ingenieurin oder ein Ingenieur der Flugtest-Datenanalyse (FTDA) weiterhin Dateien auswählen, die Verarbeitung in DIAdem – der von der Abteilung genutzten Messdatenumgebung – und deren VBS-Skripten starten, warten, Berichte und Ermüdungsrechnungen anstossen und jede Übergabe überwachen.
Der Hauptaufwand waren nicht die Klicks. Menschliche Wartezeiten zwischen den Schritten, vergessene Aufgaben, sequentielle Ausführung und geringe Sichtbarkeit des Status wurden zunehmend riskant, je mehr Verarbeitung automatisiert wurde und je öfter mehrere Flüge oder Prototypen gleichzeitig aktiv waren.
Das angestrebte Betriebsmodell war damit klar: Die Automatisierung führt die deterministische Arbeit aus; die diensthabende Person überwacht Ausnahmen und trifft die Engineering-Entscheidungen.
02 — Entwicklung
Schrittweise entlang der betrieblichen Realität gewachsen.
Das Ganze wurde nie als formales Plattformprogramm aufgesetzt. Jede Generation löste die nächste Einschränkung, die im Betrieb sichtbar wurde.
- 2022
Manuelle Skripte → zentrale Oberfläche
Eine einzige Oberfläche ersetzte das wiederholte Auswählen von Dateien, das Laden von Skripten und die manuelle Reihenfolge der ersten vier bis fünf Verarbeitungsschritte.
- 2024–25
Oberfläche → automatischer Auslöser
Auslöser bei neuem Flug ersetzten die aktive Überwachung; die zentrale Nachverarbeitung wechselte von VBS zu Python.
- Q1 2026
Persistente Orchestrierung
PostgreSQL, ein Planner und ein Worker brachten dauerhaften Zustand, Prioritäten, Abhängigkeiten, parallele Ausführung und sichtbare Fehler.
- Juni 2026
Verteilter Feldbetrieb
Dasselbe Betriebsmodell trug eine ausgelagerte Flugtestkampagne, nach vorbereitenden Standort- und Netzwerktests.
03 — Aktuelle Architektur
Persistenter Zustand macht den Ablauf sichtbar und wiederherstellbar.
Aufgabendefinitionen und Prioritäten liegen in einer JSON-Konfiguration. PostgreSQL hält geplante Arbeit, Status, Abhängigkeiten, Worker-Zuordnung und Fehlerdetails. Ein dauerhaft laufender Worker wählt nur Arbeit aus, die nach Prioritäts-, Abhängigkeits- und Ausführungsregeln zulässig ist.
Die Datenbank ist die betriebliche Wahrheit – keine Warteschlange im Arbeitsspeicher. So kann das Team Arbeit einsehen, wiederherstellen und neu starten, ohne den Ablauf rekonstruieren zu müssen.
Aktuelle Architektur der Flugtest-Datenverarbeitung
- 01FTI-Lieferung
Chapter 10 wird manuell in TDMS-Rohdaten umgewandelt, auf den gemeinsamen Speicher geladen und löst dort einen Ordner-Trigger aus.
- 02Python-Planner · Prüfung alle ~3 Minuten
Prüft Benennung, Quellenkonsistenz und begleitende Fluginformationen und plant anschliessend rund 15 Aufgaben.
- 03PostgreSQL
Speichert Prioritäten, Abhängigkeiten, Ausführungsstand, Zuordnung, Nachvollziehbarkeit und Python-Fehler.
- 04Python-Worker
Sperrt zulässige Arbeit und führt kritische Aufgaben zuerst aus, unabhängige Arbeit parallel und weniger dringende Arbeit über Nacht.
- 05Ergebnisse und Betrieb
Berichte, dekodierte Daten und Engineering-Datensätze werden mit Dashboard-Status, Desktop-Benachrichtigungen und Wiederholungsfunktionen bereitgestellt.
04 — Technische Entscheidungen
Eine Reihenfolge, die der technischen Dringlichkeit folgt.
Kontrollierte Parallelität
Unabhängige Aufgaben laufen weiter, während der rund 45-minütige Limit Report ausgeführt wird; explizite Parallelitätsregeln schützen empfindliche Bericht- und PDF-Vorgänge.
Sofort oder über Nacht
Kritische Engineering-Ergebnisse laufen zuerst. Speicher- und Datenbankpflege kann bis zur Nacht warten oder bei Bedarf manuell neu priorisiert werden.
Betreibbarkeit vor Komplexität
Die Architektur trägt mehrere Worker, im Normalbetrieb laufen jedoch bewusst ein Planner und ein Worker auf derselben Maschine – passend zu einem dreiköpfigen Betriebsteam.
05 — Prüfung und Betrieb
Den Ablauf testen, die validierte Engineering-Logik bewahren.
Grössere Änderungen an der Orchestrierung werden mit historischen Flügen, kontrollierten Ordnern, simulierten Auslösern und bekannten Ergebnissen erprobt, bevor sie eng begleitet in den Produktivbetrieb gehen.
Ändert sich die Verarbeitungslogik selbst – wie bei der Migration von VBS zu Python – werden die Ergebnisse direkt mit der etablierten Implementierung verglichen. Das trennt die Validierung des Ablaufs von der Validierung der Engineering-Algorithmen.
Bei einem Fehler zählt das Dashboard hoch, die diensthabende Person erhält eine Desktop-Benachrichtigung, und der Python-Traceback wird für Analyse und Neustart in PostgreSQL abgelegt.
06 — Ausgelagerte Kampagne
Kritische Fähigkeiten bleiben nahe am Luftfahrzeug.
Ein Kampagnenserver kann einen lokalen Planner und Worker betreiben und teilt dabei das PostgreSQL-Betriebsmodell mit dem Hauptstandort. Worker-Zuordnung und Prioritäten bestimmen, wo eine Aufgabe läuft; bei fehlender Verbindung ist eine lokale Neuzuordnung möglich.
- Vor Ort verarbeitenNachverarbeitung, Limit Report und die Dekodierung des Avionikbusses ARINC 429 können am Kampagnenstandort laufen.
- Komprimieren und prüfenDie Daten werden komprimiert, und vor der Übertragung wird eine BLAKE3-Prüfsumme berechnet.
- Zentral fortsetzenNach Dekomprimierung und Prüfsummenkontrolle am Hauptstandort laufen die übrigen Aufgaben auf dem zentralen Worker weiter.
Betrieblicher Nachweis: vorbereitende Standort- und Netzwerktests, danach eine ausgelagerte Flugtestkampagne im Juni 2026 ohne grösseren Ausfall der Plattform.
07 — Belegbare Wirkung
Weniger Wartezeit, früheres Engineering-Feedback.
Der wesentliche Gewinn ist ein verlässlicher Fluss: Die automatische Reihenfolge entfernt menschliche Wartezeiten, parallele Arbeit verhindert, dass lange Aufgaben unabhängige Ergebnisse blockieren, und Fehler werden sofort sichtbar.
Der Vergleich von rund einer Stunde gegenüber zwei Stunden beruht auf mehreren Architektur- und Implementierungsänderungen, nicht auf einem einzelnen gemessenen Faktor. Ein früher verfügbarer Limit Report kann einen Inspektionsbedarf noch am selben Tag aufzeigen und das nächste Flugfenster sichern.
Die drei Betreibenden und die 50 bis 75 Engineering-Nutzenden sind unterschiedliche Gruppen: Drei Ingenieure betreiben die Plattform, während ein breiterer Engineering-Kreis ihre Ergebnisse nutzt. Die Zahlen dürfen weder addiert noch mit den Nutzerzahlen der Fallstudie zur Infrastruktur-Integration gleichgesetzt werden.
08 — Meine Rolle
Durchgängige technische und betriebliche Verantwortung.
Ich habe die erste Oberfläche angestossen, den automatischen Ablauf und die Planner-/Worker-/PostgreSQL-Architektur entworfen und rund 99 % des Plattformcodes entwickelt. Ebenso stammen die meisten integrierten Verarbeitungsfunktionen, das Dashboard, der File Manager, der Cloud Uploader und die Architektur für ausgelagerte Kampagnen von mir.
Die Verantwortung endet nicht mit dem Rollout: Ich sammle Rückmeldungen der Betreibenden, definiere Verbesserungen, teste und führe grössere Generationen ein, erstelle Dokumentation, schule Kolleginnen und Kollegen und unterstütze den Produktivbetrieb an den Schnittstellen zu FTDA, FTI, Flugtest-Engineering, Fachabteilungen und Infrastruktur.
Die Abgrenzung ist wichtig: Ich habe die Orchestrierungsplattform und die meisten Verarbeitungsfunktionen entworfen und entwickelt und dabei Fachwerkzeuge sowie Engineering-Logik von Kolleginnen und Kollegen integriert. Das ist technische und plattformbezogene Verantwortung – nicht die Autorschaft jedes Algorithmus und keine formale Programmleitung.
09 — Was der Betrieb gelehrt hat
Architektur folgt dem Betrieb
Aus einer praktischen Oberfläche wurde erst dann persistente und später verteilte Orchestrierung, als die Betriebsbedingungen jeden Schritt rechtfertigten.
Beobachtbarkeit verändert die Arbeit
Dauerhafter Zustand, sichtbare Fehler und Benachrichtigungen erlauben es einem kleinen Team, Ausnahmen zu überwachen, statt jede Aufgabe zu begleiten.
Einfacher Betrieb ist ein Entwurfsergebnis
Die Mehr-Worker-Fähigkeit zu erhalten und dennoch Planner und Worker gemeinsam zu betreiben, macht die Plattform für drei direkte Betreibende einfacher handhabbar.