Connexion Abonnez-vous

Airbus A320 cloués au sol : après l’alerte, les avions reprennent du service

Alerte rouge sur un vendredi noir

Airbus A320 cloués au sol : après l’alerte, les avions reprennent du service

Airbus avait alerté vendredi soir d'une défaillance de sécurité impliquant une intervention immédiate sur les 6 000 avions A320 en circulation dans le monde, en raison d'un logiciel de commande vulnérable aux radiations solaires. Lundi matin, la situation semble revenue à la normale au terme d'un week-end perturbé : seule une centaine d'appareils restent en attente de modifications, affirme l'avionneur.

Le 01 décembre à 12h45

L'alerte, émise vendredi en fin de journée par l'Agence européenne de la sécurité aérienne (EASA), laissait redouter un week-end d'intenses perturbations chez les compagnies aériennes du monde entier.

Suite à un incident relevé le 30 octobre dernier à bord d'un Airbus A320 opéré par Jetblue, l'autorité a en effet déclenché une consigne d'urgence imposant une intervention immédiate sur l'ensemble des appareils de la famille Airbus A320, l'avion mono-couloir le plus vendu au monde, avec environ 6 000 exemplaires en exploitation commerciale dans le monde.

Un calculateur perturbé par une éruption solaire

Dans son alerte, immédiatement répercutée par son homologue américaine la FAA, l'EASA indiquait agir sur la base d'une alerte transmise par l'avionneur Airbus, qui a lui-même communiqué publiquement sur le sujet vendredi.

« L'analyse d'un incident récent impliquant un appareil de la famille A320 a révélé qu'un rayonnement solaire intense peut corrompre des données essentielles au fonctionnement des commandes de vol. Airbus a par conséquent identifié un nombre important d'appareils de la famille A320 actuellement en service qui pourraient être concernés ».

La note d'information de l'EASA décrit plus en détails le phénomène rencontré.

« Un Airbus A320 a récemment subi une brève descente en piqué non sollicitée. Le pilote automatique est resté engagé durant tout l'incident, entraînant une perte d'altitude brève et limitée. Le reste du vol s'est déroulé sans incident ».

L'incident en question s'est produit le 30 octobre dernier. Il concernait un A320-200 opéré par Jetblue sur son vol 1230, reliant Cancun, au Mexique, à Newark, dans le New Jersey. L'avion avait connu une perte subite d'altitude, avant que le vol reprenne son cours. Par précaution, les pilotes avaient alors décidé de se dérouter vers l'aéroport de Tampa, en Floride, où une quinzaine de personnes ont été examinées pour d'éventuelles blessures, rapportait Reuters le 31 octobre dernier.

Il aura a priori fallu près d'un mois pour que l'enquête associée livre ses conclusions. En l'occurrence, l'EASA parle d'une « vulnérabilité introduite par une mise à jour logicielle » au sein de l'un des composants de l'avion, le calculateur de gouverne de profondeur (ELAC).

En cause : une mise à jour logicielle

La note diffusée par Airbus aux compagnies aériennes le 28 novembre confirme : « L'enquête ultérieure a identifié une vulnérabilité du matériel ELAC B équipé du logiciel L104 en cas d'exposition aux éruptions solaires », indique l'avionneur, qui ordonne donc la restauration sans délai à la version précédente du logiciel, la L103+.

Airbus n'a pas précisé qui était le fournisseur de l'ELAC concerné, mais Thales, qui revendique sur son site fournir le calculateur de gouverne de la famille A320, semble un candidat tout indiqué. Le groupe français a cependant décliné toute responsabilité. « La fonctionnalité dont il est question est portée par un logiciel qui n'est pas de responsabilité Thales », a indiqué vendredi l'un de ses porte-paroles à l'AFP.

Comment une mise à jour logicielle a-t-elle pu rendre sensible un calculateur aux radiations solaires ? En attendant l'éventuelle divulgation des détails techniques, il est permis de supposer que la mise à jour a altéré le fonctionnement d'un mécanisme de contrôle de l'intégrité des données, qui aurait sans doute pu, et dû, détecter la survenue d'une anomalie.

Retour à la normale

Du fait de sa nature logicielle, le problème a pu être corrigé rapidement sur la plupart des appareils concernés. Lundi matin, Airbus a en effet déclaré que « sur un total d'environ 6 000 avions potentiellement concernés, la grande majorité a désormais bénéficié des modifications nécessaires ». Il resterait une centaine d'appareils en attente de correction, précise l'avionneur, dont le CEO a publiquement présenté ses excuses sur LinkedIn.

