Je vous propose ci-dessous un article très intéressant, émanant de Sakerfrancophone. Il s’agit d’un blog antimondialiste, qui est une source très riche et créative, très réactive en matière de traduction d’essais, de témoignages venus du monde anglo-saxon. Hervé est l’un des animateurs de cette plateforme d’information et de résistance.
Les deux accidents qu’a subi le Boeing 737 MAX ont coûté la vie à 346 personnes sont liés au Système de Maximisation des Caractéristiques de Manœuvre (MCAS). Mais il s’est révélé un autre problème important : la solution logicielle de Boeing pour régler le problème du 737 MAX dépasse les capacités de l’ordinateur de l’avion !
Il était déjà avéré que les volants de compensation manuelle que Boeing recommandait d’utiliser pour contrer le MCAS du Boeing 737 Max étaient impossibles à manœuvrer quand il le fallait, car dépassant la force des pilotes. Ce défaut majeur concerne également l’ancien Boeing 737 NG, dont 6.143 exemplaires volent en 2018 !!!
Mais alors que le problème MACS n’est toujours pas résolu, voici qu’un nouveau problème apparaît :
Boeing avait promis de publier un correctif du 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. Et il vient de s’ajouter un nouveau problème, qui causera d’autres retards :
Deux personnes informées du problème ont révélé que la semaine dernière, des pilotes de la F.A.A. ont testé dans un simulateur de vol des activations intempestives du logiciel MACS, qui a tendance à faire piquer le nez de l’avion.
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 proposée par Boeing pour reprendre le contrôle de l’avion. Le pilote a qualifié cette défaillance de catastrophique, ce qui signifie qu’elle pouvait 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 = Flight Control Computer) 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écessitera 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= Control Power Unit).
Le système de commandes de vol du 737
Comme l’écrivait l’an dernier Peter Lemme, l’ancien ingénieur chargé des commandes de vol de Boeing, dans une note technique à ce sujet :
« 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, ce qui donne une très faible redondance.
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, Peter Lemme 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 qu’utilisait Peter Lemme à son é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. Peter Lemme 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 s’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 et on put douter 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 ces performances.
La dernière date annoncée 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 parle-t-on? »
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ée 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.