Le Boeing 737 MAX continue d’être un avion à problèmes
Moon of Alabama – Le 27 juin 2019
Les deux accidents qu’a subis ce type avion, qui ont coûté la vie à 346 personnes, ont révélé un autre problème important que celui du fatidique Système de Maximisation des Caractéristiques de Manœuvre (MCAS).
Il s’est avéré que les volants de compensation manuelle que Boeing recommandait d’utiliser pour contrer le MCAS étaient impossibles à manœuvrer quand il le fallait. Moon of Alabama a détaillé le problème en mai dernier et le Wall Street Journal l’a confirmé la semaine dernière. Cela concerne également l’ancien Boeing 737 NG.
Alors que ce problème n’a toujours pas été résolu, un nouveau problème apparaît.
Boeing avait promis de publier un correctif logiciel pour le MCAS d’ici avril 2019. Mais cela s’est avéré plus difficile que prévu. Trois mois plus tard, il n’y a toujours pas de solution définitive disponible. Entre-temps, un nouveau problème qui causera d’autres retards a été encore révélé hier :
La semaine dernière, des pilotes de la F.A.A. ont testé dans un simulateur de vol des activations intempestives d'un logiciel qui a tendance à faire baisser le nez du Max, ont expliqué deux personnes au courant du problème. Ce logiciel, connu sous le nom de MCAS, a été impliqué dans les deux accidents ayant tué 346 personnes. Dans au moins un des cas, le pilote de la F.A.A. a été incapable de suivre rapidement et facilement les procédures d'urgence de Boeing pour reprendre le contrôle de l'avion. Le pilote a qualifié cette défaillance de catastrophique, ce qui signifie qu'elle pourrait entraîner la perte d'un avion en plein vol. ... Le problème découvert la semaine dernière est lié à la vitesse de traitement des données d'une puce informatique de commande de vol spécifique, selon les deux personnes ayant connaissance de la question. Au cours de l'essai, le pilote de la F.A.A. a constaté des retards dans l'exécution d'une étape cruciale nécessaire à la stabilisation de l'avion.
Il semble que le traitement du signal et les calculs supplémentaires nécessaires au MCAS surchargent le processeur du calculateur de commandes de vol (FCC) et retardent son temps de réaction.
Boeing cherche à mettre à jour ce logiciel depuis huit mois, a déclaré [un porte-parole de Boeing]. On ne sait pas encore si le nouveau défaut peut être résolu en reprogrammant le logiciel ou s'il nécessite un correctif matériel, ce qui serait plus coûteux et pourrait prendre beaucoup plus de temps.
Le 737 MAX dispose, comme les versions précédentes 737 NG et Classic, de deux FCC qui ont chacune deux unités centrales de traitement (CPU).
Le système de commandes de vol du 737
Comme l’écrivait l’an dernier l’ancien ingénieur chargé des commandes de vol de Boeing, Peter Lemme, dans une note technique à ce sujet :
Chaque FCC est composée de deux processeurs, dont chacun fonctionne indépendamment. Chaque FCC dispose de deux processeurs 16 bits. Les deux processeurs ont des numéros de pièces différents pour s'assurer qu'il n'y a pas de problème de conception dans les deux processeurs. Les CPU pilotent différentes commandes ...
Dans une autre note, Lemme écrivait :
Le FCC du 737 est configuré en mode "dual-dual". Dans chacun des deux ordinateurs du pilote automatique, il y a deux processeurs différents, qui sont programmés par des personnes différentes. La plus grande menace est une panne logicielle en mode commun. Le fait d'avoir deux groupes de programmes différents à partir d'un ensemble commun d'exigences est un moyen de diminuer un risque d'échec ... L'architecture double du 737 est tout à fait unique. La décision de faire un régulateur de vitesse monovoie date du 737 classique. La fonction du MCAS revient à celle d’un autre FCC qui se comporte, à un niveau élevé, comme un régulateur de vitesse, dont l'architecture aurait alors été reproduite.
Le 737 n’utilise qu’un FCC à la fois, et le Système de régulateur de vitesse (STS), dont le MCAS fait partie, ne fonctionne qu’avec un seul des deux processeurs internes de l’ordinateur de vol.
Les processeurs en question seraient des processeurs de type Intel 80286. La version Intel originale de ce processeur, vendue entre 1982 et 1991, avait une fréquence d’horloge maximale de 4, 6 ou 8 MHz. Ils ont ensuite été fabriqués par un certain nombre d’autres entreprises, dont AMD et la société aéronautique Harris, avec une fréquence d’horloge de 20 et 25 MHz. Il est probable que le Boeing 737 FCC utilise ces types ou des types similaires.
Ces vieux processeurs sont très fiables et sans erreur. Mais ils calculent mille fois moins vite qu’un téléphone portable moderne. Selon Lemme, un processeur dans l’ordinateur de vol exécute jusqu’à onze processus différents. Tous ont besoin de recevoir les données de capteurs externes, de les traiter avec leurs algorithmes et de transmettre une commande aux leviers qui contrôlent les surfaces de vol mobiles de l’avion. Le fait que le pilote de la FAA ait « rencontré des retards dans l’exécution d’une étape cruciale » causés par l’ordinateur indique une surcharge de capacité.
Il y a quelques décennies, votre serviteur a programmé des pilotes de périphériques spéciaux pour les systèmes Intel 80286 et similaires. Leur but était d’enregistrer et de traiter des données provenant de capteurs de processus industriels, souvent des centaines à la fois. Les problèmes de performance et de synchronisation exigeaient que les drivers (pilotes) d’entrée 80286 soient écrits en langage assembleur de bas niveau. Mais même avec un code extrêmement optimisé, le système finissait par atteindre ses limites. Le traitement retardé des données d’un capteur se traduisait par d’autres retards et, en fin de compte, le système n’enregistrait et ne traitait plus rien. La tâche était tout simplement au-dessus de ses capacités physiques.
L’ordinateur de contrôle de vol exécute des processus d’opérations spéciales avec un minimum de surcharge. Ils sont programmés dans des langages de programmation très efficaces. La conception et la mise en œuvre du logiciel suit un processus très strict utilisant des outils spécialisés (voir les produits de Green Hills pour des exemples). Tout cela est bien meilleur que ce que j’utilisais à mon époque.
Les programmes écrits pour les commandes de vol sont déjà très optimisés. Les optimiser davantage « manuellement » briserait le processus réglementé qu’exige la production d’un tel logiciel.
Boeing dit qu’il peut à nouveau réparer le logiciel pour éviter le problème que la FAA vient de trouver. Je doute que cela soit possible. La charge logicielle est à son maximum, sinon déjà au-dessus des capacités physiques des ordinateurs de contrôle de vol actuels. Le potentiel d’optimisation du logiciel est probablement minime.
Le MCAS était déjà un pansement sur une blessure. En raison de la nouvelle position du moteur, le 737 MAX a eu un comportement différent par rapport aux anciens types 737, même si il utilisait toujours les anciens types de certification. Le MCAS était donc censé corriger cela. Le correctif du logiciel du MCAS est donc un nouveau pansement sur l’ancien pansement. Corriger le logiciel, comme le promet maintenant Boeing pour résoudre le problème que le pilote de la FAA a découvert, est un troisième pansement sur la même blessure. Je doute que cela guérisse la blessure.
Les calculateurs de commandes de vol du 737 MAX et du NG ont été développés entre le début et le milieu des années 1990. Il n’existe pas de solutions prêtes à l’emploi pour améliorer ses performances.
La dernière date annoncé par Boeing pour la remise en vol des avions 737 MAX immobilisés au sol est « mi-décembre ». Face à ce nouveau problème, on a tendance à se demander de « quelle année ? »
Moon of Alabama
Note du Saker Francophone Ayant étudié sur ces processeurs dans les années 80/90, on confirme les informations de cet article. La situation est même pire que cela car faire de la rétro-ingénierie est déjà complexe, en assembleur pour ceux qui connaissent, c'est encore plus difficile mais le pire est dans doute que les développeurs qui ont mis au point ces logiciels sont au mieux en retraite, voire déjà morts. Les nouveaux développeurs étudient sur des logiciels de haut niveau (comme Java, Python, même le C/C++ n'est plus forcément enseigné) très très loin du langage machine. On assiste en direct à l'obsolescence programmé d'infrastructures industrielles complexes. Il faudrait rebâtir des processus industriels à partir de zéro, ce que doivent faire les chinois qui sont au début de la phase d'industrialisation de leur avion de ligne gros porteur. La conscience de ce mitage de nos systèmes n'a sans doute d'égal que l'autisme des dirigeants qui eux aussi ont été financiarisés.
Traduit par Wayan, relu par Hervé pour le Saker Francophone