L’effondrement du système de contrôle aérien britannique

 (jameshaydon.github.io)
2 points par GN⁺ 2023-09-12 | 1 commentaires | Partager sur WhatsApp
  • Le 28 août 2023, une panne du FPRSA-R de NATS, l’opérateur britannique du contrôle aérien, a entraîné l’annulation de plus de 2 000 vols, pour un coût estimé à plus de 100 millions de livres sterling
  • Le plan de vol qui a déclenché le chaos était un plan valide accepté par l’IFPS d’Eurocontrol, et le système de NATS a tenté d’extraire le segment correspondant à l’espace aérien britannique en faisant correspondre les données ADEXP et la route ICAO4444
  • La cause directe était que deux waypoints géographiquement distincts portaient le même identifiant ; le FPRSA-R a associé à tort un identifiant dupliqué au point de sortie et n’a pas pu produire un segment britannique valide
  • Le système principal et le système de secours ont traité le même plan de vol avec la même logique, ont chacun généré une critical exception et sont passés en maintenance mode en moins de 20 secondes, interrompant le traitement automatique
  • Les aéronefs ont continué à être contrôlés en toute sécurité, mais le mode de défaillance qui a permis à un seul plan de vol d’arrêter tout le système de traitement automatique, le manque de tests et une procédure de reprise dépendante de logs de bas niveau restent problématiques

L’ampleur de la panne de NATS du 28 août 2023

  • NATS, l’opérateur britannique du contrôle aérien, a subi une panne technique majeure le 28 août 2023
  • Selon la BBC, plus de 2 000 vols ont été annulés, et le coût est estimé à plus de 100 millions de livres sterling
  • La panne a probablement touché des centaines de milliers de personnes
  • Les premiers articles de presse évoquaient la possibilité d’un « plan de vol erroné » ou d’une « erreur d’une compagnie aérienne française », mais le plan de vol à l’origine du problème était un plan conforme à ICAO4444 accepté par l’IFPS d’Eurocontrol
  • Le vol qui a ensuite été identifié comme ayant déclenché la panne était le French Bee FBU731, qui reliait LAX/KLAX à ORY/LFPO

Le cheminement d’un plan de vol jusqu’à NATS

  • La compagnie aérienne soumet son plan de vol à l’IFPS d’Eurocontrol
    • Une fois le plan de vol accepté par l’IFPS, l’aéronef peut décoller après autorisation du contrôle de l’aéroport de départ
    • À cette étape, aucune entrée de NATS n’est nécessaire
  • L’IFPS transmet le plan de vol aux prestataires de services de navigation aérienne concernés
    • NATS doit recevoir le plan de vol au moins 4 heures avant l’entrée de l’aéronef dans l’espace aérien britannique
    • Ces 4 heures servent de marge pour résoudre d’éventuels problèmes de traitement
  • Dans les opérations En-route de NATS au Swanwick Centre, les données sont transmises au FPRSA-R
    • Le FPRSA-R convertit les données au format ADEXP reçues de l’IFPS dans un format compatible avec le UK National Airspace System, ou NAS
    • Le NAS est un système de traitement des données de vol qui contient les informations relatives à l’espace aérien et aux routes concernés

Différences entre ICAO4444 et ADEXP

  • Un plan de vol ICAO4444 est un format lisible par machine et, si nécessaire, aussi par un humain
    • La partie route contient la vitesse, l’altitude, les waypoints, les noms de routes et des indications de vol direct comme DCT
    • Par exemple, N0440 signifie 440 nœuds, et F310 correspond au Flight Level 310
  • L’IFPS convertit les plans de vol ICAO4444 au format ADEXP avant de les transmettre
    • ADEXP inclut le plan de vol ICAO4444 d’origine ainsi que des waypoints géographiques supplémentaires pour les routes de la région européenne
    • Pour les vols qui traversent l’espace aérien britannique sans atterrir au Royaume-Uni, il peut aussi inclure des waypoints nécessaires à la suite du trajet en dehors du Royaume-Uni
  • Les RTEPTS d’ADEXP contiennent davantage de détails sur l’altitude et l’heure estimée de passage de chaque waypoint
    • Une route ICAO peut contenir 9 waypoints, tandis que la liste étendue ADEXP peut en contenir 21
    • Le départ et l’arrivée de la route ICAO étant indiqués dans des champs séparés, ils ne sont pas répétés dans la liste de route

