Boeing 737 MAX : c’est bien pire que ce qu’on imaginait !
Le 30 juin 2019
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 B737 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.
Ma conclusion : pour l’avenir de la firme Boeing, à laquelle beaucoup de pilotes sont attachés, car elle a produit des avions superbes, il n’y a qu’une seule alternative de succès : celle d’ouvrir une page blanche pour concevoir le remplaçant d’un avion mis en ligne en 1967 ! Hors de cela : point de salut, ni de confiance des pilotes !
***************************************
2 août 2019 at 13 h 10 min -
Bonjour,
Ingénieur en retraite, je partage globalement l’analyse de cet article sur les
aspects technologiques des processeurs pour applications embarqués CDVE (Cde de Vol) que j’ai très bien connu dans ma vie professionnelle antérieure et en particulier la famille x86.
Hélas, on ne fait pas du neuf avec du vieux, et les rustines logiciels ça ne tient qu’un temps avec la puissance de calcul requise pour les applications complexes et les retrofits calculateurs…
Dans le contexte actuel, je vois mal comment Boeing pourrait s’en sortir sans refondre ses calculateurs, (ce qu’on fait ses concurrents…) sans parler de redévelopper un nouvel avion qui prend cinq ans et nécessite de mettre 15Mrd de $ au tapis…
Quand à la FAA, n’en parlons pas, c’est un scandale, il y a du ménage à faire pour avoir certifié des architectures calculateurs et logiciels incertifiables ! malheureusement, ça ne fera pas revenir les 346 personnes qui ont peris …
Par ailleurs, dans les commentaires de certains en particulier ce qui touche aux avions de la défense et au spatial, je suis surpris du niveau de détail qui normalement relève des obligations de réserve, même pour un retraité…
À suivre donc le feuilleton Boeing…
Bonne journée à tous
18 juillet 2019 at 10 h 43 min -
Bonjour à tous,
Les dernières sondes spatiales sont équipées de processeurs RISC extrêmement puissants et fiables. Ils sont étudiés pour résister aux rayons cosmiques et sont ÉVOLUTIFS et ne nécessitent que très peu de puissance électrique (d’où une climatisation réduite).
Pourquoi ne pas les utiliser dans l’avionique???? Au lieu de cela des « dinosaures » des années 90 sont employés en limite de saturation.
Oui cela coûte de l’argent à développer et a certifier, mais de toute façon les nouveaux avions demandent des puissances de calcul incomparables avec celles des premiers « tout électronique ».
Et l’arrivée de l’IA ne vas pas arranger cela.
Pour que les avions de demain soient aussi fiables que les « vieux » 737 et autres A320, il faudra en passer par là.
Bons vols à tous.
GM
6 juillet 2019 at 6 h 55 min -
Je crois que quand on gratte on en trouve des choses, et ce n’est peut être pas fini :
Problèmes de pilote automatique
La check-list de l’EASA comprend un certain nombre de problèmes qui ont été révélés : difficultés potentielles des pilotes à tourner la roue de trim manuel du jet, manque de fiabilité des capteurs d’angle d’attaque du Max, procédures de formation inadéquates et problème de logiciel signalé la semaine dernière par la FAA, concernant un ralentissement du microprocesseur.
L’agence a également évoqué une préoccupation qui n’avait pas été signalée auparavant: le pilote automatique ne se désengageant pas dans certaines situations d’urgence.
5 juillet 2019 at 10 h 40 min -
Au train où vont les choses, on peut se demander si Boeing ne va pas droit vers l’accident industriel… proportionné à sa taille. J’ai pu entendre : pour concevoir un nouvel avion à partir de rien, c’est 15 milliards de dollars. Au train où vont les choses cette somme va être vite atteinte en indemnités, pertes d’exploitation etc…
6 juillet 2019 at 15 h 05 min -
Je partage tout à fait ton inquiètude et ton pessimisme. Boeing est bien inéluctablement devant ure page blanche, et les 15 milliards me semblent réalistes des frais à engager.
Pour information, le coût de la certification de l’A380 a été de 2 milliards de dollars !
Je crois aussi qu’il faut faire comme lors du crash de la navette Challenger :la NASA a viré quasiment tous les responsables
8 juillet 2019 at 2 h 32 min -
Cette affaire du 737 MAX pourrait-elle entraîner la faillite de Boeing et donc, soit son rachat, soit sa disparition pure et simple ?
Par ailleurs, le COMAC 919 et l’Irkut MC-21 pourraient-ils être des alternatives crédibles (c’est-à-dire, sûrs et fiables) aux 737 et A320 ?
8 juillet 2019 at 19 h 14 min -
Je ne pense pas, mais cela remet en cause pour bien des années la confiance en cette entreprise
8 juillet 2019 at 9 h 29 min -
La succession de faits et de révélations ainsi que la diversité de leurs objets amènent à suggérer que l’on est pas dans l’incident isolé techniquement (un peu comme les batteries du 787 : ça fume, on règle le problème des batteries et c’est terminé), mais plutôt dans le dysfonctionnement d’ordre systémique qui s’étend dans toute et au delà de l’entreprise jusqu’à la FAA. On a l’impression que c’est une philosophie industrielle, un paradigme de production qui sont défaillants. On reboucle ainsi sur le titre plausible et un peu effrayant d’un de vos premiers papiers sur le sujet : « quelque chose de pourri au royaume de Boeing ».
8 juillet 2019 at 19 h 11 min -
Je pense effectivement qu’il y a un sérieux ménage à faire chez Boeing et à la FAA
2 juillet 2019 at 14 h 26 min -
Ca fait froid dans le dos de voir Boeing s’enteter de cette maniere…
Ou est le concepteur du 727 737 747 757 767 777 787
Boeing a fait de merveilleux avions, je suis triste de voir qu’il a renié sa philosophie de laisser au pilote la decision ultime du vol
Facile à dire, mais le 737 MAX n’est il pas deja mort?
Je doute qu’il puisse revoler un jour
3 juillet 2019 at 17 h 16 min -
Le b 737 max ne sera jamais un avion de ligne fiable. Effectivement, il est mort, à moins de refaire strictement toute une avionique moderne, c’est à dire un autre avion, avec une qualification de type, ce que Boeing refuse d’accepter et qui de toutes façons, prendra de la monnaie et du temps, choses qui manquent le plus !
2 juillet 2019 at 13 h 22 min -
Le »sofware » qui ne correspond au »hardware » disponible dans les appareils sont hélas courant.
Pour les missions Apollo, quelques milliers de lignes de code suffisaient à accomplir le plus grand exploit de l’exploration humaine. Aujourd’hui, pour concocter une bête application pour smartphone, impossible de trouver aussi léger en mémoire….
2 juillet 2019 at 12 h 12 min -
Bonjour à tous, et un grand merci pour ces révélations d’informations importantes et très explicites. Ce qui interroge c’est que Boeing doit bien les connaître : alors que diable attend-il pour revoir complètement sa copie avec de nouveaux calculateurs et logiciels (à défaut de nouvel avion) ? J’ose espérer que c’est en cours d’étude depuis la connaissance de ces insuffisances, mais comme il faut du temps pour y parvenir, cet avionneur n’a-t-il pas fait prédominer « idiotement », la limite des pertes financières résultant de l’immobilisation des flottes, en menant en parallèle la mise au point de rustine informatiques sur ce système obsolète et à bout de souffle depuis longtemps ?
2 juillet 2019 at 12 h 08 min -
J’étais confronté à ces problèmes pas nouveaux, ai exigé des tests draconiens pour éviter le mercantilisme par utilisation de reutilisation des logiciels. J’ai programmé, testé notamment plate forme inertielle Mirage 2000, tests regulateur caburant M88 Rafale, en 6 ou 7 langages machines dit ‘assembleurs’, différents (et je ne suis pas encore mort ! LOL) , ai pu par expertise constater que des processeurs, en calculant, écrasait des données sauvegardées en mémoire vive car oubli de tests aux limites à l’époque obligatoire pour éviter cela et autrefois les mémoires RAM et …. des catastrophes. La démarche mercantile de réutilisation des logiciels sans compétence dans le domaine informatique a aussi été fatal à Ariane 5 vol 501 dont je manageais les banc d’essai de qualification avant d’être le responsable au premier niveau de l’informatique embarqué de l’avion spatial Hermès où j’étais confronté aux même risque face aux tentative des industriels dans leurs propositions technique de développement de logiciels et autres.
1 juillet 2019 at 22 h 08 min -
Dans un certain sens c est bien.
Car ça garantie que les programmes restent simple.
3 juillet 2019 at 17 h 21 min -
Çà veut dire quoi?
1 juillet 2019 at 22 h 00 min -
Pour rappel, il n y pas d instruction invalide pour le 80286 (contrairement à ce qui se fait sur les processeurs modernes où les instructions invalides ne sont pas executés) mais seulement des comportements non spécifiés. Y compris pour une éventuel instruction faisant fondre les circuits. De quoi diminuer le point de vue sans erreur (bien sûr à moins d un saut dans les données il n y aucune raison que ça se produise surtout si les programmes sont prouvés).
Et puis en matière de calcul doublé, il y a beaucoup plus rapide que ça (suffit de regarder les puces proposé par BAE systems à 200000$ l unité). La Nasa elle même utilise des puces ayant la puissance d un Powerpc G4 (même si il n y a pas besoin de système radiodurci dans le cas présent). Ça reste moins puissant qu une télé mais c est beaucoup mieux.
Il me semble que l utilisation de ce matériel soit plus lié à sa conception ancienne comme le reste de l avion.
Et quand bien même il est serait nécessaire de garder une finesse de gravure élevé pour la fiabilité, il y de nombreuse optimisations hardware pour augmenter la vitesse d execution.
J ai personnellement de l embarqué encore en vente à neuf tournant avec un processeur compatible 80286 (conçu par rétroingénérie de l original comme la plupart), mais il s agit que d assister des calculs manuel sur 16 bits. Bien loin d effectuer la moindre boucle.
3 juillet 2019 at 17 h 35 min -
Problème du à une utilisation de conception ancienne: c’est bien ce que du l’ingénieur LEMME
5 juillet 2019 at 20 h 33 min -
Oui mais ce n est pas détaillé. Soyons clair pour l embarqué de ce type, la formule c est de ne pas changer ce qui marche (donc que la conception soit ancienne c est normal mais pas à ce point là), voir de garder des finnesses de gravure élevés même par rapport au processeur d une télécommande de télévision.
Là on parle de puce grand publique spécialement reconçu pour l aéronautique en faible série dont l unité peut se vendre avec une somme à 6 chiffres.
Curiosity tourne avec la puissance d un ordinateur du début des années 90. Mais c est déjà bien plus rapide qu un 80286.
1 juillet 2019 at 20 h 13 min -
Je suis abasourdi : en plus du rafistolage de centrage, il y a un rafistolage aérodynamique, un autre sur les capteurs, et maintenant on apprend ces « retards » sur le calculateur, ce qui veut encore dire qu’ils ont fait entrer au chausse-pied une pointure 45 dans une chaussure 43.
.
Contrairement à Christian, je ne pense pas qu’améliorer le matériel et/ou le logiciel soit particulièrement compliqué même si les outils d’optimisation de code contemporains donnent assez peu d’espoir d’optimiser « à la façon » de Peter Lemme sur 286. Il y a beaucoup de choix techniques pour résoudre ce problème sommes toutes banal.
.
Par contre il y a un risque de passage par la case certification de l’ensemble qui peut être très très coûteux.
3 juillet 2019 at 17 h 28 min -
Nouvelle avionique et certification et qualification de type. Dollars et temps ! On en reparle dans au plus tôt deux ans
1 juillet 2019 at 18 h 27 min -
Oui en effet ce serait la meilleure solution de bâtir un nouvel avion, on constate que agrandir un modèle existant a des limites.
Et maintenant on veut faire du bricolage pour éviter un désastre financier !
BOEING était jusqu’alors une firme remarquable qui a produit des machines superbes.
On peut constater aussi qu’il est dommage de n’avoir que deux grands constructeurs, après les fusions avec Douglas et autres.
1 juillet 2019 at 12 h 56 min -
et on est peut-être pas au bout de nos surprises : d’après un article de l’agence Bloomberg, le développement du logiciel MCAS aurait été sous-traité à des co-contractants indiens, avec des intérimaires payés 9$ de l’heure…..notamment.
https://www.bloomberg.com/news/articles/2019-06-28/boeing-s-737-max-software-outsourced-to-9-an-hour-engineers
Cette affaire ressemble à une histoire de poupées russes, quand on entend que l’avion revolera à mi-décembre, on peut effectivement se demander « mais de quelle année ? ».
3 juillet 2019 at 20 h 57 min -
Ne nous moquons pas de Boeing pour ce point : j’avais rencontré un technicien qui avait écrit une partie du logiciel du pilote automatique du Mirage 2000, sans avoir la moindre connaissance en aéronautique, mais ces informaticiens ont un cahier des charges et savent écrire ce qu’on leur demande. Par contre la méthodologie de justification de l’écriture du logiciel (vaste sujet) laisse peut-être à désirer dans certaines petites sociétés. Un grand avionneur est impardonnable s’il néglige ce point.
6 juillet 2019 at 15 h 16 min -
J’a de la peine de la situation de Boeing, dont les avions m’ont donné tant de joies. Et de aussi de la colère. Dans cette entreprise comme dans d’autres industries, les financiers ont pris le pas sur les ingénieurs et dictent le cahiers de charges. Le résultat, c’est le refus de concevoir un remplaçant en temps utile, préferant des bricolages pour retarder le renouvellement du type d’avion
1 juillet 2019 at 11 h 41 min -
bonjour,
Ce phénomène de dépassement de capacité des ordinateurs de bord n’est hélas pas nouveau; c’était la raison donné « officiellement » pour l’explosion du lanceur Ariane5 Vol 501. Le logiciel de plateforme inertielle d’Ariane 4 avait été récupéré pour Ariane 5. Ceci pour faire des économies de développement et de tests. Problème : le logiciel d’Ariane 4 était développé sur 32 bits (ancienne génération d’ordinateur). Araine 5 fonctionnait sur ordinateur 64 bits (nouvelle génération). L’accélération transversale d’Ariane 5 étaient très supérieure à celle d’Ariane 4. Les infos nécessitaient un traitement sur 64 bits. Elles étaient traités en seulement 32 bits (logiciel d’A4 sur A5) ce qui donnait des résultats erronées et inverses à la réalité. Les 3 plateformes inertielles qui se surveillaient avec le même mauvais logiciel dupliqué pensaient que le lanceur était incliné excessivement et demandait au moteur Vulcain de redresser alors qu’il était sur sa bonne trajectoire. Résultat, le lanceur s’est mis de travers et s’est brisé en deux (à mach 7 ?). Nous avons supputé un problème de logiciel sur l’A320 de l’accident du Mont Saint Odile sans que cela soit la cause de l’accident Mais je crois me souvenir qu’un ingénieur de Toulouse a voulu mettre fin à ses jours car responsable des tests logiciel de l’avion et dont on mettait en doute ses compétences. La politique de récurrence des logiciels est très risqué et les responsables souvent non informaticiens ne mesurent souvent pas le monde de l’informatique et obsolescence rapide de leur technologie à un moment t. D’où des conséquences dramatiques. ET toujours pour du fric !
3 juillet 2019 at 20 h 50 min -
Pour cette perte du lanceur Ariane 501, j’avais lu une information que l’écriture du logiciel faisait que les données des accéléromètres des centrales à inerties n’étaient pas coupées durant la phase de départ du pas de tir, ce qui est nécessaire à cause des vibrations. J’avais découvert, au sol, sur le premier prototype du MIRAGE 2000, que par vent de travers (mistral), le test pilote des commandes de vol électriques plantait à cause des informations des gyromètres de lacet qui n’était pas coupées…Par ailleurs le chef pilote de Dassault avait avorté un décollage car avion refusant de cabrer : cause identifiée : bouton de test pilote CDV oublié sur marche, alors que les gains des CDV étaient à zéro en fin de test……(naturellement l’avionneur avait très rapidement fait les modifications nécessaires)
Dans les bureaux d’études de l’aviation, on ne dispose pas d’une banque de données internationale concernant les identifications d’erreurs de conception ayant conduit à des avatars, voire des incidents graves ou des accidents, survenus , identifiés, et ayant conduit à des modifications. Pourtant des erreurs de choix semblent récurrentes ou présenter une certaine analogie.
1 juillet 2019 at 7 h 07 min -
sur le nez des planeurs on colle un fil de laine par un bout et en vol le déplacement de l’autre bout du fil de laine indique si l’on est en dérapage ou en glissade
je propose d’installer dans la cabine d epilotage du 737, entre les 2 pilotes un fil à plomb fixé
au plafond de la cabine : en vol, si le plomb va vers l’arrière de l’avion on est en montée, s’il va vers l’avant on est en descente,
c’est pas beau la technique ?
JPG
1 juillet 2019 at 8 h 54 min -
Ca n’empècherait pas le MACS de fonctionner !
1 juillet 2019 at 15 h 30 min -
Mais on saura pourquoi on va au tapis ! Ça console !
2 juillet 2019 at 21 h 52 min -
Et si le fil à plomb est envoyé collé au plafond, c’est que c’est que le décrochage est bien installé…Trêve de plaisanterie des « trucs » simples qui n’ont pas besoin de redondance ni ne nécessitent d’interprétation difficile, ni n’ont besoin d’énergie électrique pour continuer à être opérationnel, pourquoi pas (mais je ne suis pas pilote) ?
3 juillet 2019 at 17 h 32 min -
Ne t’attarde pas sur une connerie
1 juillet 2019 at 5 h 50 min -
merci pour ce commentaire très intéressant mais qui nous laisse perplexe sur les suites de cet appareil cloué au sol mais combien de temps pour remédier à cette défaillance catastrophique Je prends l’avion ce matin pour NICE (un petit avion) certes mais sans enthousiasme !
cordialement. Mme didelot
30 juin 2019 at 19 h 46 min -
Un article du Wall Street journal
Trim Cutout with Severe Out-of-Trim Stabilizer can be difficult to recover
The Wall Street Journal reports that the crew on ET302 used the stabilizer trim cutout switches in response to MCAS commands, but appeared to be unable to raise the nose. They then released the cutout switches to use electric trim, but encountered MCAS commands again without recovering.
One possible explanation is that the loads on the jackscrew due to the severe stabilizer nose down out-of-trim situation were too great for the pilot to overcome using the trim wheel with folding handle. The pilots restored electric trim as a means to trim.
Boeing published a technique in the past that discussed this issue and the need to release the column briefly in a series of « roller coaster » or « yo yo » maneuvers, by cranking in stabilizer trim alternatively with large column commands.
This is in a 737NG Flight Crew Ops Manual
This is in the 737NG training manual:
Manual Stabilizer TrimIf manual stabilizer trim is necessary, ensure both stabilizer trim cutout switches are in CUTOUT prior to extending the manual trim wheel handles.Excessive airloads on the stabilizer may require effort by both pilots to correct the mis-trim. In extreme cases it may be necessary to aerodynamically relieve the airloads to allow manual trimming. Accelerate or decelerate towards the in-trim speed while attempting to trim manually.Anticipate the trim changes required for the approach. Configure the airplane early in the approach. When reaching the landing configuration, maintain as constant a trim setting as possible. If a go-around is required, anticipate the trim changes as airspeed increases.
This is in a 737 QRH (Ref 9.15)
This is from the Airworthiness Directive. It seems quite pertinent to emphasize using the electric trim to get the stabilizer near to an in-trim condition before hitting the cutout switch.
Ce problème de trim touche tous les 737 NG, Boeing n’en est pas sorti et va de Charybe en Scylla
1 juillet 2019 at 8 h 56 min -
Voir mon article du 30 juin
30 juin 2019 at 18 h 49 min -
Eh ! Bé ! je suis abasourdi par une solution de rafistolage qui est l’accumulation de pansements sur des pansements qui ne garantissent pas la fin de la « maladie » ni même évitent , ce qui est pire, la mort de l’avion malade…
Du passé faisons table rase !
30 juin 2019 at 18 h 29 min -
A lire l’article du Canard Enchainé de cette semaine à propos du cas des femmes pilotes confrontées à ce système…
1 juillet 2019 at 9 h 02 min -
Polémique idiote, car le blocage du volant de trim vaut pour tous les pilotes , males ou femelles
4 juillet 2019 at 3 h 57 min -
Pas si idiote que ça car « femme au volant la mort au tournant »!
(Pardon à toutes les lectrices de ce blog)
6 juillet 2019 at 15 h 20 min -
Il n’a jamais été envisagé qu’on fasse passer aux pilotes, mâles ou femelles des brevets d’haltérophilie pour pouvoir manœuvrer le trim manuel des avions
9 juillet 2019 at 6 h 22 min -
Le trim s’en fou de qui le manipule.
Qui suis-je ?
Commandant de Bord Boeing 747 Air France ER
Ex Leader de la Patrouille de France
Expert de l’accident de Sharm El Sheikh (2004)
Ancien Président du Bureau Air France du SNPL, Syndicat National de Pilotes de Ligne – 1986 / 1990
Biographie
Abonnez vous à la newsletter