Stabiler Antennenstrom
Das Radarcape liefert Daten mit etwa 10 Hz, und das Antennensystem erwartet ebenfalls 10 Hz. Eine Wiederholungslogik hält die feste Rate, wenn eingehende Aktualisierungen zeitlich nicht exakt dazu passen.
Systems Engineering · Legacy-Modernisierung · Betriebswerkzeug
Luftraum- Übersicht
Eine entkoppelte Python-Suite, die das LabVIEW-Werkzeug zur Verfolgung einer Flugtest-Telemetrieantenne abgelöst hat. Sie macht aus ADS-B-Positionen den Positionsstrom mit fester Rate für die Antennensteuerung; Bedienoberfläche, Abdeckung und Aufzeichnung bleiben ausserhalb des kritischen Verfolgungspfads.
Technische Verantwortung
Alleiniger Softwareentwickler und durchgängiger technischer Verantwortlicher.
BetriebProduktionswerkzeug im Flugtest
2 Standorteim operativen Einsatz
10 HzPositionsstrom zum Antennensystem
0,1 HzAbtastrate des Recorders
01 — Der betriebliche Bedarf
Eine gerichtete Telemetrieantenne kontinuierlich mit der Luftfahrzeugposition versorgen.
Bei Flugtests empfängt eine gerichtete Bodenantenne Engineering-Telemetrie vom Hubschrauber. Um die Verbindung zu halten, muss sie dem Luftfahrzeug automatisch folgen. Manuelle Führung ist möglich, aber deutlich schwieriger, weil die Instrumentierungsperson die Orientierung relativ zu Norden interpretieren und die Hubschrauberposition schätzen muss.
Die betriebliche Kette lautet: ADS-B-Aussendung des Hubschraubers → Radarcape-ADS-B-Empfänger → Python-Suite → Antennensteuerung → physische Antennenbewegung.
Die Software liefert die Luftfahrzeugposition. Das Antennensteuerungssystem kennt seinen eigenen Standort und berechnet die physische Ausrichtung selbst; die Anwendung steuert weder die Motoren direkt noch berechnet sie Motorbefehle.
02 — Warum das Altwerkzeug ersetzt wurde
Windows 11 löste die Arbeit aus; Wartbarkeit machte daraus eine Modernisierung.
Mein Manager beauftragte mich, das bestehende LabVIEW-Verfolgungswerkzeug zu ersetzen, und übergab eine erste Jira-Liste, überwiegend kurze Anforderungssätze und Checkboxes. Unmittelbarer Auslöser war die Migration auf Windows 11.
Die Anwendung hätte möglicherweise im Kompatibilitätsmodus weiterlaufen können; es war also kein absoluter technischer Blocker. Sie war jedoch veraltet, schwer wartbar und an eine lizenzierte Umgebung mit begrenzter interner Kontrolle gebunden.
Der Wechsel zu Python beseitigte diese Abhängigkeit, schuf eine vom Team wartbare Codebasis und ermöglichte lange gewünschte Funktionen. Das Ergebnis war eine funktionale Modernisierung, keine 1:1-Portierung.
03 — Requirements Engineering
Kurze Jira-Anforderungen wurden zu prüfbarem Systemverhalten.
Ich kannte den Legacy-Ablauf, war aber nicht der primäre Fachexperte. Der tatsächliche Prozess war iterativ: erste Jira-Anforderungen → Entwicklung → erste Tests → Nutzerfeedback → Klärung → zusätzliche Anforderungen → weitere Umsetzung.
Konfigurierbare Prototypen
Bedienende wählen einen Prototyp aus einer Liste. Callsign und ICAO-Adresse liegen in der Konfiguration; weitere interne Prototypen lassen sich ohne Änderung des Kernsystems ergänzen.
Sichtbare Gültigkeit
ADS-B-Status unterscheiden nutzbare von fehlenden oder ungültigen Daten, einschliesslich Ausfällen, die bei einem Luftfahrzeug am Boden plausibel sein können. Betroffene Anzeigen werden rot.
Physisches Antennenverhalten
Nahe der Antenne passt eine konfigurierbare Zone die übermittelte Höhe bewusst an, um bei bestimmten Schwebeflug-, Lande- und Startprofilen das passende Akquisitionsverhalten auszulösen.
Nicht-kritische Oberfläche
Die Verfolgung muss weiterlaufen, wenn Dash geschlossen wird oder ausfällt. Die Visualisierung hilft im Betrieb, darf aber keine Abhängigkeit des Antennenstroms sein.
Standorte als Konfiguration
Antennenposition, Prototypdefinitionen und vorbereitete Geländeabdeckung sind Standortartefakte. Ein neuer Ort soll keine grössere Änderung am Kernsystem erfordern.
Hubschrauber-ADS-B
Kennung · Position · Höhe
Radarcape
Empfängt Luftfahrzeugaussendungen
Erfassung und Verteilung
Stellt den validierten Zustand bereit
Verfolgung und Antennenstrom
Wählt Prototyp · liefert Position mit 10 Hz
Antennensteuerung
Berechnet Ausrichtung · bewegt Antenne
Recorder
Dauerhafte Positionshistorie
Dash-Dashboard
Karte · Spur · Status · Gegenprüfung
Offline-Geländeprozess
Swisstopo-Geländekacheln→GIS-/Kommandozeilenverarbeitung→Höhengestaffelte Abdeckung→Interaktive Karte
04 — Resiliente Architektur
Unabhängige Komponenten halten die Visualisierung aus dem kritischen Pfad.
Die Python-Suite ist bewusst entkoppelt statt monolithisch. Jede Komponente hat eine klare betriebliche Verantwortung; das Dashboard wird dadurch nicht zum Single Point of Failure.
Betrieblicher Verfolgungspfad
Erfassung und Verteilung
Empfängt Daten vom Radarcape, behandelt relevante Gültigkeitszustände und stellt den Zustand anderen Komponenten bereit.
Verfolgungs- und Antennenstrom-Komponente
Wendet den ausgewählten Prototyp und das Standortverhalten an und liefert die Position mit der erwarteten Rate von 10 Hz an die Antennensteuerung.
Unabhängige betriebliche Nutzer
Plotly-Dash-Dashboard
Bietet Prototypauswahl, interaktive Karte, jüngste Spur, Status, Abdeckung sowie unabhängig berechneten theoretischen Azimut und Elevationswinkel. Fällt Dash aus, kann die Verfolgung weiterlaufen.
Recorder
Überwacht konfigurierte Prototypen im Hintergrund und schreibt deren Position alle zehn Sekunden in eine Tages-CSV, solange ein Prototyp erkannt, in Reichweite und gültig ist.
Vorbereitet und um die Suite herum bereitgestellt
Geländeabdeckungsprozess
Lädt die nötigen Swisstopo-Geländekacheln und verarbeitet sie zu Abdeckungsebenen für die konfigurierte Antennenposition.
Windows-Paketierung und Konfiguration
PyInstaller-Programme ersparen Bedienenden eine eigene Python-Umgebung; dokumentierte Konfiguration trennt Prototypen und Standorte vom Kerncode.
Das Dashboard liegt nicht im kritischen Pfad. Das Schliessen oder der Ausfall der Oberfläche stoppt nicht automatisch die Komponente, die das Antennensystem weiter versorgt.
05 — Strom mit fester Rate
10 Hz ist eine Schnittstellenpflicht.
Radarcape-Luftfahrzeugdaten treffen mit etwa 10 Hz ein; das Antennensystem erwartet den Positionsstrom ebenfalls mit 10 Hz. Eingangszeitpunkte und feste Ausgangsrate werden nicht als perfekt synchron angenommen.
Wiederholungs- oder Upsampling-Logik liefert deshalb die jüngste gültige Position im geforderten Takt. Ein wiederholter Wert wird dadurch nicht zu einer neuen Messung.
Keine Koppelnavigation, Vorhersage oder fortgeschrittene Interpolation. Die Gültigkeit bleibt sichtbar; der Verfolgungspfad verwendet Luftfahrzeugdaten nicht blind weiter, nachdem sie ungültig geworden sind oder nicht mehr empfangen werden.
Mit Nutzenden geklärte Anforderungen
Eine missverstandene Checkbox legte die Physik hinter der Anforderung offen.
Meine erste Umsetzung der Anforderung nahe der Antenne war falsch, weil der kurze Jira-Satz weder Akquisitions- und Richtmodus noch die Abhängigkeit ihrer Verstärkung von Geometrie und Höhe erklärte.
Die Instrumentierungsnutzenden erklärten, warum der Richtbetrieb bei bestimmten Schwebeflug-, Lande- und Startprofilen Signal verlieren kann, wenn der Hubschrauber sehr nahe zurückkehrt. Ich korrigierte den Entwurf mit einer konfigurierbaren Zone und einer bewussten Höhenanpassung, die das passende Akquisitionsverhalten auslöst.
Damit entfallen wiederholte manuelle Moduswechsel und Signalverluste in diesen Phasen werden reduziert. Es ist ein konkretes Beispiel dafür, wie Nutzerfeedback und Verständnis des physischen Systems zu einer korrigierten Anforderung und Umsetzung führten — ohne einen gemessenen Zahlenwert zu behaupten.
06 — Interaktive Karte und Geländeabdeckung
Höhenabhängige Sichtbarkeit ersetzt eine standortspezifische statische Karte.
Die LabVIEW-Oberfläche nutzte eine feste Karte und weitgehend standortspezifische Abdeckung. Der Ersatz bietet interaktiven Zoom, aktuelle Luftfahrzeugposition und rund 120 jüngste Positionen — etwa 120 Sekunden Spurhistorie.
Ein Offline-GIS- und Kommandozeilenprozess lädt Swisstopo-Geländekacheln und verarbeitet sie. Er modelliert Gelände, keine Gebäude; dies passt zu den wichtigsten Hindernissen im alpinen Betriebsumfeld.
Für jede Antennenposition entstehen ungefähre Sichtbereiche in rund 30 km Radius, in 500-ft-Höhenstufen bis rund 20.000 ft. Das Dashboard wählt die Abdeckung nach der aktuellen Hubschrauberhöhe.
Derselbe Prozess bereitet aus Antennenkoordinaten und passenden Geländedaten einen neuen Standort vor. So wird Mehrstandortbetrieb möglich, ohne jeden Ort in den Kern der Anwendung einzubauen.
07 — Fehlerbehandlung und betriebliche Gegenprüfung
Ungültige Daten werden sichtbar, statt plausibel weiterzuwirken.
Resilienz entsteht durch Trennung und explizite Zustände; das System beansprucht weder redundante Empfänger noch automatische Umschaltung oder Hochverfügbarkeit.
Luftfahrzeugdaten werden ungültig
Der Zustand des verfolgten Luftfahrzeugs wird ungültig, betroffene Anzeigen werden rot und der Antennenstrom vertraut ungültigen Positionen nicht blind weiter.
Ein Ausbleiben kann betrieblich plausibel sein
Die Gültigkeitslogik berücksichtigt Fälle wie ein Luftfahrzeug am Boden, damit nicht jeder fehlende Wert als derselbe Fehler erscheint.
Das Dashboard fällt aus
Verfolgung und Antennenstrom können weiterlaufen, weil Dash ein unabhängiger Nutzer und kein Schritt im kritischen Pfad ist.
Manuelle Führung wird nötig
Das Dashboard berechnet theoretischen Azimut und Elevationswinkel unabhängig aus bekannten Antennen- und Luftfahrzeugpositionen und bietet damit eine betriebliche Gegenprüfung.
Keine direkte Antennenrückmeldung wird behauptet. Ein Soll-Ist-Vergleich wurde erwogen, aber verworfen, weil die verfügbare Antennenschnittstelle für eine saubere Integration nicht zuverlässig oder wartbar genug war.
08 — Schrittweise Betriebsvalidierung
Wiederholbare Simulation, dann reale Hardware und reale Flüge.
Die Validierung ging von kontrollierten Eingaben zur vollständigen Betriebskette. Simulation war Ausgangspunkt, kein Ersatz für Hardware- und Flugnachweise.
- 01
CSV-Fake-Modus
Aufgezeichnete Positionen lassen sich in einer Schleife abspielen. So entsteht eine wiederholbare Flugbahn zur Prüfung von Auswahl, Verfolgungsverhalten und Antennenkette.
- 02
Live-Radarcape und echter Verkehr
Die Software wurde mit dem installierten Empfänger und aktuellem ADS-B-Verkehr an einem aktiven Flugplatz betrieben.
- 03
Reale Platzrunden
Flugzeuge in Platzrunden dienten dazu, visuell zu prüfen, dass die physische Antenne ihrer Flugbahn folgte.
- 04
Hubschrauberflug mit begrenztem Risiko
Ein realer Flug wurde zur Begrenzung des Betriebsrisikos ausgewählt und prüfte Antennenverhalten, Hubschrauberverfolgung und tatsächlichen Telemetrieempfang.
- 05
Betriebliche Flüge
Mehrere spätere Flugtests wurden erfolgreich mit der Python-Suite als Antennenverfolgungswerkzeug durchgeführt.
09 — Aktueller Stand
An zwei Flugteststandorten im Betrieb.
- Produktive Nutzung
- Das System ist fertig und wird bei Flugtests eingesetzt. Das LabVIEW-Werkzeug ist nicht mehr das primäre Verfolgungssystem; am Kernsystem ist derzeit keine Entwicklung erforderlich.
- Bereitstellungsmodell
- Die Software ist mit PyInstaller als Windows-Programme paketiert. Teile der Suite laufen kontinuierlich auf einem Server, unter anderem für Monitoring und Aufzeichnung; Nutzende greifen vom Arbeitsplatz auf das Dashboard zu oder starten es dort.
- Recorder-Historie
- Konfigurierte Prototypen werden unabhängig von aktiven Telemetriesitzungen mit 0,1 Hz protokolliert, solange sie erkannt, in Reichweite und gültig sind. Tages-CSVs bleiben langfristig erhalten und liefern bei einem unerwarteten Ereignis die letzte verfügbare Position und Flugbahn.
- Betriebsübergabe
- Wiki, README, Nutzer- und Konfigurationsanleitungen, Entwicklungskontext, Fehlerbehebung und Bediener-Kurzübersichten erklären Start, Konfiguration und Diagnose ohne meine direkte Anwesenheit.
- Künftige Standorte
- Ein weiterer Standort ist geplant. Seine Ergänzung besteht hauptsächlich aus Konfiguration, Antennenkoordinaten, Gelände- und Abdeckungsvorbereitung sowie Umgebungsbereitstellung — nicht aus Neuentwicklung des Kernsystems.
10 — Nachgewiesene Veränderung
Die betriebliche Fähigkeit wurde wartbar, sichtbar und übertragbar.
Altbestand
Alternde LabVIEW-Anwendung und Lizenzabhängigkeit
Ersatz
Windows-11-kompatible Python-Suite, für Bedienende paketiert
Altbestand
Statische Karte und weitgehend einzelstandortspezifische Abdeckung
Ersatz
Interaktive Karte, höhenabhängige Geländeabdeckung und wiederverwendbare Standorterzeugung
Altbestand
Verfolgung und Visualisierung in einem Werkzeug gekoppelt
Ersatz
Unabhängige Tracking-, Dash- und Recorder-Komponenten mit geschütztem Betriebspfad
Altbestand
Prototyp- und Standortänderungen eng an das Werkzeug gebunden
Ersatz
Konfigurierbare Callsigns, ICAO-Adressen, Antennenpositionen und Standortartefakte
Altbestand
Manuelle Eingriffe nahe der Antenne in bestimmten Profilen
Ersatz
Konfigurierbares Nahbereichsverhalten, mit Instrumentierungsnutzenden geklärt
Altbestand
Begrenzte Statussicht und Testunterstützung
Ersatz
Explizite Gültigkeitsanzeigen, theoretische Winkelprüfung, Wiedergabemodus und Material für erste Fehlerbehebung
Altbestand
Positionshistorie vor allem an aktive Nutzung gebunden
Ersatz
Dauerhafte Hintergrundaufzeichnung konfigurierter Prototypen, auch ausserhalb aktiver Telemetriesitzungen
Die Wirkung bleibt qualitativ. Keine gemessene Arbeitsersparnis oder höhere Verfolgungsgenauigkeit wird behauptet. Nachgewiesen ist ein wartbarer Ersatz im Betrieb, mit klarerem Status, resilienter Trennung, Mehrstandortfähigkeit und dokumentierter Übergabe.
11 — Meine Rolle
Alleiniger Softwareentwickler und durchgängiger technischer Verantwortlicher.
Mein Manager definierte den ersten Bedarf — das bestehende LabVIEW-Werkzeug ersetzen — und lieferte die ersten Jira-Anforderungen. Anschliessend klärte ich die Anforderungen mit Nutzenden, entwarf die entkoppelte Architektur und entwickelte die gesamte Suite allein.
Mein Umfang umfasste Radarcape-Integration, Antennenschnittstelle, Verfolgungsverhalten, Dash-Dashboard, Gelände- und Abdeckungsverarbeitung, Fake-/Replay-Werkzeuge, unabhängigen Recorder, Unterstützung der Betriebsvalidierung, PyInstaller-Paketierung, Konfiguration, Dokumentation und Fehlerbehebung.
Mein Manager unterstützte Teile der physischen Bereitstellung, insbesondere die Installation des neuen Radarcape. Die Nutzenden brachten das Fachwissen zur Klärung des Betriebsverhaltens ein; ihr Feedback führte zu den weiteren Iterationen.
Dies war technische Verantwortung, kein Projektmanagement. Ich initiierte das Projekt nicht, leitete kein Programm und verantwortete die Antennenhardware nicht. Ich verantwortete die Ersatzsoftware und ihre Integration von geklärten Anforderungen bis Betriebseinführung und Übergabe.
12 — Technische Erkenntnisse
Anforderungen entstehen durch Nutzung
Kurze Sätze wurden erst durch erste Tests, Nutzererklärungen, korrigierte Annahmen und Iteration zu verlässlichem Verhalten.
Das physische System verstehen
Die Nahbereichslogik ergab erst mit dem Verständnis von Akquisitions- und Richtverhalten Sinn, nicht allein aus der Checkbox.
Den Betriebspfad schützen
Unabhängige Dash- und Recorder-Komponenten können ausfallen oder gewartet werden, ohne den Antennenstrom automatisch zu stoppen.
Übergabe gehört zur Architektur
Konfiguration, Windows-Paketierung, Fehlerstatus und Bedienerdokumentation machen das System ohne seinen Autor betreibbar.