Le waypoint dupliqué à l’origine de la panne

  • La liste de waypoints ADEXP en cause contenait deux waypoints géographiquement distincts ayant le même designator
    • L’ICAO et d’autres organismes ont travaillé à supprimer les noms de waypoints non uniques, mais il reste encore des noms dupliqués dans le monde
    • Les standards récents imposent que des waypoints portant le même identifiant soient très éloignés géographiquement
    • Dans cet incident, les deux waypoints étaient hors du Royaume-Uni ; l’un se situait au début de la route, l’autre vers la fin, et ils étaient séparés d’environ 4 000 milles nautiques
  • Dans le plan de vol étendu du vol FBU731 effectivement identifié, un waypoint nommé DVL apparaît deux fois
    • L’un correspond à Devil’s Lake, dans le Wisconsin, aux États-Unis
    • L’autre correspond à Deauville, en Normandie, en France
    • Ce dernier est présenté comme apparaissant en fin de vol lors de l’extension de la voie aérienne UN859

Le traitement du FPRSA-R et le point d’échec

  • Le FPRSA-R recherche d’abord le point d’entrée dans l’espace aérien britannique à partir des données de waypoints ADEXP
  • Il cherche ensuite le point de sortie de l’espace aérien britannique, puis tente de trouver le segment correspondant dans la section ICAO4444
  • La route ICAO n’a pas nécessairement besoin d’inclure le point de sortie de l’espace aérien
    • Le logiciel était conçu pour, si le point de sortie n’était pas présent dans la route ICAO, réessayer avec le point proche suivant dans le fichier ADEXP
  • Dans cet incident, le logiciel a suivi les waypoints suivants dans ADEXP et a trouvé un identifiant dupliqué présent dans la route ICAO
    • Mais cet identifiant ne correspondait pas au waypoint situé après la sortie réelle de l’espace aérien britannique ; il correspondait à un autre waypoint géographique situé au début de la route
    • En conséquence, l’ordre ou le segment entre le point d’entrée et le point de sortie n’était pas valide, et le système n’a pas pu extraire le segment ICAO correspondant à l’espace aérien britannique
  • Le rapport de NATS désigne ce point comme la root cause de l’incident et conclut qu’une contribution cyber peut être écartée

Pourquoi le système principal et le système de secours se sont arrêtés simultanément

  • Les logiciels critiques pour la sûreté sont conçus pour passer dans un état nécessitant une intervention manuelle lorsqu’ils ne peuvent pas continuer en toute sécurité
  • Le système principal FPRSA-R a estimé qu’il ne pouvait pas garantir l’exactitude des données du plan de vol et a déclenché une critical exception
    • Il a écrit un fichier de log dans les logs système
    • Il est passé en maintenance mode
    • Le système C&M a détecté que le système principal n’était plus disponible
  • Le système de secours était conçu pour prendre le relais en cas de défaillance du système principal
    • Il se trouvait sur un matériel séparé, avec une alimentation séparée et un flux de données séparé
    • Mais il a appliqué la même logique au même plan de vol et a produit le même résultat, en déclenchant une critical exception
  • Il a fallu moins de 20 secondes entre la réception du message ADEXP et le passage du système principal comme du système de secours en maintenance mode
  • À 08:32, le traitement automatique des plans de vol s’est arrêté, rendant nécessaire une saisie manuelle des plans de vol dans la marge de 4 heures

Procédure de reprise et impact opérationnel

  • L’équipe de support 1st Line a pris connaissance de la panne via le système C&M dédié, le système C&M central et les retours de l’équipe opérationnelle
  • La première réponse a consisté à suivre la procédure de reprise standard, qui redémarre les sous-systèmes via le système C&M central
    • Plusieurs tentatives de reprise ont échoué
    • L’équipe d’ingénierie 2nd Line est intervenue pour assister les ingénieurs sur site via une liaison vidéo à distance
  • Comme les équipes 1st Line et 2nd Line n’ont pas réussi à rétablir le service ni à identifier précisément la cause, l’équipe Technical Design et le support du fabricant du sous-système ont été sollicités
  • Le fabricant a analysé des logs logiciels de bas niveau pour identifier le plan de vol qui semblait avoir déclenché la panne
    • Après avoir compris ce plan de vol, il a fourni la procédure exacte permettant de restaurer le système de manière contrôlée et sûre
  • En cas de panne, des procédures de saisie manuelle et de coordination manuelle entre secteurs étaient prévues, mais le passage aux procédures manuelles imposait d’appliquer des restrictions de contrôle aérien pour réduire le trafic au Royaume-Uni