Guillaume Faury, CEO d'Airbus, a présenté samedi ses « sincères excuses » aux passagers et aux compagnies concernés - capture d'écran Next

Si de nombreux vols ont été retardés en Europe ce week-end et si certains passagers ont eu la surprise de voler à bord d'un Boeing 777 pour rallier Toulouse depuis Paris Charles-de-Gaulle lundi matin, l'incident ne semble pas avoir d'impact significatif en matière d'activité aérienne d'après les statistiques d'Eurocontrol. Aux États-Unis, où les festivités de Thanksgiving battent leur plein, plusieurs centaines de vols ont été annulés.

Hasard du calendrier, le parquet général a réclamé mercredi 26 novembre la condamnation d'Airbus, en tant que constructeur, et celle d'Air France, en tant qu'exploitant, dans le procès en appel qui fait suite au crash du vol AF 447 survenu le 1er juin 2009.

Commentaires (39)

votre avatar
Pour moi ça donne une meilleure image que ce que Boeing avait fait avec leur MCAS pour leur Max.
Là on a un correctif dès la première occurence et entre Octobre et Novembre il y a pas eu d'autre incidents constaté par Airbus donc tant mieux.
Dans l'aérien on sait qu'il vaut mieux ne pas transiger avec la sécurité.
votre avatar
Il faut dire quand même que là, pour Airbus c'est plus facile de faire un rollback vers la version précédente du logiciel que pour Boeing de changer complètement la conception d'un avion mal branlé depuis le départ.
votre avatar
Oui et il s'agit pas non plus de rappeler des Airbag Takata on est d'accord.

Mais bon prendre les bonnes décisions dès le départ ça semble payer?!
votre avatar
« La fonctionnalité dont il est question est portée par un logiciel qui n'est pas de responsabilité Thales »
Qu'elle est donc l'entreprise à qui fait appel Thales pour développer le logiciel ?
#OnVeutDesNoms :D
votre avatar
Pour simplifier, Thales fait le matos, assure que c'est compatible avec le reste, etc... Mais le logiciel, dans son code, est fait par Airbus. Ils ont de très nombreux brevets là dessus.
votre avatar
Des équipes de développement directement chez Airbus ? Je n'y crois pas ! Ils sous-traitent aussi cette partie à des entreprises.
votre avatar
Des équipes de développement directement chez Airbus ? Je n'y crois pas ! Ils sous-traitent aussi cette partie à des entreprises.
Les commandes de vol primaires et secondaires sont (parmis) les derniers bastions du développement interne à Airbus. Et c'est sans rentrer dans les détails de quel code est généré automatiquement (à partir de planches logiques de CAO comme Scade) vs. quel code est manuel.

Et Airbus sur certains aspects des commandes de vol garde aussi une maitrise du hardware (i.e. une spécification plus détaillée que "faite moi une boite qui sache calculer à telle ou telle vitesse avec telles I/Os").

Plein d'autres systèmes sont en effet plus sous-traités que ça (fonctions/spec bas niveau/code....).
votre avatar
Effectivement, d'ailleurs chaque projet de dev est TRES documenté, pour éviter des surprises quant à la propriété intellectuelle : qui fait quoi, sur quelques ordres, le client garde tout ou pas etc...

Thales qui produit des calculateurs, essaye d'ailleurs de recycler au max le hardware en le vendant à d'autres avioneurs, et Airbus n'aime pas ça. Mais les normes sont tellement nombreuses et obligatoires pour tout le monde, du hardware comme ça t'envie de rentabiliser. Sans vendre du code ou savoir-faire de ton principal client. C'est sportif ^^
votre avatar
Ah ok ! Mea culpa. Je ne savais pas pour cette partie là. Merci de l'info ☺️
votre avatar
Si c'était Thales qui avait fait appel à une société pour développer le logiciel, ce logiciel serait quand même sous sa responsabilité.
Thales doit fournir le calculateur sans logiciel à Airbus et c'est Airbus qui a dû choisir la société qui a développé le logiciel. C'est probablement une grosse ESN qui sait développer pour l'aviation.
votre avatar
au hasard: Altran en sous-traitance ?

