Wiederkehrende Antworten vorberechnen
Wiederholtes Dateilesen aus dem Anfragepfad entfernen und gespeicherte Kennzahlen erneut nutzen.
Engineering-Datenarchitektur · technische Verantwortung
Flugtest- Analysedatenbank
Eine PostgreSQL-Analyseplattform, die wiederkehrende Fragen über vollständige Hubschrauber-Flughistorien in indexierte Abfragen überführt – mit automatisierter Ingestion und einem gemeinsamen Python-Zugriffspaket.
Technische Verantwortung
Technischer Eigentümer seit dem ersten Entwurf.
Ende 2022erste Version umgesetzt
400–500Flüge hinter dem ersten Engpass
~30 000Event Marker im Ausgangsumfang
~800Kanäle im ersten Entwurf
01 — Der technische Engpass
Die Flüge waren indexiert. Ihre Signalhistorie war es nicht.
Als ich im Juni 2022 zur Flugtest-Datenanalyse kam, verknüpfte eine kleine SQLite-Datenbank bereits Flugnummern mit Aufzeichnungsdateien und grundlegenden Metadaten. Dieser Katalog war nützlich, konnte aber weder das historische Maximum eines Signals noch frühere Grenzwertüberschreitungen beantworten.
Für jede Anfrage mussten weiterhin alle betreffenden Flugdateien geöffnet, die gewünschten Kanäle geladen, das Ergebnis berechnet und der Vorgang über Hunderte Flüge wiederholt werden. Mit der Signalzahl stieg die Laufzeit stark: Umfangreiche Python-Extraktionen dauerten rückblickend geschätzt häufig vier bis fünf Stunden, besonders grosse Fälle bis zu etwa zehn Stunden; DIAdem-Analysen liefen teilweise über Nacht.
Diese Angaben sind rückblickende Erfahrungswerte und keine damaligen Benchmarks. Entscheidend war, dass jede neue Frage dieselbe Rohdatenhistorie erneut durchsuchte.
02 — Eigeninitiative
Wiederverwendbare Engineering-Kennzahlen speichern statt jede Datei erneut zu öffnen.
Etwa im September–Oktober 2022, wenige Monate nach meinem Einstieg als fest angestellter Ingenieur, begann ich eigenständig mit dem Entwurf einer Analysedatenbank. Das Vorhaben war weder ein formaler Auftrag von IT oder Management noch ein zugewiesenes Projekt; es entstand aus dem wiederkehrenden Engpass. Ende 2022 war die erste Version umgesetzt.
Die automatisierte Ingestion berechnet Signalstatistiken vor und speichert deren Flug- und Event-Marker-Kontext in PostgreSQL. Historische Extremwerte, Grenzwertüberschreitungen und ihre genauen Fundstellen lassen sich danach ohne erneutes Lesen der gesamten Kampagne abrufen.
Engineering-ModellFlug → Event Marker → nach ATA gegliederte Systemdaten
Event Marker stammen aus dem Flugbetrieb: Die Crew markiert Beginn und Ende von Testbedingungen in den aufgezeichneten Daten. Die Datenbank nutzt diesen Kontext, begrenzt historische Suchen aber nicht auf stabilisierte Testpunkte.
03 — Architektur
Warum PostgreSQL und warum dieses Datenmodell.
Zunächst erwog ich, SQLite zu erweitern. Ein Prototyp umfasste jedoch bereits rund 400–500 Flüge, etwa 30 000 Event Marker und ungefähr 800 Kanäle. Vorberechnete Kennzahlen in diesem Umfang verlangten nach einem grösseren, langlebigen relationalen System.
Nach eigener Recherche wählte ich PostgreSQL als quelloffene, ausgereifte Plattform für das erwartete Volumen, ohne unnötige Komplexität einzuführen. Es war meine technische Entscheidung und nicht das Ergebnis eines formalen Architekturboards.
Das Schema folgt dem Engineering-Domänenmodell. Flüge enthalten die operativen Event Marker; darunter sind indexierte Tabellen nach Luftfahrzeugsystem und ATA-Kapitel gegliedert. So entsteht keine monolithische Gesamttabelle, und die Daten bleiben an den Subsystemgrenzen der Analyse ausgerichtet.
04 — Analyseablauf
Vom verarbeiteten Flug zur wiederverwendbaren Historie.
- 01
Verarbeiteter Flug und aufgezeichnete Event Marker stehen bereit
- 02
Die Ingestion liest die verfügbaren Engineering-Kanäle
- 03
Signalstatistiken werden mit Flug- und Event-Marker-Kontext berechnet
- 04
Ergebnisse werden in indexierte, nach ATA gegliederte PostgreSQL-Tabellen geschrieben
- 05
Regeln können Vorwärtsflug, Schweben, Steig- und Sinkflug klassifizieren
- 06
Ingenieure rufen ausgewählte Flüge und Signale über Python oder SQL ab
Die Ingestion läuft innerhalb der umfassenderen Flugtest-Datenbetriebsplattform. Diese Datenbank bildet die analytische Historie aus den verarbeiteten Daten.
05 — Technische Entscheidungen
Betrieblichen Kontext erhalten
Crew-seitig aufgezeichnete Event Marker lokalisieren Testbedingungen, ohne die Historie auf stabilisierte Punkte zu beschränken.
Nach Engineering-Domänen gliedern
Subsystemdaten nach ATA-Kapitel organisieren, damit das relationale Modell mit den Kampagnen übersichtlich bleibt.
Mit expliziten Regeln klassifizieren
Eine Entscheidungsbaum-/Regelschicht nutzt Stabilitäts-, Parameter- und Flugzustandskriterien; dies ist keine Machine-Learning-Behauptung.
06 — Umfang und Leistung
Belegte Umfänge statt aufgeblähter Gesamtzahlen.
Die Zahlen beschreiben den anfänglichen Entwurfskontext und eine belegte spätere Analyse. Sie sind nicht als aktuelle Gesamtwerte der Datenbank ausgewiesen.
- 400–500 Flüge
- ~30 000 Event Marker
- ~800 Kanäle
- typisch 50–100
- ~30 bei manchen kurzen Flügen
- 150–200 bei manchen komplexen Flügen
Beobachteter Ablauf
- FrüherStunden oder über Nacht
- Historische Fundstellenin Sekunden
- Temperaturstudie~10–15 s je Sensor
Messgrenze: Es gibt keinen universellen Vorher-nachher-Benchmark. Die früheren Laufzeiten hingen von der Zahl der Flüge und Kanäle ab; die historischen Werte sind rückblickende Schätzungen.
Für eine zertifizierungsbezogene Analyse von Rumpftemperaturen über rund 900–1 000 Flüge zweier Prototypen liess sich ein Sensor in etwa 10–15 Sekunden abrufen. Die Reproduktion genau dieser Analyse mit dem früheren DIAdem-ähnlichen Ablauf hätte schätzungsweise ein verlängertes Wochenende von etwa vier Tagen beansprucht; dies war kein formaler Benchmark.
07 — Betriebliche Pflege
Auf Nutzung über den Autor hinaus ausgelegt.
Langfristige Verantwortung umfasst Datenmodell, Ingestion, Zugriff, Wiederherstellung und die Anomalien realer Flugtesthistorien.
Zugriff
Getrennte Zugangsdaten bestehen für Lesen und Schreiben; Anwendungsgeheimnisse liegen in nicht versionierten .env-Dateien.
Schreibkontrolle
Python-Schreibvorgänge sind zusätzlich anhand des authentifizierten Arbeitsplatz- und Benutzerkontexts eingeschränkt.
Wiederherstellung
Automatische abendliche Sicherungen sind Teil des breiteren Datenbetriebs; etwa die 20 neuesten Sicherungen werden aufbewahrt.
Wartung
Schemaentwicklung, Ingestionsprobleme, Zugriffskonfiguration sowie PostgreSQL-Wartung und -Upgrades bleiben Teil meiner technischen Verantwortung.
Die Kontrollen sind auf ihrer tatsächlichen Ebene beschrieben: Datenbankzugänge, Anwendungsprüfungen und betriebliche Sicherungen – kein Unternehmens-SSO und keine separate IAM-Plattform.
08 — Python-Zugriff und Einführung
Vom persönlichen Werkzeug zur gemeinsamen Engineering-Infrastruktur.
Etwa im ersten Jahr war ich der Hauptnutzer. Durch die schnelleren historischen Auszüge wurden zunehmend Anfragen direkt an mich gerichtet, wodurch ein neuer Engpass entstand. Ab Anfang 2024 begannen weitere Ingenieure der Flugtest-Datenanalyse, das System selbst abzufragen.
Ich entwickelte die Zugriffsschicht zu einem dokumentierten internen Python-Paket im Git-Repository des Teams. Es wird per editable pip installiert, über den gemeinsamen Repository-Ablauf aktualisiert und bietet einfache Funktionen zur Auswahl von Signalen und Flügen sowie zur direkten Rückgabe an Python. Hinzu kamen SQL-Beispiele, PostgreSQL-/pgAdmin-Anleitungen und Unterstützung beim Zugriff.
Direkte Nutzer sind Mitglieder der Flugtest-Datenanalyse. Konstruktionsbüro und andere Engineering-Bereiche fordern üblicherweise einen Auszug an und erhalten CSV-Daten, Diagramme, Extremwerttabellen oder unterstützende Zeitverläufe, statt PostgreSQL selbst abzufragen.
09 — Engineering-Nutzung
Historische Fragen wurden zu routinemässiger Engineering-Analyse.
Mit der Datenbank lassen sich Extremwerte, Grenzwertüberschreitungen, Ausreisser und der genaue Flug beziehungsweise Event Marker einer Bedingung finden. Auch ein Flug kann anhand eines erinnerten Signalwerts lokalisiert und der detaillierte Zeitverlauf zur Erklärung eines ungewöhnlichen Punkts abgerufen werden.
Im Beispiel der Rumpftemperaturen wurden regelbasiert klassifizierte Manöver genutzt, um etwa 10–15 Sensoren nach Manöverart über rund 900–1 000 Flüge zu vergleichen, Extremwerte und Ausreisser zu erkennen und Zeitverläufe erklärungsbedürftiger Punkte abzurufen. Die Ergebnisse unterstützten die Bewertung der thermischen Belastung und der Repräsentativität einer Bedingung im Nutzungsspektrum des Luftfahrzeugs.
Die Datenbank ist eine Analysequelle für zertifizierungsbezogene Untersuchungen. Die Flugtest-Datenanalyse liefert Datensätze, Diagramme und Ausreisseranalysen; Konstruktionsbüro beziehungsweise Systemingenieure bleiben für Luftfahrzeugsysteme, technische Schlussfolgerungen und Zertifizierungsberichte verantwortlich.
10 — Meine Rolle
Technischer Eigentümer seit dem ersten Entwurf.
Ich identifizierte den Engpass, recherchierte die Architektur und setzte Ende 2022 die erste PostgreSQL-Version um. Ich entwarf Schema und Indexierung, entwickelte Ingestion und Python-Zugriffspaket und führte Kolleginnen und Kollegen mit Dokumentation, Beispielen und direkter Unterstützung an das System heran.
Ich verantworte weiterhin Datenbankarchitektur, Schemaentwicklung, Ingestion, Wartung, Zugriffskonfiguration, Sicherungen und Wiederherstellungsbereitschaft, PostgreSQL-Upgrades, Nutzerunterstützung und die Untersuchung von Datenanomalien. Unter dieser Verantwortung entwickelte sich die individuelle Lösung zu regelmässig genutzter Team-Infrastruktur.
Die Abgrenzung ist wichtig: Dies war ein eigeninitiativ gestartetes Engineering- und Datenarchitekturprojekt, kein Projektmanagementauftrag. Ich verantworte die Analyseplattform; Konstruktionsbüro und Systemingenieure verantworten ihre Zertifizierungsberichte und die Schlussfolgerungen aus den bereitgestellten Analysen.
11 — Technische Erkenntnisse
Wiederholte Arbeit aus dem Anfragepfad entfernen
Die Vorberechnung änderte das verzögernde Zugriffsmuster, statt denselben Dateiscan immer weiter zu optimieren.
Die Engineering-Domäne modellieren
Flüge, operative Event Marker und ATA-Systeme strukturieren Analysen besser als eine generische Tabelle isolierter Messungen.
Einführung braucht eine Zugriffsschicht
Das gemeinsame Python-Paket, Dokumentation und direkte Unterstützung machten aus einer nützlichen Datenbank Team-Infrastruktur.