Frequentis AG et FPRSA-R

  • Le sous-système FPRSA existait chez NATS depuis plusieurs années, et en 2018, le système existant a été remplacé par un nouveau matériel et un nouveau logiciel de Frequentis AG
  • Frequentis AG est une entreprise autrichienne et l’un des fournisseurs de systèmes de contrôle aérien
  • Les produits ATC de ce fabricant seraient exploités dans environ 150 pays, et l’entreprise est réputée occuper une position mondiale dans les domaines de la gestion de l’information aéronautique et des systèmes de traitement de messages
  • Sur la page recrutement de Frequentis AG, Ada, C++, Java et Python apparaissent en lien avec les systèmes de contrôle aérien, Java semblant être le plus fréquent

Bug logiciel et problèmes de tests

  • Le FPRSA-R n’a pas réussi à extraire le segment ICAO correspondant à l’espace aérien britannique à partir d’un plan de vol valide accepté par l’IFPS
  • Les identifiants de waypoints ne sont pas uniques à l’échelle mondiale, et c’est un problème connu
    • Lorsque des waypoints dupliqués sont très éloignés, un plan de vol normal peut malgré tout rester non ambigu
    • Mais le logiciel aurait dû gérer cette condition de manière robuste
  • NATS a indiqué qu’il pourrait, via le gouvernement britannique, envisager de supprimer du jeu de données mondial géré par l’ICAO le petit nombre de noms de waypoints dupliqués liés à cet incident
  • Le CEO de NATS, Martin Rolfe, a déclaré à la BBC que cet incident avait une probabilité de « 1 sur 15 millions »
    • Il a précisé que le système avait été déployé en 2018 et avait depuis traité 15 millions de plans de vol
  • Dans un système critique pour la sûreté, les étapes de traitement des plans de vol, en particulier une étape importante comme l’extraction du segment britannique, devraient être testées
    • Des tests ne tenant pas compte des noms de waypoints dupliqués auraient pu ne pas révéler ce bug
    • Le fuzzing, consistant à injecter en masse des plans de vol aléatoires, aurait pu aider à trouver des entrées faisant passer le système dans un mauvais mode de défaillance

Le problème du mode de défaillance

  • Un seul plan de vol a arrêté tout le système de traitement automatique FPRSA-R, si bien qu’aucun plan de vol ne pouvait plus être traité automatiquement
  • Un meilleur mode de défaillance consisterait à envoyer le plan de vol problématique dans une file lente séparée pour qu’un humain le traite manuellement
  • NATS a indiqué que, parmi les mesures déjà engagées ou achevées, un filtre de messages spécifique serait ajouté au flux de données entre l’IFPS et le FPRSA-R afin de filtrer les plans de vol correspondant aux conditions ayant provoqué l’incident
  • Lorsque le FPRSA-R s’est arrêté, le plan de vol concerné n’a été identifié que dans des logs logiciels de bas niveau
    • Si, dans un système de traitement de plans de vol, une erreur de traitement d’un plan précis arrête tout le système, il serait plus approprié qu’une alerte incluant ce plan de vol soit immédiatement transmise à l’équipe de supervision
  • NATS a déclaré avoir établi des consignes opérationnelles permettant de rétablir rapidement le FPRSA-R si la même situation devait se reproduire, et que les opérateurs techniques avaient été formés à appliquer la nouvelle procédure
    • Une supervision renforcée et des experts techniques supplémentaires doivent également surveiller l’activité

