Les fausses idées reçues des programmeurs sur l’aviation
(flightaware.engineering)- Les données aéronautiques sont complexes et présentent de nombreuses caractéristiques non standard
- Les développeurs font souvent de mauvaises hypothèses sur les vols, aéroports, la navigation et les informations de transpondeur
- En pratique, les systèmes de suivi des vols doivent gérer avec souplesse de nombreuses situations d’exception et anomalies de données
- Beaucoup d’idées reçues provoquent des erreurs inattendues dans les logiciels ou les systèmes clients
- Lors de la conception des données, il est nécessaire d’adopter une perspective qui reflète attentivement la complexité du réel
Vue d’ensemble
FlightAware est une entreprise qui développe des logiciels traitant et diffusant des données aéronautiques dans le monde entier. Or, contrairement à ce que l’on pourrait croire, les données aéronautiques réelles ne sont pas structurées de façon uniforme et comportent de nombreuses exceptions et anomalies. Beaucoup de développeurs partent de certaines hypothèses sur la structure des données, les flux ou les systèmes d’identification, mais celles-ci se révèlent erronées dans la pratique et entraînent des erreurs et incohérences dans les systèmes. Cet article, dans la continuité de la série sur les fausses évidences, récapitule les idées fausses fréquentes dans les logiciels du secteur aérien ainsi que les cas concrets qu’elles provoquent.
Flights (informations sur les vols)
- On croit souvent à tort qu’un vol part toujours d’une porte d’embarquement, alors qu’en réalité il peut changer plusieurs fois de porte, ou partir beaucoup plus tard ou plus tôt que prévu
- Il est facile de penser que les horaires de vol ou les aéroports de départ et d’arrivée sont clairement définis, mais les hélicoptères, appareils militaires et autres peuvent décoller ou atterrir ailleurs que dans un aéroport
- On pourrait supposer que la durée d’un vol ou son horaire suit une régularité, mais les vols de très longue durée s’étendant sur plusieurs jours ou les opérations atypiques sont fréquents
- Il est tentant de supposer qu’un numéro de vol (par ex. UAL1234) est unique, alors qu’en réalité plusieurs identifiants ou numéros peuvent être associés à un même avion, et qu’un même numéro peut être utilisé dans différentes situations
- Même lorsque le numéro semble identique à l’écrit, identifiant de vol, immatriculation et autres marques peuvent être mélangés, ce qui crée de la confusion, et les informations d’identification utilisées peuvent différer entre billetterie, contrôle aérien et pilotes
Airports (informations sur les aéroports)
- On peut penser que la position d’un aéroport et ses codes d’identification sont fixes, mais en pratique des aéroports ferment, déménagent ou fusionnent, ce qui peut modifier leur emplacement ou leur code
- Les systèmes de dénomination des terminaux, portes d’embarquement, pistes, etc. ne sont pas cohérents non plus et comportent de nombreuses règles d’exception
- Même pour les systèmes de codes ICAO/IATA, il existe de nombreux cas de doublons, d’attribution de plusieurs codes ou de mauvaise interprétation des codes de localisation qui ne correspondent pas à l’idée qu’on s’en fait
- Le fait qu’une information d’identification existe (par ex. un code IATA) ne garantit pas nécessairement qu’il s’agisse d’un véritable aéroport ; certains codes IATA ont aussi été attribués à des gares ferroviaires ou des terminaux de bus
- Certains codes ICAO ont même été attribués à des lieux qui ne se trouvent pas sur Terre (par ex. des cratères extraterrestres)
Airlines (informations sur les compagnies aériennes)
- Aucun exemple précis de fausse idée reçue n’étant mentionné séparément dans la source, cette partie est omise
Navigation (navigation et informations de route)
- On croit à tort que les noms des waypoints sont uniques, alors qu’en réalité il existe des doublons
- La définition de l’altitude utilisée dans l’aviation n’est pas unifiée et peut être interprétée différemment selon les références employées
- On peut penser que les données du contrôle aérien sont parfaitement exactes, alors qu’en pratique des erreurs ou des changements surviennent fréquemment
- L’annulation d’un plan de vol ou ses modifications peuvent ne pas se refléter dans le vol réel, et un même vol peut changer plusieurs fois de destination
- Il existe également des incohérences entre les données de radar et celles des organismes de contrôle aérien, ainsi que des écarts de position lors d’observations simultanées
Transponders and ADS-B (informations sur les transpondeurs et l’ADS-B)
- On suppose que les signaux ADS-B ne sont émis que par des avions, alors qu’ils peuvent aussi provenir de véhicules d’aéroport ou d’autres équipements
- La confiance excessive dans la précision des coordonnées GPS et la fiabilité du signal est également une idée fausse
- Les erreurs, doublons, oublis de maintenance ou problèmes de format dans les informations d’enregistrement des transpondeurs (numéro d’identification, adresse Mode S, etc.) entraînent fréquemment des écarts entre les données en temps réel et la réalité
- Il est facile de penser que les informations ADS-B sont reçues et stockées telles quelles, mais en pratique divers problèmes surviennent, comme des erreurs de transmission ou la falsification de signaux
- Les pannes d’équipement, la mauvaise gestion ou des facteurs externes (par ex. des câbles rongés par des rats) sont aussi des variables bien réelles
Conclusion
Cette liste illustre la complexité de la fiabilité des données aéronautiques à partir de l’expérience et des enseignements accumulés au fil des années par les équipes de développement de FlightAware et Hyperfeed à travers de très nombreux cas réels. Elle souligne l’importance d’une modélisation et d’une exploitation des données qui tiennent rigoureusement compte des exceptions du monde réel afin de réduire les erreurs et les malentendus.
4 commentaires
C’est pour ça que la standardisation des données est… importante… haha
Le texte est vraiment très concis, mais l’émotion sous-jacente… ;;
Rien qu’à le lire, ma tension monte lol
Commentaires Hacker News
Explication du fait qu’un avion ne dispose pas d’un identifiant unique immuable dans le temps. Partage d’une expérience concrète montrant que chaque appareil reçoit bien un numéro de série, mais que cela ne suffit pas à garantir l’unicité. La combinaison « constructeur, modèle, numéro de série » constitue à peu près un identifiant unique sur toute la durée de vie, mais même cela peut changer si l’appareil change de type après une modification structurelle. Ajout d’une remarque personnelle sur le caractère étonnant de l’absence d’identifiant immuable dans un système aussi vaste et complexe que l’aviation. Il est aussi expliqué que le numéro d’immatriculation de l’avion (tail number) change comme une plaque d’immatriculation automobile, et que l’identifiant ICAO sur 24 bits est lié à l’équipement ADS-B, ce qui lui permet d’être déplacé ou modifié librement
Expression de curiosité face au fait que la combinaison « constructeur, modèle, numéro de série » ait fait l’objet d’un brevet. Questionnement sur la façon dont une telle chose a pu être considérée comme nouvelle au point d’être brevetable
Présentation d’une association philosophique entre cette histoire et le paradoxe du bateau de Thésée, autour de l’identité d’un avion et de l’évolution de ses identifiants lien Wikipédia sur le bateau de Thésée
Partage du contexte historique selon lequel l’industrie aéronautique s’est développée en silos nationaux, chacun différemment, ce qui a retardé la standardisation. Point de vue selon lequel il est déjà étonnant que des standards mondiaux aient réellement fini par s’imposer. Analyse selon laquelle cela n’est aujourd’hui possible que parce que les grands constructeurs se sont consolidés en un petit nombre d’acteurs
Partage d’une expérience de terrain indiquant qu’en pratique le problème d’un identifiant « vraiment » unique revient souvent. La solution est presque toujours la combinaison « modèle, constructeur, numéro de série », à laquelle on ajoute si besoin l’année de production. Mention d’un cas où l’on a même tenté de faire de la déduplication de données humaines selon des critères comme la langue maternelle
Partage d’un exemple où les numéros de piste changent eux aussi avec le temps, avec lien vers la documentation Wikipédia Wikipédia sur les pistes
Avis selon lequel ces listes seraient toujours bien plus utiles avec des explications détaillées. Mais les sources liées contiennent beaucoup d’informations intéressantes, par exemple le cas où un code d’aéroport ICAO a été attribué à un cratère sur Mars (JZRO) Wikipédia sur le cratère Jezero, ainsi qu’un exemple de vol parti normalement mais retardé à l’atterrissage de 40 heures exemple de vol
Questionnement sur le fait que la combinaison constructeur-modèle-numéro de série semble tellement évidente qu’on se demande comment elle a pu être brevetée, et si quelqu’un en tire réellement profit aujourd’hui
Partage des difficultés très concrètes d’un développeur ayant travaillé sur un logiciel d’analyse de données de vol : hélicoptères et avions décollent et atterrissent dans toutes sortes d’endroits (hôpitaux, toits, parkings, terrains de sport, aéroports, golfs, etc.), si bien qu’on passe l’essentiel de son temps à naviguer dans « toutes sortes de mensonges sur l’aviation »
Point de vue selon lequel, chaque fois qu’on lit un texte de la série « Falsehoods... », il est frappant de voir combien de développeurs tombent dans l’illusion qu’un système centré sur l’humain suivra forcément des règles strictes
Les développeurs aiment tout ramener à un système de règles strictes, mais reconnaissent que le monde réel ne fonctionne pas ainsi
Analyse selon laquelle le métier même de programmeur consiste à servir d’interface entre des systèmes humains souples et des machines fondées sur des règles strictes
Partage du dilemme et de la confusion rencontrés lorsqu’on tente, en tant que programmeur, de modéliser le monde en logiciel en considérant certaines hypothèses comme évidentes, alors qu’en réalité elles ne tiennent pas du tout. Exemple : supposer qu’un vol a nécessairement un aéroport de départ et un aéroport d’arrivée
Affirmation selon laquelle, par nature, le logiciel doit impérativement transformer la modélisation du domaine en un ensemble de règles. Sans règles, aucune fonctionnalité n’est possible. Comme des exceptions telles que la leap second paraissent facilement absurdes au grand public lorsqu’on les explique, cela montrerait au contraire que les développeurs sont souvent très conscients des exceptions et de la complexité du monde
Proposition de traiter chaque élément de la série « Falsehoods Programmers Believe... » comme un cas de test. L’idée peut être étendue en tests unitaires et d’intégration pour vérifier les hypothèses erronées intégrées dans les programmes
Mention d’un cas où l’hypothèse « un vol décolle/atterrit dans un aéroport » était codée en dur dans un ancien système aérien brésilien, avec un exemple de contournement temporaire. Critique du fait que l’hypothèse « un aéroport/une piste ne change ni de position ni d’orientation » est elle aussi trop souvent supposée à tort. Proposition d’ajouter même l’hypothèse « les avions n’atterrissent que sur des pistes ou des héliports »
Partage d’une vidéo de CGP Grey qui résume bien le caractère chaotique des codes d’aéroport lien YouTube. Elle explique aussi les particularités propres au système
Présentation d’une discussion connexe sur le forum FlightAware traitant du même sujet lien vers le forum FlightAware
Partage du sentiment, du point de vue d’un programmeur, d’avoir trouvé toutes les hypothèses de cette liste raisonnables avant de découvrir douloureusement la réalité, avec l’impression que le cerveau explose. Éloge de la qualité du résumé