Mais bon, ca a p-e changé depuis 10ans.
votre avatar
Altran, SQLI, Sopra-Steria, etc. Ils ont pas mal de boites en sous-traitance qui font du dev pour eux oui ! D'où #OnVeutDesNoms 😝
votre avatar
j'allais le dire :D un peu beaucoup d'ailleurs, à la fin tu passes ton temps à parler avec des ext alors que tu pensais avoir des interlocuteurs internes.
votre avatar
Les événements de radiations (de type éruption) peuvent émettre des particules (protons, électrons) pouvant affecter des systèmes électroniques très denses en haute altitude, comme on en voit aujourd'hui. Cela peut déclencher des Single Event Upsets (SEU) tels que des bit-flips (en gros une anomalie dans les mémoires). En aéronautique, le phénomène est rare mais connu depuis quelques temps (la FAA les recense depuis 20 ans, et on en parle depuis au moins 1998), et il faut en tenir compte pour certains appareils électroniques. Les logiciels pilotant de tels systèmes doivent prendre en compte ce phénomène rare pour effectivement vérifier l'intégrité de la mémoire et en gérer une éventuelle corruption. Pas toujours facile, et surtout pas facile à tester. A priori le "L104" a un défaut que la version précedente n'avait pas...

Les avions sont plus sensibles que les appareils terrestres, car en haute altitude avec une atmosphère moins dense, les radiations sont plus fortes. Côté éditeur/fournisseur, ça peut être Airbus (très probable) ou Collins Aerospace (peu probable), mais sans aucune certitude (à part que ça n'est pas Thalès).

Dernière info : 900 appareils ont quand même besoin d'une mise-à-jour matérielle.
votre avatar
Merci Jean pour les précisions !
le nombre de 900 avancé au départ a été révisé à la baisse dès dimanche : probablement la centaine d'appareils qui restent à mettre à jour, même si airbus n'a pas confirmé à ce stade
votre avatar
C'est quand même mieux de clouer des avions au sol pour faire la mise à jour, plutôt que d'avoir des avions en pièces détachées au sol.
votre avatar
C'est plus difficile à reclouer ensuite, quand ils sont en pièces détachées.
votre avatar
Un gros lego !
votre avatar
Un gros lego !
C'est la blague en vogue chez Airbus et ses sous-traitants...
"- Quelle est la meilleure façon de se construire un Boeing en kit ?"
"- Attendre que les pièces nécessaires tombent du ciel !"
votre avatar
Le fameux "lithofreinage abrupte" : une solution de décélération parmi les plus efficaces.
votre avatar
Curieux de connaître la tronche de ce genre de correctif!
votre avatar
Le voici : ";"
:windu:
votre avatar
Là, c'était facile : revenir à la version précédente.

La version suivante sera plus compliquée à faire : reprendre les améliorations de la version fautive sans les bugs introduits. J'ai l'impression que les tests vont être approfondis.
votre avatar
La version suivante sera plus compliquée à faire : reprendre les améliorations de la version fautive sans les bugs introduits. J'ai l'impression que les tests vont être approfondis.
Oui. Après, sur un ELAC d'A320 (pas "NEO") y a des chances que les mises à jour soient du peaufinage frisant avec le pinaillage, la correction de bugs rares et obscures et que 1) cette mise à jour L104 ne soient pas d'une importance capitale et 2) qu'on prenne le temps de refaire bien.