Possibilité de vérification formelle

  • Il n’y a pas de signe clair que la vérification formelle ait été utilisée à l’étape et dans le système concernés par cet incident, et le rapport ne la mentionne pas
  • La vérification formelle ou le model checking auraient pu contribuer à réduire ce type de bug
  • Cela dit, la vérification formelle de bout en bout de systèmes de grande taille en est encore à ses débuts, et même si une vérification formelle partielle avait été utilisée, la possibilité qu’un code défectueux arrive en production demeurerait
  • Il faudra attendre les conclusions finales de l’enquête pour en savoir davantage sur les méthodes de vérification réellement utilisées

Sécurité et reporting public

  • Les aéronefs dans le ciel britannique sont restés en sécurité tout au long de l’incident
    • Des contrôleurs aériens expérimentés ont surveillé les aéronefs au moyen des plans de vol connus, de la radio, du radar et de la vue directe
    • Le résultat n’a pas été un risque pour les vies humaines, mais une situation où beaucoup moins de vols pouvaient décoller ou devaient contourner l’espace aérien britannique
  • NATS a maintenu la sécurité en prenant des mesures de réduction du nombre de vols
  • Le rapport public est assez transparent et détaillé, et ce type de reporting est important pour les infrastructures critiques
  • Michael O’Leary, de Ryanair, a critiqué ce rapport en le qualifiant de « rubbish » et en affirmant qu’il minimisait l’impact sur l’industrie aérienne, mais il existe aussi l’analyse selon laquelle le périmètre du rapport initial n’était pas d’évaluer l’ampleur des défaillances de NATS

Vers une implémentation plus robuste

  • Le problème consiste à gérer deux séquences de waypoints
    • ADEXP : la liste complète des waypoints
    • ICAO : une sous-séquence des waypoints ADEXP
  • Comme le plan ICAO ne contient pas nécessairement les points d’entrée et de sortie de l’espace aérien, trouver le plus petit segment continu de l’ICAO correspondant à l’espace aérien britannique n’est pas trivial
  • Le problème de l’algorithme incorrect est qu’il manipulait des pointeurs vers les données ICAO et ADEXP en même temps, tout en laissant hors du code des invariants qui n’étaient pas clairement définis
  • L’approche proposée consiste d’abord à faire correspondre les données ICAO et ADEXP dans une structure de plan de vol Combined, puis à en extraire le segment britannique
    • Calculer toutes les réconciliations possibles afin de détecter les cas ambigus
    • S’il y a 0 réconciliation, ICAO et ADEXP ne peuvent pas être mis en correspondance
    • S’il y en a plusieurs, le cas est ambigu et peut être destiné au traitement manuel
  • L’implémentation d’exemple en Haskell traite explicitement les erreurs NonUkPlan, CannotReconcileIcaoAdexp et AmbiguousReconciliationsOfIcaoAdexp
  • Dans l’exemple, même si la liste ADEXP contient l’identifiant dupliqué Q, si les données ICAO et ADEXP peuvent être mises en correspondance sans ambiguïté, le segment britannique correct est renvoyé
  • Le code complet est disponible sur uk-portion-of-ICAO

À lire aussi

