Manu a écrit:Gilles131 a écrit:La visualisation de l'ordre TCAS se fait sur le vario, qui n'est pas un instrument de pilotage primaire. Boeing, lui, l'a tout de suite affiché sur le PFD
Pourtant le vario est affiché sur le PDF depuis une éternité, même chez Airbus. L'A320 en 1988 était déjà conçu comme ça.
Très juste, merci!
Je me suis en effet mal exprimé, toutes mes excuses. Ce que je veux dire est que quand Airbus présente une consigne d'évitement TCAS en
vario, Boeing le fait en
assiette (l'horizon du PFD). L'assiette est un paramètre de pilotage primaire, pas le vario.
On constate de nombreuses confusions de sens de correction avec la présentation en vario,
aucune avec la présentation en assiette: la bonne solution est donc évidente.
Mais quand Airbus a enfin (30 ans après!) admis son erreur et voulu changer son fusil d'épaule, on s'est aperçu que Boeing s'était évidemment empressé de déposer un brevet. C'est cela qui a motivé la fuite en avant vers l'automatisation du RA TCAS sur Airbus, alors que Boeing continue avec un succès total d'appliquer la seule solution de bon sens:
le calculateur calcule et informe, le pilote décide et agit.
Manu a écrit:Et la collision du lac de Constance, qui a fait comprendre les limites de l'utilisation humaine du TCAS, c'était entre un Tupolev et un Boeing, l'ergonomie des Airbus n'avait rien à voir avec ça. La encore, pour que le pilote ne fasse jamais l'erreur de ne pas suivre le TCAS (quelle qu'en soit la raison), le couplage TCS / PA est la seule solution.
Ce n'est pas la (seule) solution mais bien le dogme. Le dogme de l'automaticien-méchant-de-James Bond, obsédé par sa volonté de dominer et asservir le monde depuis son bureau.
La solution, c'est ce qui manquait à cette époque:
la formation, l'information.
Depuis cet accident les pilotes et les contrôleurs ont été correctement formés, le pilote sait quand il doit
et quand il ne doit pas suivre le RA TCAS (un ordre d'évitement qui t'envoie dans le sol en finale n'est pas forcément judicieux), une phraséologie a été mise en place pour annoncer au contrôleur qu'on est en mode RA TCAS et le contrôleur sait alors que ses instructions ne seront pas suivies dans le plan vertical - mais le seront dans le plan horizontal.
Depuis, plus aucune collision en vol, même entre avions Boeing qui n'ont
jamais fait exécuter les manoeuvres TCAS par le PA.
On est dans le cas typique d'un excellent système, apportant un énorme plus à la sécurité des vols et apprécié par tous, mais dont la mise en oeuvre a montré de possibles défaillances résolues par la mise en place de procédures, d'informations et de formations adaptées.
Qu'Airbus ait été contraint à la fuite en avant n'est que la conséquence de son interface inadaptée et de son obstination dans l'erreur laissant à Boeing tout le temps de déposer le brevet et de le coincer.
Manu a écrit:Gilles131 a écrit:Affirmation bien péremptoire. Les ingénieurs d'Airbus ayant longuement et sérieusement travaillé sur le sujet ont conclu à l'impossibilité du pilotage en incidence à haute altitude et haut Mach.
Comment est piloté un avion alors ? Il faut bien à un moment que son incidence soit prise en compte et affichée par le PA. Il ne travaille certainement pas avec l'assiette ni avec le vario comme nous en VFR. Pour répondre aux ordres du minimanche, qui pilote un facteur de charge, il faut bien piloter la portance, donc l'incidence.
Ja parle là du BUSS (back-up speed scale), option non achetée par AF sur le 447 et dont il a été dit qu'elle aurait pu éviter l'accident.
En réalité Airbus réserve son utilisation à un niveau inférieur à FL250: basée sur une mesure de l'incidence, ses concepteurs la considèrent inexploitable à haute altitude et haut Mach.
A M.85, 100 ft/min = 0,12° d'assiette...
Manu a écrit:Si on mettait (ou plutôt quand on mettra) ce type d'algorithme en place, on pourrait encore renforcer sa robustesse, par exemple en mettant des jauges de contraintes sur les attaches moteur et les ailes (pour mesurer la poussée des moteurs et l'accélération verticale indépendamment du FADEC ou des centrales inertielles)
C'est la fuite en avant: toujours plus de capteurs donc toujours plus de risques d'informations fausses, discordantes et incompréhensibles par l'automatisme, des logiciels toujours plus touffus (comme Microsoft: des patchs sur des patchs sur des patchs) finissant par tomber, après des années et des années d'utilisation normale, dans un cas auquel personne parmi ses concepteurs humains n'avait jamais pensé et qui conduit à la catastrophe...
Manu a écrit:L'Etre Humain est par définition faillible, bien plus que n'importe quel automatisme, on peut le nier tant qu'on veut mais ça ne changera rien. Il garde aujourd'hui une capacité de réflexion que ne peuvent pas avoir ces automatismes, mais ce n'est que temporaire.
L'automatisme est conçu par l'être humain et est donc fatalement faillible. On le voit à chaque accident, où il est de plus en plus reproché aux pilotes de n'avoir pas su récupérer un automatisme défaillant alors que justement, leur donnant de plus en plus d'autorité et de moins en moins de transparence, et donnant aux pilotes de moins en moins d'information et de formation car "c'est tout automatique, même ma concierge pourrait s'en servir", ils sont de plus en plus piégés.
C'est le drame du complexe de l'automaticien-méchant-de-James Bond: la fuite en avant aveugle.
Manu a écrit:Gilles131 a écrit:C'est exactement le contraire: un PA ne remplace aucunement le pilote ou le conducteur, mais l'assiste
Un PA utilise les données des capteurs pour contrôler l'avion sans que le pilote n'ait besoin d'intervenir. Si pour toi c'est pas remplacer, j'ai du mal à te suivre.
On voit bien que tu n'as jamais utilisé de PA!
C'est ce qu'il y a de plus compliqué de nos jours dans une qualif de type, et de loin! Le PA ne fait que ce que le pilote lui demande. Le pilote affiche des consignes (
décide et
agit), le calculateur
calcule et
applique la consigne.
Le pilote peut guider le vol en lâchant le manche et en relâchant un peu sa surveillance pour s'occuper en parallèle de toutes les tâches auparavant dévolues au mécanicien, au radio, au navigateur, sans compter le commercial. Ce n'est, bien sûr, en aucun cas le PA qui guide!
Manu a écrit:Techniquement le PA aujourd'hui est capable de faire décoller, voler, atterrir et rouler l'avion. Le pilote n'est là que pour suppléer ses défaillances. Il y a bien un moment où la technique sera capable de le faire elle même. C'est qu'une question de temps.
Je vais te dire un secret: c'était déjà le cas il y a un demi-siècle, et l'on envoyait déjà des engins entièrement automatisés sur la lune!
Cet "argument" est une obsession de l'automaticien-méchant-de-James Bond. Déjà il y a plus de 30 ans les automaticiens du CERT racontaient à qui voulaient l'entendre que tous les atterrissages étaient automatiques! On avait beau leur expliquer qu'un pilote en faisait en moyenne 1 par an en long-courrier, 5 en moyen-courrier, ils continuaient à raconter leurs salades! Il y a bel et bien du psy derrière.
Manu a écrit:Le FADEC sort l'Humain de la boucle de la gestion du moteur
Pas du tout! le FADEC fait ce que faisait le mécanicien, et
assiste parfaitement le pilote.
Le pilote
décide (la poussée) et
agit (l'affiche), la calculateur
calcule et
applique. C'est un excellent système!
Manu a écrit:L'AP sort le pilote de la boucle du pilotage courant de l'avion
l'AP ne sort pas le pilote de la boucle, mais le décharge et lui permet (normalement) de prendre du recul. Il ne se fatigue pas, est (normalement) prédictif et répétitif et permet donc au pilote de guider l'avion en ayant moins "le nez dans le guidon"
Bien utilisé (et non pas de façon dogmatique comme on l'a vu parfois) c'est une aide précieuse. Indispensable pour des vols longs à haute altitude et haut Mach, où l’assiette se pilote à moins de 1/10° près.
Le pilote affiche des consignes (
décide et
agit), le calculateur
calcule et
applique la consigne.
Manu a écrit:l'ATHR sort le pilote de la boucle de la gestion de la puissance
L’ATHR ne sort pas le pilote de la boucle, mais remplace le mécanicien qui auparavant gérait la position des manettes en fonction de la demande du pilote. Le pilote décide et agit (demande ou affiche), le calculateur calcule et, comme le mécanicien, applique.
Bien utilisée (et non pas de façon dogmatique comme on l’a vu parfois) c’est une aide précieuse: excellent système!
Le pilote affiche des consignes (
décide et
agit), le calculateur
calcule et
exécute.
Manu a écrit:Le GPWS / EGPWS sort le pilote de la boucle de l'anticollision avec le sol => on juge qu'il peut ne pas se rendre compte qu'il va finir au dans la montagne. Et même avec ça, les cas de non réaction des pilotes à une alarme GPWS, il y en a
Ils ne sortent pas le pilote de la boucle, mais calculent sa position, la comparent à leur bibliothèque du relief et l’informent. Le calculateur
calcule et
informe, le pilote
décide et
agit. Excellent système!
Et il y a des cas où le décision de ne pas agir est prévue, salutaire et parfaitement justifiée.
Manu a écrit:Le TCAS le sort de la boucle de l'anticollision en vol
Il ne sort pas du tout le pilote de la boucle, mais précisément l’y met! Le calculateur
calcule la possibilité d’un conflit, en
informe les pilotes et leur
propose une manoeuvre coordonnée (par simple comparaison des numéros de série des deux équipement, ou un équivalent), ce qu’il leur est matériellement impossible de faire seuls.
Les pilotes
décident (suivre la consigne ou pas, selon le cas), et
agissent. Excellent système!
Aucune raison de le coupler au PA, sauf quand il s’avère que l’interface est totalement inadaptée… et que l’on ne peut plus la changer!
Manu a écrit:L'antiskid, l'autobrake et le ROPS gèrent le freinage à la place du pilote
L’autobrake ne gère pas le freinage à la place du pilote: c’est bien lui qui décide de l’utiliser ou pas, et quel niveau de freinage sera utilisé. Le pilote
décide et
affiche, le calculateur
calcule et
applique la consigne. Seul avantage: couplé à l'antiskid, il peut freiner dès que c'est matériellement possible, ce que ne peut faire précisément le pilote faute de capteur approprié: petit gain de performance. Donc freinage initial à l'autobrake, puis passage en freinage manuel pour réguler sa vitesse à la bretelle.
L’antiskid fait grâce à ses capteurs ce que le le pilote, qui n’en dispose pas, ne peut effectivement pas faire. Mais avec ses pièges et ses lacunes, comme le non-freinage en cas d’atterrissage doux sur piste mouillée. Mais c’est la faute des pilotes, ils n’avaient qu’à faire un boum! Après quelques incidents sérieux, ils en sont maintenant
informés, et
formés.
Je ne te parle même pas du sketch de la panne du calculateur "Antiskid and Nosewheel Steering" de l'A320 sur la piste, et de la réalisation pratique de la procédure associée! Grand moment, pendant lequel l'avion continue de dévaler la piste à 70 m/s!
Le ROPS est un super concept issu du BTV (voir plus bas). Le calculateur
calcule (en fonction de l’énergie en courte finale, la capacité à arrêter l’avion sur la piste, mouillée et sèche) et informe. Le pilote
décide et
agit.
Manu a écrit:On en profite au passage pour rajouter une fonctionnalité de freinage optimisé qui lui permet ne pas forcément freiner comme un sourd dès le toucher pour ensuite se trainer à 10 kts pour rejoindre le taxiway qui lui a été assigné par le contrôle. Les quelques secondes / dizaines de secondes qu'on gagne à chaque atterrissage permettent d'augmenter la capacité des pistes, d'autant plus qu'on SAIT que l'automatisme le fera, alors que rien ne garanti qu'un pilote appliquera cette procédure à coup sûr.
Ce n’est pas le contrôle qui assigne une bretelle de sortie mais le pilote qui la choisit.
Voilà le contre-exemple type d’un système (le BTV pour brake to vacate) totalement stupide, inutile et allant exactement à l’encontre du but affiché.
Une merveille qui se targue de faire ce que tout pilote fait à chaque vol: moduler le freinage pour être à la bonne vitesse face à la bretelle. Chaque conducteur automobile, dès ses premières leçons de conduite, le fait des centaines de fois par trajet, sans même y penser!
Quelle trouvaille! Sauf que ce truc stupide amène l’avion à 10 kt face aux bretelles grande vitesse que chaque pilote sait très bien prendre à 30 kt pile, un peu moins si c’est mouillé. Les quelques secondes/dizaines de secondes gagnées à chaque atterrissage le sont par le pilote qui
n'utilise pas le BTV!
Son seul mérite est d’avoir, par le développement de son calculateur, permis le ROPS.
Manu a écrit:Le ND, le BUSS et l'HUD ne sont que des affichages, pas des automatismes.
Je ne connais pas assez le FMS et pas du tout le PWS pour me prononcer, l'ACARS et le CPDLC ne sont que des moyens de communication.
Tous les systèmes que je mentionne sont des merveilles ayant permis l’amélioration spectaculaire de la sécurité des vols que nous avons connu en une génération (ce n'est pas moi qui ai mentionné le BTV!). La plupart ne sont pas des automatismes, et encore moins de l’intelligence artificielle.
Loin de sortir le pilote de la boucle, ils lui permettent une bien meilleure conscience de la situation et une bien meilleure capacité à décider, avec les résultats que l'on sait sur la sécurité du transport aérien. Bravo!
Cependant ils sont très exigeants en formation et en entrainement, alors qu'ils sont présentés comme justement permettant d'en épargner. Il a donc fallu attendre que des accidents en mettent en évidence les pièges ou les lacunes pour que les autorités l'imposent.
L’automaticien-méchant-de-James Bond, lui, en retient que les pilotes ont failli à pallier les failles et les pièges des automatismes: CQFD! il en faut donc encore plus, toujours plus! Et c'est la mortifère fuite en avant...
Le progrès, c'est quand c'est mieux.