Un flux stable vers l’antenne
Le Radarcape fournit des données à environ 10 Hz et le système d’antenne attend également 10 Hz. Une logique de retransmission maintient la cadence fixe lorsque les arrivées ne s’alignent pas exactement.
Systems engineering · modernisation legacy · outil opérationnel
Visibilité de l’espace aérien
Une suite Python découplée qui a remplacé l’outil LabVIEW de poursuite d’une antenne de télémesure d’essais en vol. Elle transforme les positions ADS-B en un flux à cadence fixe vers le contrôleur d’antenne, tandis que l’interface opérateur, la couverture et l’enregistrement restent hors du chemin critique.
Responsabilité technique
Seul développeur logiciel et technical owner de bout en bout.
Opérationneloutil de production pour les essais en vol
2 sitesen usage opérationnel
10 Hzflux de positions vers le système d’antenne
0,1 Hzéchantillonnage du Recorder
01 — Le besoin opérationnel
Fournir en continu la position de l’aéronef à une antenne directionnelle.
Pendant les essais en vol, une antenne directionnelle au sol reçoit la télémesure d’ingénierie de l’hélicoptère. Pour maintenir la liaison, elle doit suivre automatiquement l’appareil ; un guidage manuel reste possible, mais il est nettement plus difficile car l’ingénieur instrumentation doit interpréter l’orientation par rapport au nord et estimer la position de l’hélicoptère.
La chaîne opérationnelle est : diffusion ADS-B de l’hélicoptère → récepteur ADS-B Radarcape → suite Python → contrôleur d’antenne → mouvement physique de l’antenne.
Le logiciel fournit la position de l’aéronef. Le système de contrôle connaît sa propre position et réalise les calculs nécessaires à l’orientation physique ; l’application ne pilote ni les moteurs ni leurs commandes.
02 — Pourquoi remplacer l’outil legacy
Windows 11 a déclenché le travail ; la maintenabilité en a fait une modernisation.
Mon manager m’a confié le remplacement de l’outil LabVIEW existant et fourni une première liste Jira, composée surtout de courtes phrases et de checkboxes. Le déclencheur immédiat était la migration vers Windows 11.
L’application aurait éventuellement pu continuer à fonctionner en mode de compatibilité : il ne s’agissait donc pas d’un blocage absolu. Elle restait toutefois vieillissante, difficile à maintenir et liée à un environnement sous licence offrant peu de contrôle interne.
Le passage à Python a supprimé cette dépendance, créé une base de code maintenable par l’équipe et permis d’ajouter des fonctionnalités demandées depuis longtemps. Ce fut une modernisation fonctionnelle, pas un portage 1:1.
03 — Requirements engineering
De courtes exigences Jira sont devenues des comportements testables.
Je connaissais le fonctionnement général du legacy sans être l’expert métier principal. Le processus réel fut itératif : exigences Jira initiales → développement → premiers tests → feedback utilisateur → clarification → exigences complémentaires → nouvelle implémentation.
Des prototypes configurables
L’opérateur sélectionne un prototype dans un menu. Callsign et adresse ICAO sont configurés, ce qui permet d’ajouter des prototypes internes sans modifier le cœur du logiciel.
Une validité visible
Les statuts ADS-B distinguent les données utilisables des données absentes ou invalides, y compris certaines absences cohérentes avec un aéronef au sol. Les indicateurs concernés passent au rouge.
Le comportement physique de l’antenne
Près de l’antenne, une zone configurable ajuste volontairement l’altitude transmise afin d’obtenir le comportement d’acquisition approprié pendant certains profils de hover, d’atterrissage et de décollage.
Une interface non critique
La poursuite doit continuer si l’interface Dash est fermée ou tombe en panne. La visualisation aide l’opérateur sans devenir une dépendance du flux antenne.
Les sites sont de la configuration
Position d’antenne, définition des prototypes et couverture préparée sont des assets de site. Ajouter un lieu ne doit pas exiger de refonte du logiciel principal.
ADS-B hélicoptère
Identité · position · altitude
Radarcape
Reçoit les diffusions des aéronefs
Acquisition et distribution
Rend disponible l’état validé de l’aéronef
Poursuite et flux antenne
Sélectionne le prototype · fournit la position à 10 Hz
Contrôleur d’antenne
Calcule l’orientation · déplace l’antenne
Recorder
Historique persistant des prototypes
Tableau de bord Dash
Carte · trace · statuts · cross-check
Workflow terrain hors ligne
Dalles terrain Swisstopo→Traitement GIS / ligne de commande→Couches par altitude→Carte interactive
04 — Architecture résiliente
Des composants indépendants maintiennent la visualisation hors du chemin critique.
La suite Python est volontairement découplée plutôt que monolithique. Chaque composant porte une responsabilité opérationnelle claire et peut évoluer sans faire du dashboard un point unique de défaillance.
Chemin de poursuite opérationnel
Acquisition et distribution
Reçoit les données du Radarcape, applique le traitement de validité pertinent et rend l’état disponible aux autres composants.
Composant de poursuite et de flux antenne
Applique le prototype et le comportement du site sélectionnés, puis fournit la position au contrôleur d’antenne à la cadence attendue de 10 Hz.
Consommateurs opérationnels indépendants
Tableau de bord Plotly Dash
Propose la sélection du prototype, une carte interactive, la trace récente, les statuts, la couverture et les azimut et élévation théoriques calculés indépendamment. Si Dash tombe, la poursuite peut continuer.
Recorder
Surveille les prototypes configurés en arrière-plan et, lorsqu’un prototype est détecté, à portée et valide, enregistre sa position toutes les dix secondes dans un CSV quotidien.
Préparé et déployé autour de la suite
Workflow de couverture terrain
Télécharge et traite les dalles Swisstopo nécessaires en couches de couverture pour la position d’antenne configurée.
Packaging Windows et configuration
Les exécutables PyInstaller évitent aux opérateurs de maintenir un environnement Python ; la configuration documentée sépare prototypes et sites du code principal.
Le dashboard n’est pas sur le chemin critique. Fermer ou perdre l’interface visuelle n’arrête pas à lui seul le composant qui continue d’alimenter le système d’antenne.
05 — Flux à cadence fixe
Le 10 Hz est une obligation d’interface.
Les données aéronef du Radarcape sont reçues à environ 10 Hz, et le système d’antenne attend également un flux de positions à 10 Hz. Le timing d’arrivée et la cadence fixe de sortie ne sont pas supposés parfaitement alignés.
Une logique de retransmission ou d’upsampling fournit donc la dernière position valide à la cadence requise. Répéter une valeur ne la transforme pas en nouvelle mesure.
Aucun dead reckoning, aucune prédiction ni interpolation avancée. La validité reste explicite et la poursuite ne continue pas à utiliser aveuglément des données devenues invalides ou qui ne sont plus reçues.
Requirements clarifiés avec les utilisateurs
Une checkbox mal comprise a révélé la physique derrière l’exigence.
Ma première implémentation de l’exigence proche de l’antenne était incorrecte : la courte phrase Jira n’expliquait ni les modes acquisition et directionnel de l’antenne, ni l’évolution de leur gain avec la géométrie et la hauteur.
Les utilisateurs instrumentation m’ont expliqué pourquoi le mode directionnel peut perdre le signal quand l’hélicoptère revient très près pendant certains profils de hover, d’atterrissage et de décollage. J’ai corrigé la conception avec une zone configurable et un ajustement volontaire de l’altitude qui provoque le comportement d’acquisition approprié.
Ce comportement évite des changements manuels répétés et réduit les pertes de signal dans ces phases. C’est un exemple concret de feedback utilisateur et de compréhension du système physique transformés en exigence puis en implémentation corrigées, sans prétendre à un gain quantifié.
06 — Carte interactive et couverture terrain
Une visibilité dépendante de l’altitude remplace la carte statique spécifique à un site.
L’interface LabVIEW utilisait une carte fixe et une couverture largement spécifique à un site. Le remplaçant apporte une carte interactive avec zoom, position actuelle et environ 120 positions récentes — soit près de 120 secondes de trajectoire.
Un workflow GIS et ligne de commande télécharge et traite les dalles terrain Swisstopo. Il modélise le relief, pas les bâtiments, ce qui correspond aux principales obstructions de l’environnement alpin.
Pour chaque position d’antenne, le traitement produit une zone de visibilité approximative sur environ 30 km de rayon, par tranches de 500 ft jusqu’à environ 20 000 ft. Le dashboard sélectionne la couverture selon l’altitude courante de l’hélicoptère.
Le même processus prépare un nouveau site à partir des coordonnées d’antenne et des données terrain pertinentes. Cela permet le multi-site sans intégrer chaque lieu dans le cœur de l’application.
07 — Gestion des défaillances et cross-check opérateur
Une donnée invalide devient visible au lieu de rester plausible.
La résilience vient de la séparation et des statuts explicites ; le système ne revendique ni récepteur redondant, ni failover automatique, ni haute disponibilité.
Les données deviennent invalides
L’état de l’aéronef suivi passe à invalid, les indicateurs concernés deviennent rouges et le flux antenne ne continue pas à faire confiance aveuglément aux positions invalides.
Une absence reste plausible en opération
La logique de validité tient compte de cas comme un aéronef au sol, afin de ne pas présenter toutes les valeurs manquantes comme une même panne.
Le dashboard tombe
La poursuite et le flux vers l’antenne peuvent continuer car Dash est un consommateur indépendant, pas une étape du chemin critique.
Le guidage manuel devient nécessaire
Le dashboard calcule indépendamment les azimut et élévation théoriques depuis les positions connues de l’antenne et de l’aéronef pour fournir un cross-check opérationnel.
Aucun feedback direct de l’antenne n’est revendiqué. Une comparaison commande-versus-position-réelle a été envisagée puis abandonnée, l’interface disponible n’étant pas assez fiable ni maintenable pour une intégration propre.
08 — Validation opérationnelle progressive
Simulation répétable, puis matériel réel et vols réels.
La validation a progressé des entrées contrôlées à la chaîne opérationnelle complète. La simulation était un point de départ, pas un substitut aux preuves matérielles et en vol.
- 01
Fake mode CSV
Des positions enregistrées peuvent être rejouées en boucle afin de créer une trajectoire répétable et de vérifier la sélection, le comportement de poursuite et la chaîne vers l’antenne.
- 02
Radarcape et trafic en direct
Le logiciel a été connecté au récepteur installé et exercé avec le trafic ADS-B courant d’un aérodrome actif.
- 03
Circuits d’aéronefs réels
Des avions en circuit ont permis de vérifier visuellement que l’antenne physique suivait correctement leur trajectoire.
- 04
Vol hélicoptère à risque limité
Un vol réel a été choisi pour limiter le risque opérationnel tout en vérifiant le comportement de l’antenne, le suivi de l’appareil et la réception réelle de la télémesure.
- 05
Vols opérationnels
Plusieurs essais en vol ultérieurs ont été réalisés avec succès avec la suite Python comme outil de poursuite d’antenne.
09 — État actuel
Opérationnel sur deux sites d’essais en vol.
- Usage en production
- Le système est terminé et utilisé pendant les essais en vol. L’outil LabVIEW n’est plus le système principal de poursuite et aucun développement n’est actuellement nécessaire sur le cœur de la suite.
- Modèle de déploiement
- Le logiciel est packagé en exécutables Windows avec PyInstaller. Une partie de la suite fonctionne sur un serveur en continu, notamment pour le monitoring et l’enregistrement ; les utilisateurs accèdent ou lancent le dashboard depuis leur station.
- Historique du Recorder
- Les prototypes configurés sont enregistrés indépendamment des sessions de télémesure actives à 0,1 Hz lorsqu’ils sont détectés, à portée et valides. Les CSV quotidiens sont conservés sur une longue période et fournissent la dernière position et trajectoire disponibles en cas d’événement imprévu.
- Transfert opérationnel
- Wiki, README, guides utilisateur et de configuration, contexte de développement, troubleshooting et cheat sheets expliquent comment lancer, configurer et diagnostiquer le système sans ma présence directe.
- Sites futurs
- Un site supplémentaire est prévu. Son ajout consiste surtout à configurer le site, renseigner l’antenne, préparer le terrain et la couverture puis déployer l’environnement — pas à redévelopper le système principal.
10 — Changement démontré
La capacité opérationnelle est devenue maintenable, visible et transférable.
Legacy
Application LabVIEW vieillissante et dépendance à une licence
Remplacement
Suite Python compatible Windows 11 et packagée pour les opérateurs
Legacy
Carte statique et couverture surtout mono-site
Remplacement
Carte interactive, couverture terrain selon l’altitude et génération réutilisable par site
Legacy
Poursuite et visualisation couplées dans un outil
Remplacement
Composants tracking, Dash et Recorder indépendants avec chemin opérationnel protégé
Legacy
Évolutions des prototypes et sites liées étroitement à l’outil
Remplacement
Callsigns, adresses ICAO, positions d’antenne et assets de sites configurables
Legacy
Interventions manuelles proches de l’antenne pendant certains profils
Remplacement
Comportement proche de l’antenne configurable et clarifié avec les utilisateurs instrumentation
Legacy
Peu de visibilité opérateur et de moyens de test
Remplacement
Statuts explicites, cross-check des angles théoriques, rejeu et matériel de first-line troubleshooting
Legacy
Historique de position surtout lié à l’usage actif
Remplacement
Enregistrement de fond persistant des prototypes configurés, même hors sessions de télémesure actives
L’impact reste qualitatif. Aucun gain de charge de travail ni de précision de poursuite n’est chiffré. Le résultat démontré est un remplacement maintenable, utilisé en opération, avec des statuts plus clairs, une séparation plus résiliente, le multi-site et un handover documenté.
11 — Mon rôle
Seul développeur logiciel et technical owner de bout en bout.
Mon manager a défini le besoin initial — remplacer l’outil LabVIEW existant — et fourni les premières exigences Jira. J’ai ensuite clarifié les requirements avec les utilisateurs, conçu l’architecture découplée et développé seul l’ensemble de la suite.
Mon périmètre couvrait l’intégration Radarcape, l’interface antenne, le comportement de poursuite, le dashboard Dash, le traitement terrain et couverture, les outils de fake/replay, le Recorder indépendant, le support à la validation opérationnelle, le packaging PyInstaller, la configuration, la documentation et le troubleshooting.
Mon manager a soutenu certaines parties du déploiement physique, notamment l’installation du nouveau Radarcape. Les utilisateurs ont apporté les connaissances métier nécessaires à la clarification du comportement, et leur feedback a conduit aux itérations suivantes.
Il s’agissait de responsabilité technique, pas de project management. Je n’ai ni initié le projet, ni dirigé un programme, ni été responsable du matériel d’antenne. J’ai pris en charge le logiciel de remplacement et son intégration, des exigences clarifiées au déploiement opérationnel et au handover.
12 — Enseignements techniques
Les exigences s’apprennent par l’usage
Les phrases courtes ne sont devenues des comportements fiables qu’après premiers tests, explications utilisateurs, correction des hypothèses et itérations.
Comprendre le système physique
La logique proche de l’antenne n’a pris sens qu’en comprenant les comportements acquisition et directionnel, pas seulement la checkbox.
Protéger le chemin opérationnel
Dash et Recorder indépendants peuvent tomber ou évoluer sans arrêter automatiquement le flux vers l’antenne.
Le handover fait partie de l’architecture
Configuration, packaging Windows, statuts de troubleshooting et documentation opérateur rendent le système exploitable sans son auteur.