1 commentaires

 
GN⁺ 2023-09-12
Avis de Hacker News

  • En gros, ils ont omis de limiter géographiquement le périmètre de la requête de plan de vol. Quand je travaillais autrefois sur des systèmes de navigation aérienne, je connaissais ce bug, je l’avais déjà vu en pratique, et j’ai appliqué une spécification imposant d’ajouter une géoclôture pour l’éviter.

    • Si les noms de points de navigation ne sont pas uniques à l’échelle mondiale et que les routes interrégionales sont courantes, je ne comprends pas pourquoi on n’a pas attribué de GUID à ces points de navigation.
    • Par curiosité, j’aimerais savoir quel langage a été utilisé pour le développement.
    • La norme ICAO précise depuis 1978 que, si des identifiants sont dupliqués, ils doivent être séparés d’au moins 600 milles nautiques (690 miles, 1 100 km).

  • Le passage problématique, c’est : « le système de secours a appliqué la même logique au plan de vol et a obtenu le même résultat ». En logiciel, un système de secours devrait utiliser une logique différente.
    Autrefois, chez Boeing, quand je travaillais sur le système de compensation du stabilisateur du 757, deux ordinateurs avioniques étaient reliés au câblage qui activait la compensation, via un comparateur. Si les deux boîtiers n’étaient pas d’accord, les deux perdaient leur autorité.
    Les deux boîtiers étaient conçus avec des algorithmes différents, des langages de programmation différents, des CPU différents, et du code écrit par des équipes différentes, séparées par un pare-feu, afin qu’un bug d’un côté ne puisse pas casser l’autre de la même manière.

    • Cela devait être un système 2oo2 avec le pilote comme solution de secours, mais le 2oo2 n’offre pas une grande disponibilité.
      Un système de contrôle aérien devrait au minimum être en 2oo3[1], c’est-à-dire avec 3 systèmes développés indépendamment, dont 2 doivent toujours être d’accord. Ainsi, même si un système tombe en panne, les deux autres continuent à fonctionner, sans affecter la disponibilité du secteur aérien.
      Mettre des humains en secours est impossible à cause des besoins en personnel et de la complexité. Un système de contrôle aérien doit pouvoir assurer la séparation en conditions IFR[2] et CVFR[3].
      [1] https://en.wikipedia.org/wiki/Triple_modular_redundancy
      [2] https://en.wikipedia.org/wiki/Instrument_flight_rules#Separa...
      [3] https://en.wikipedia.org/wiki/Visual_flight_rules#Controlled...
    • C’est aussi la première chose à laquelle j’ai pensé en lisant. Ce système de bascule en cas de panne semble avoir été conçu pour atténuer les pannes matérielles plutôt que les bugs logiciels.
    • « Quand un système de sécurité échoue, il échoue d’une manière qui n’est pas fail-safe. »
      J. Gall
    • Des équipes différentes font souvent la même erreur. Ce n’est pas une architecture parfaite, mais l’approche décrite semble pertinente.
    • À côté de ça, il est regrettable que cette approche n’ait pas été réutilisée sur le MAX alors qu’elle était connue.

  • Je crois me souvenir qu’il y avait eu chez NATS un autre problème produisant le même effet. Le système primaire est tombé, on a basculé sur le secondaire, et le secondaire est tombé exactement pour la même raison.
    Il me semble qu’il ne faut basculer que lorsqu’on sait que le problème vient du système primaire lui-même, et non du logiciel. Une bascule automatique renforce surtout l’impression que le système n’exposait pas assez d’informations pour décider de ce qu’il fallait réellement faire.
    Ce qui est encore plus inquiétant, c’est qu’il n’existait apparemment pas de méthode du type « ValidateFlightPlan » : si le plan ne pouvait pas être analysé pour une raison quelconque, une erreur était levée, sans chemin de traitement très simple pour gérer cette erreur. Quel programmeur peut regarder un gestionnaire d’entrées externes sans se demander : « que fait-on si une mauvaise entrée casse tout ? »

    • Si l’on sait que le système primaire n’est pas dans un état normal, on peut tenter une bascule en espérant que ce soit un disque grillé ou un bit retourné par un rayon cosmique.
      La vraie fonction de sécurité, c’est le délai de 4 heures avant que le traitement manuel ne devienne nécessaire.
      Dans l’aérien, le contrôle de sécurité essentiel relève moins de « comment éviter que ça casse au départ » que de « que fait-on si ça casse, quelle qu’en soit la raison ».
    • Outre l’absence de validation, ce passage de l’article m’a marqué.
      Le style de programmation paraît très impératif et, d’après la description, on dirait que la procédure manipule directement la représentation textuelle du plan de vol, plutôt qu’une structure de données issue du parsing d’un fichier texte. Si c’est vraiment le cas, c’est assez inquiétant, même si cela vient peut-être simplement de la façon dont c’est décrit.
      Avec une telle description, je ne serais pas surpris qu’ils fassent simplement tourner des expressions régulières ou des recherches de sous-chaînes sur du texte, sans classes, objets ni structures de données. Il faut aussi envisager la possibilité qu’il s’agisse de code C vieux de plusieurs décennies, dont dépend toute l’aviation britannique, et qu’on ne peut ni réécrire ni remplacer.
    • Comme il n’y a aucun moyen de déterminer que le matériel n’est pas en cause, la bascule elle-même était correcte. En revanche, il aurait fallu mieux concevoir la réaction au second échec pour éviter l’effet en chaîne.
    • D’un point de vue électrique, c’est comme remplacer un fusible puis le regarder sauter à nouveau. Et le magasin n’a plus de fusibles. Est-ce un progrès ?
    • L’échec du lancement d’Ariane 5[1] était un problème similaire, avec un résultat beaucoup plus spectaculaire.
      Le système primaire a échoué à cause d’un dépassement d’entier, et le système secondaire identique a débordé lui aussi. L’angle d’attaque a augmenté, les boosters se sont séparés, et la fusée a explosé.
      [1] https://en.wikipedia.org/wiki/Ariane_flight_V88

  • Je ne comprends pas pourquoi seuls les plans de vol en échec ont été placés dans une file d’attente de revue humaine, au lieu de continuer à traiter les autres vols. Le plus difficile à comprendre, c’est que cette « fonctionnalité » n’existait pas.

    • Le code a classé cette erreur comme « ça ne doit absolument jamais arriver ! », et c’est précisément ce qui est arrivé. Il ne l’a pas classée comme « données de plan de vol incorrectes » ni comme « données correctes, mais pas encore prises en charge ».
      Quand une erreur « ça ne doit absolument jamais arriver » se produit, le système ne peut pas savoir ce qui ne va pas, ni l’ampleur et l’étendue de l’impact. Comme ici, il aurait peut-être été possible de continuer, mais il aurait aussi pu s’agir d’un nouveau bug critique dans le logiciel, corrompant silencieusement tous les autres plans de vol et tuant des gens. Si on ne sait pas s’il est sûr de continuer, il faut s’arrêter.
    • Pour être juste, le début de l’article indique que ces plans de vol peuvent aussi concerner des appareils déjà en vol. Ils sont certes à au moins plus de 4 heures du Royaume-Uni, mais tout de même.
      Si l’on peut empêcher l’avion concerné de décoller, il peut être acceptable de laisser tourner le système ; s’il est déjà en l’air, c’est une autre histoire.
      Le raisonnement « un appareil en route vers l’espace aérien britannique va y entrer, mais on ne sait pas quand ni où ; on suspend les plans de vol supplémentaires jusqu’à connaître sa position » n’est pas totalement déraisonnable.
      Si le plan de vol ne peut vraiment pas être traité, une solution raisonnable pourrait consister à dérouter l’appareil et à le faire atterrir avant qu’il n’atteigne le Royaume-Uni, mais cela implique de toute façon d’attendre une intervention manuelle.
    • L’article comme l’analyse post-incident ont tous deux identifié le mauvais mode de défaillance du système FPRSA-R comme le problème principal, et c’est à mon avis le point le plus important.
      Tous les systèmes peuvent dysfonctionner ; l’essentiel est qu’ils dysfonctionnent de la bonne manière et que les responsables soient préparés à cette situation.
      Un seul plan de vol a posé problème, et tout le système FPRSA-R s’est arrêté, si bien qu’aucun plan de vol n’a plus été traité. Lorsqu’un plan de vol pose problème, il devrait être déplacé vers une file d’attente distincte et plus lente pour traitement manuel. NATS reconnaît aussi, dans les « mesures déjà prises ou en cours », qu’il ajoute un filtre de messages dans le flux de données entre IFPS et FPRSA-R afin d’intercepter les plans de vol correspondant à cette condition.
    • Dans un système critique pour la sécurité, face à une « erreur inconnue », il faut supposer que tous les invariants ont été violés et que l’on est entré dans un comportement indéfini ; il n’y a donc pas d’autre choix que de s’arrêter.
      Dire que cela aurait dû être traité comme une erreur connue est valable, mais, plus largement, cela revient un peu à dire « il aurait fallu écrire du code sans bug ». Même si les données avaient été parsées dans une structure, cela pourrait être l’équivalent d’un code qui suppose la présence d’une clé optionnelle et voit soudain surgir une KeyError.
      L’analyse post-incident et les améliorations de ce genre d’événement doivent partir du principe qu’une erreur inconnue non gérée et imprévisible finira un jour par se produire, et se demander comment mieux la gérer à ce moment-là. La solution au bug est de corriger le bug, mais la cause de la panne majeure était un plan de reprise après sinistre impossible à exécuter dans un délai raisonnable. Quels que soient les pratiques, le style, le langage ou les outils de programmation utilisés, un incident d’un niveau comparable finira avec une probabilité de 1 par se reproduire un jour, même avec les meilleurs développeurs.
    • Il est très probable que l’algorithme décrit dans l’article ne soit pas un simple code procédural suivant dans l’ordre les points de cheminement du plan de vol en entrée. Une abstraction a peut-être masqué le fait qu’il s’agissait d’une erreur d’entrée.
      Si, du point de vue du code, cela ressemblait à une défaillance d’intégrité de la base de données sous-jacente des points de navigation, la décision d’interrompre le traitement des plans de vol devient beaucoup plus compréhensible.
      Par exemple, si le code demande au référentiel des points de cheminement et des routes « trouve-moi le point de cheminement où cette route sort de l’espace aérien britannique », trouve ensuite le segment de route contenant ce point, puis affirme que ce segment traverse l’espace aérien britannique, et que cette assertion échoue, cela peut ressembler non pas à un problème de plan de vol, mais à une hypothèse intégrée aux données de route qui vient d’être invalidée.
      D’une certaine manière, il est même possible qu’il s’agisse réellement d’un bug critique. Cet incident montre que les hypothèses formulées par l’algorithme à propos des données étaient fausses et qu’il pouvait potentiellement renvoyer une réponse incorrecte.

  • Articles liés
    Le système britannique de contrôle aérien trompé par deux points de cheminement portant par hasard le même nom - https://news.ycombinator.com/item?id=37430384 - septembre 2023, 64 commentaires
    De mauvaises données de plan de vol ont provoqué la panne du contrôle aérien britannique - https://news.ycombinator.com/item?id=37402766 - septembre 2023, 20 commentaires
    Le rapport d’incident de NATS sur le contrôle aérien détaille la cause racine et les solutions - https://news.ycombinator.com/item?id=37401864 - septembre 2023, 19 commentaires
    Panne du réseau de contrôle aérien britannique - https://news.ycombinator.com/item?id=37292406 - août 2023, 23 commentaires

    • Après avoir écouté le récent épisode de The Daily sur l’industrie aérienne américaine, je suis convaincu qu’on verra bientôt un titre de presse catastrophique. On ne peut pas continuer comme ça.
    • En voyant le titre de cet article, j’ai cru qu’il s’agissait d’une nouvelle panne qui venait de se produire.

  • Le fait qu’ils aient accusé un plan de vol français déjà accepté par Eurocontrol prouve qu’ils ne comprenaient pas correctement le fonctionnement de leur logiciel. Et l’entreprise autrichienne doit aussi assumer une part de responsabilité pour le manque de tests intensifs.

    • C’est juste parce que c’est le Royaume-Uni qu’ils ont accusé la France. Les mauvaises habitudes ont la vie dure.

  • Excellent article. À la lecture, l’essentiel me semble être ceci :
    les noms de waypoints utilisés dans le monde entier ne sont pas uniques et, comme une sorte de rustine pour éviter les confusions, les normes récentes demandent que les mêmes identifiants soient suffisamment éloignés géographiquement. Malgré cela, sur une même route aérienne, un même nom de waypoint peut désigner des positions différentes.
    Le logiciel n’a pas pris cette possibilité en compte, le calcul de route a échoué, il a levé une « exception fatale » et est passé en « mode maintenance ». Autrement dit, il est mort.
    Le système de secours a pris le relais, mais avec les mêmes données il a rencontré le même bug et est mort lui aussi ; les équipes de support ont galéré. Au final, ce n’est qu’après avoir contacté le fournisseur du logiciel qu’ils ont trouvé des logs de bas niveau révélant la cause.

    • Je ne comprends pas pourquoi, pour un système critique pour la mission de ce niveau, il n’y a pas quelqu’un à l’aise avec le code d’astreinte 24 h/24 et 7 j/7.
    • Le point central est l’absence d’un espace de noms approprié. Qui aurait cru que les ingénieurs en aéronautique et spatial devraient étudier les systèmes d’exploitation ?
      Un ami, ancien pilote de l’armée de l’air, est diplômé de Cranfield University ; c’est l’un des principaux établissements britanniques de troisième cycle en ingénierie aérospatiale, avec son propre aéroport pour l’enseignement et la recherche[1]. Il m’avait dit avoir étudié les systèmes d’exploitation à Cranfield, et je comprends enfin pourquoi.
      À lire les autres commentaires, il existe déjà une norme d’espace de noms, mais NATS/ATC ne semble pas l’utiliser. J’espère que cet incident les poussera enfin à s’en servir. Le commentaire le mieux classé parlait d’un bug de géorepérage, mais si NATS/ATC utilisait un espace de noms correct, le géorepérage n’aurait probablement pas été nécessaire au départ.
      [1] Cranfield University :
      https://en.wikipedia.org/wiki/Cranfield_University

  • « À lire l’explication, on dirait que la procédure manipule directement la représentation textuelle du plan de vol, plutôt qu’une structure de données parsée depuis un fichier texte. Si c’est vraiment le cas, c’est assez préoccupant, mais cela vient peut-être simplement de la manière dont c’est expliqué. »
    Dans les travaux liés à l’industrie aéronautique, cette approche est courante. Si vous demandez à des programmeurs ce qu’il en est du modèle de domaine ou du parsing, ils vous regardent souvent d’un air vide. Ils aiment le code de validation et, si la validation échoue, ils aiment simplement abandonner. Tout n’est qu’un pipeline de données stupide, sans aucun code qui modélise les activités du monde réel.
    Dans aucun système on ne trouve de type « plan de vol » doté d’un comportement, ni d’ensemble de types de waypoints. Même quand un type existe, c’est une structure de chaînes à la manière du C, et chaque membre de cette structure est parsé non pas une fois, mais à chaque accès. Comme le dit l’article, « le style de programmation semble très impératif ».

    • Abandonner en cas d’échec de validation est toutefois une approche standard pour éviter de propager des données mal interprétées et de créer des bugs bien plus complexes. Il faut valider tôt, valider strictement, signaler les erreurs, et ne pas essayer d’interpréter de force ce qui ne va pas dans l’entrée. Dès qu’on essaie d’être « intelligent », on ouvre des failles de sécurité.
      Mourir sur une mauvaise entrée est une erreur, mais essayer d’interpréter des données non validées sans spécification conduit facilement ensuite à des divergences de compréhension, à des problèmes de compatibilité et à des conditions limites inattendues. Personne ne veut payer pour un système qui couvre tous les cas entièrement testés, des outils de simulation d’entrées invalides, ni pour la vérification formelle du parseur et de tout le code qui utilise ses résultats.
      Il y a déjà beaucoup de problèmes à cause des émetteurs de données non conformes, legacy ou bogués, ainsi que de la sémantique des interfaces et de la complexité du timing. Essayer de réagir intelligemment à des données mal formatées ou mal encodées devient encore plus dangereux.
      Construire un système qui fonctionne selon la spécification est déjà difficile et coûteux. Les variantes subtiles qui acceptent plus généreusement des comportements non spécifiés, c’est soit demander des bugs, soit construire un système plus cher qui ne passera pas le critère du prix d’achat.
    • Très intéressant, et aussi un peu effrayant. C’est fascinant de voir que différentes industries ont développé chacune leur propre culture de développement, pour des raisons pas forcément très claires.

  • « Contrôle aérien britannique : enquête pour déterminer si une erreur française a provoqué la panne »
    Bien sûr que non. C’est un système britannique : comment cela pourrait-il être la faute d’une compagnie aérienne française ? Un tel système devrait avoir une architecture tolérante aux erreurs avec redondance.
    Il aurait peut-être suffi de rejeter l’élément problématique et de continuer.

    • Si l’on veut vraiment raisonner en termes nationalistes, le logiciel était autrichien.

  • Une journée que je n’ai pas envie de revivre. Il m’a fallu 15 heures pour atteindre une destination qui devait normalement prendre 2 heures.
    J’ai pris le train, le bus, puis encore le train ; trente minutes après avoir réservé mon billet, tout était complet pour les deux jours suivants.

    • J’ai attendu 6 heures à l’aéroport avant d’apprendre que le vol était annulé, et j’ai dû réserver à nouveau. Comme j’allais à New York voir ma famille, il n’y avait pas vraiment d’autre moyen de transport.