Après, si ça se trouve c'est un flag de compilateur du type "vérifie le CRC de chaque mot en mémoire à chaque fois que tu bouges le petit doigt" qui a été oublié. et que donc la correction soit à la fois évidente, immédiate, mais que ça prenne quand même 3 lurettes et demi à arriver en service.
votre avatar
Après, si ça se trouve c'est un flag de compilateur du type "vérifie le CRC de chaque mot en mémoire à chaque fois que tu bouges le petit doigt" qui a été oublié. et que donc la correction soit à la fois évidente, immédiate, mais que ça prenne quand même 3 lurettes et demi à arriver en service.
oui ça pourrait être ça (quoi que normalement les flags du compilo sont là une fois pour toute, tu ne t'amuses pas à bricoler à chaque release), mais ça peut aussi être une màj de la chaine de compilation qui a changé une valeur par défaut d'un flag. (précédemment par défaut le CRC était activé, depuis la version x le flag est désactivé par défaut -ou a changé de nom-)

ou une erreur de code localisé dans le module, genre l'oubli de l'appel d'une méthode spécifique de contrôle "CRC" après réception d'un message extérieur, c'est déjà plus gênant ce genre d'erreur est détectable par les outils d'audit statique de code. (donc ça veut dire qu'ils sont défaillants)
votre avatar
c'est glucose !
votre avatar
Fallait pas désactiver l'ECC... ou en masquer la remontée d'erreur! :nonnon:
votre avatar
Il a quelque chose que je ne saisi pas, si quelqu'un peut m'éclairer c'est avec plaisir :
Si le correctif est de revenir à la version précédente, pourquoi il faut faire une mise a jour matérielle pour certains appareils ?
votre avatar
Parce qu'il n'est pas toujours possible suivant le modèle de faire la mise à jour logiciel sans changer le matériel.
Pour certains, on ne peut pas télécharger le logiciel à distance et parmi ceux-là certainsne peuvent pas non plus être mis mettre à jour en connectant un PC (ou autre appareil, je n'ai pas le détail) pour faire la mise à jour. Il faut donc récupérer le calculateur pour le mettre à jour.
votre avatar
Voilà
En gros certains vieux calculos ont leur mémoire morte en EPROM et autre joyeusetés et donc effaçable en retour OEM uniquement avec des appareils qui courent pas les rues. (en gros comme décrit ici .
Donc la compagnie aérienne en a 1 ou 2 qui trainent et va racker/déracker la carte mémoire à tour de bras pour faire tourner les calculos flashé et remplacer les calculos pas encore flashés. Me semble que "mise à jour matérielle" est un abus de language en tout cas dans le sens où on l'entend nous en informatique d'habitude. C'est pas un nouveau développement qui vient corriger le problème.

Les (autres) joyeusetés du dataloading et de la mise à jour centralisée apparaissent (si mes souvenirs sont corrects) avec le A380 quelques années plus tard.
votre avatar
Voilà que les tôles du fuselage en rajoutent maintenant, comme disait l'autre, ça vole en escadrille, c'est le cas de le dire.
votre avatar
faut avouer que niveau loi des séries sont pas mal là :D (pour ceux qui n'auraient pas l'info : https://www.wsj.com/business/airlines/airbus-suffers-new-quality-issue-days-after-software-glitch-cafa2440)

cette alerte là devrait quand même faire moins de bruit
votre avatar
The aerospace sector has been on high alert for potential quality issues after Boeing’s yearslong battle to overcome a run of production challenges. Airbus customers have also been left frustrated by delivery delays and a large-scale metal contamination problem on engines manufactured for the latest generation A320neo family.

Ah, le métal des panneaux avant des A320, les moteurs (CFM ? ) pas conformes, le bug logiciel... Bon après ça arrive après le scandale de Boeing, sur la même gamme d'avions. Accessoirement les plus vendus au monde.

Je pense qu'à la FAA et AESA, il y a comme un redflag dès que c'est du A320 / B-737 ^^
votre avatar
Ça rappelle le vol Qantas 72 fr.wikipedia.org Wikipedia
votre avatar
Les symptômes ressemblent beaucoup, en effet.
votre avatar
L'avion a piqué, y compris en pilotage manuel, car les infos de la référence inertielle ont été par moment totalement à l'ouest ce qui a déclenché, à tords... des protections normalement destinées à faire rester l'avion dans son domaine de vol.
Bref, la cause c'est pas un calculo de commande de vol qui déconne tout seul comme un grand mais une info fondamentale qu'on lui envoie qui est fausse.
Comme y'a 2 références inertielles, ça sentait plutôt le gag de conception qui fait qu'on n'a pas coupé ces protections quand les deux ne sont pas d'accord.
Je ne sais pas si la protection facteur de charge (avoir atteint 0.8g en négatif à haut mach, c'est quand même déjà significatif) est dépendante de ces références inertielles ou indépendante. Mais si elle dysfonctionne aussi le risque supplémentaire aurait pu être des dommages structurels voir la rupture en plein vol.
Airbus avait à mon sens eu bien de la chance sur ce coup.
Ça doit être assez inconfortable pour les pilotes de se retrouver dans cette situation, surtout que ça ne semble pas avoir suffit à passer en lois directes (avec le 2nd jeu de calculateurs de commandes de vol, plus simples et indépendant du primaire) qui amènent à beaucoup moins piloter "à travers les ordinateurs".
votre avatar
gestion exemplaire d'une crise
votre avatar
Ça peut être en effet un flip bit. N'hésitez pas à regarder la vidéo de Veritasium dessus, elle est plutôt bien faite. youtu.be YouTube
votre avatar
Je préfèrerais une enquête d'agence officielle plutôt que des spéculations individuelles aux fins d'être rémunéré par des vues sur une plateforme.

Le BEA indique que c'est le NTSB qui est en charge, mais rien de trouvé sur le site Web de cette-dernière entité…

Airbus A320 cloués au sol : après l’alerte, les avions reprennent du service

  • Un calculateur perturbé par une éruption solaire

  • En cause : une mise à jour logicielle

  • Retour à la normale

Fermer