Technologie

Prévention des fuites, prélèvements intacts et Boeing’s 737 Max 8

Prévention des fuites, prélèvements intacts et Boeing’s 737 Max 8


Photo par Gary Lopater sur Unsplash

Le transport aérien est l'un des modes de transport les plus sûrs. Les statistiques du département américain des Transports montrent qu'en 2007 et 2016, il y a eu 11 morts par billion de kilomètres de voyages commerciaux en avion. Cela contraste nettement avec les 7 864 décès par billion de kilomètres parcourus sur l’autoroute (vous pouvez consulter les statistiques ici: nombre de morts et de kilomètres par mode de transport). Les améliorations progressives du transport aérien sont une merveille d’innovation technique. Cependant, lorsqu'un accident d'avion survient, nous sommes obligés d'en prendre conscience en raison de l'ampleur d'un seul événement.

Les voyages aériens ont aujourd'hui une maturité technique telle que lorsqu'un avion s'écrase par accident (non pas pour des raisons causées par l'homme, comme le terrorisme ou des ratés de missiles), il est étonnamment dû non pas à une erreur de pilotage ou à une défaillance de l'équipement physique, mais plutôt d'une erreur informatique. C'est-à-dire qu'un accident d'avion est causé par un bogue logiciel.

Aujourd'hui, tout le monde connaît très bien les bogues logiciels. L’écran bleu Microsoft de la mort et l’utilisation de la combinaison de touches Ctrl-Alt-Suppr ont été gravés dans nos expériences. Même dans les systèmes d'exploitation mieux conçus que l'on trouve dans les smartphones, il n'est pas rare de forcer un redémarrage. C’est beaucoup moins courant que nous ayons souvent à consulter la procédure, mais cela arrive quand même.

Le logiciel est notoirement difficile à rendre sans bug. C'est la nature de la bête. En effet, pour construire des systèmes logiciels exempts de bugs, nous devons lister explicitement tous les scénarios qui peuvent mal tourner et comment, puis tester notre logiciel pour ces conditions. Malheureusement, cette liste a tendance à être illimitée si nos conceptions ne limitent pas la portée de l’applicabilité d’un logiciel. En bref, les développeurs de logiciels sont en mesure de gérer cette complexité sans limite en limitant le champ d'application. C'est pourquoi même les applications les plus sophistiquées «d'intelligence artificielle» fonctionnent bien dans les zones les plus étroites. Il est très facile d’être frustré par les limitations d’assistants vocaux comme Alexa. C’est parce que la technologie d’IA n’a pas atteint le niveau de maturité requis pour une conversation générale ouverte. En bref, l'absence de bogues dépend fondamentalement d'un champ d'application restreint et de tests approfondis dans ce domaine restreint.

Alors que nous construisons des logiciels plus sophistiqués et plus complexes, nous devons comprendre la portée d’une application et une portée sans cesse croissante exige de plus en plus de tests pour ces systèmes. Ainsi, pour mieux comprendre cette complexité, nous devons comprendre le type d’automatisation que nous construisons.

Comme je l'ai mentionné plus tôt, l'USDOT indique qu'il y a eu plus de 37 000 décès dans des accidents de la route rien qu'en 2017. Il est donc logique de comprendre comment l’automatisation affecte la sécurité des véhicules routiers. La Society of Automation Engineering (SAE) applique une norme internationale qui définit six niveaux d’automatisation de la conduite (SAE J3016). C'est un cadre utile pour classer les niveaux d'automatisation dans des domaines extérieurs à celui des voitures. Une prescription plus large est la suivante:

Niveau 0 (processus manuel)

L'absence de toute automatisation.

Niveau 1 (processus assisté)

Les utilisateurs sont informés de l'initiation et de l'achèvement de l'exécution de chaque tâche automatisée. L'utilisateur peut annuler une tâche en cas d'exécution incorrecte. Les utilisateurs sont toutefois responsables du bon séquençage des tâches.

Niveau 2 (Assisté à plusieurs processus)

Les utilisateurs sont conscients du lancement et de la réalisation d'un ensemble de tâches. Toutefois, l'utilisateur n'est pas responsable du bon séquençage des tâches. Un exemple sera la réservation d'un hôtel, d'une voiture et d'un vol. La commande exacte de la réservation peut ne pas être une préoccupation de l'utilisateur. Toutefois, l’échec de cette tâche peut nécessiter des actions correctives manuelles plus étendues. Le relogement du client payeur d’United Airlines est un exemple malheureux de mesure corrective ayant échoué.

Niveau 3 (processus sans surveillance)

Les utilisateurs ne sont informés que dans des situations exceptionnelles et sont tenus de faire le travail dans ces conditions. Un exemple de ceci est dans les systèmes qui surveillent en permanence la sécurité d'un réseau. Les pratiquants agissent en fonction de la gravité d'un événement.

Niveau 4 (processus intelligent)

Les utilisateurs sont responsables de la définition des objectifs finaux de l'automatisation. Toutefois, tous les aspects de l'exécution du processus, ainsi que le traitement des conditions exceptionnelles en vol, sont gérés par l'automatisation. L'automatisation est capable d'effectuer une action de compensation appropriée en cas de panne en vol. L'utilisateur reste toutefois responsable de l'identification du contexte spécifique dans lequel l'automatisation peut être appliquée en toute sécurité.

Niveau 5 (processus entièrement automatisé)

Il s'agit d'un état final et futur dans lequel la participation humaine n'est plus requise dans les processus. Bien entendu, ce n'est peut-être pas le dernier niveau car il ne suppose pas que le processus est capable de s'optimiser pour apporter des améliorations.

Niveau 6 (processus d'auto-optimisation)

Cette automatisation ne nécessite aucune intervention humaine et est également capable de s’améliorer avec le temps. Ce niveau va au-delà des exigences de la norme SAE mais peut être requis dans certains environnements concurrentiels très performants tels que les courses Robocar et les opérations sur actions.

Les voitures d'aujourd'hui disposent d'un logiciel extrêmement sophistiqué qui contrôle de nombreuses parties du fonctionnement du système. Ce logiciel fonctionne à plusieurs niveaux et à chaque niveau, les risques sont différents. Certains logiciels fonctionnent à une échelle extrêmement étroite et nous ignorons qu’ils fonctionnent. Ainsi, par exemple, le système d’injection de carburant d’une voiture est entièrement automatisé. Nous pouvons dire cela à propos de nombreuses fonctions d’une voiture qui traite de la performance de son moteur. Ainsi, par exemple, de nombreux passionnés de voitures achètent des programmeurs et des puces qui permettent d’apporter des modifications après-vente sur les caractéristiques de performance d’une voiture. L'échec de l'un de ces types de systèmes peut toujours être fatal. Les normes SAE décrites ci-dessus s’appliquent toutefois à l’automatisation de la conduite et non à celle du moteur. L'automatisation présente une différence marquée en ce qui concerne la direction et l'automatisation qui maintient le bon fonctionnement des moteurs.

L'automatisation telle que le contrôle de traction ou la stabilisation de la voiture affecte la direction. Ceux-ci sont engagés dans des conditions exceptionnelles étroites pour assurer une plus grande sécurité des passagers. Le comportement contrôlé est injecté dans une situation afin qu'un conducteur puisse mieux contrôler un véhicule qu'il n'aurait pas pu autrement le faire lui-même. Dans ce contexte, un conducteur ne contrôle pas momentanément la voiture.

De nombreux avions sont tombés du ciel en raison de problèmes de logiciel. Mon premier souvenir de ce genre de catastrophe est celui du vol 004 de Lauda Air, en mai 1991. C’est l’un des moteurs qui renverse la confiance qui s’engage en plein vol, forçant l’avion à perdre le contrôle de la situation et à s'écraser. L'auteur de la publication aéronautique Macarthur Job n'a toutefois conclu à aucune conclusion officielle: "Si le Boeing 767 était d'une version antérieure du type, équipé de moteurs à commande mécanique plutôt qu'électronique, cet accident n'aurait pu arrivé."

Plus récemment, il y a eu le cas d'Air France 447 en 2009. La conclusion officielle était qu'il y avait une «incohérence temporaire entre les vitesses mesurées, probablement en raison de l'obstruction des tubes de Pitot par des cristaux de glace, entraînant la déconnexion et la reconfiguration du pilote automatique. . ”Le verdict était que les pilotes humains faisaient finalement partie de la faute en raison de leur incapacité à réagir de manière appropriée à la situation anormale. En d'autres termes, les pilotes ont reçu des informations incorrectes de l'instrumentation et ont donc pris des mesures inappropriées pour stabiliser l'avion.

Il existe d'autres cas de pannes causées par l'ordinateur. Vol Qantas 72, il a été déterminé que la CPU de l’unité de référence inertielle de données aériennes (ADIRU) avait corrompu les données d’angle d’attaque (AOA). Malaysia Air 124 qui a plongé de 200 pieds à mi-vol. L'instrumentation a montré que l'avion «allait trop vite et trop lentement simultanément».

En général, il incombe aux pilotes d’effectuer correctement les opérations de compensation en cas de défaillance de l’équipement (loi alternative). Cependant, le point essentiel est que les erreurs informatiques dues à une panne d’équipement ne devraient pas être différentes des erreurs d’équipement habituelles et il incombe aux pilotes de prendre les mesures appropriées. Généralement, en cas d'erreur matérielle, le pilote automatique est désactivé et l'avion doit être piloté manuellement. Il s’agit d’une automatisation de niveau 3 (processus autonome) dans laquelle la portée lorsqu’elle est en jeu est explicite. Au niveau 3, le pilote est informé de conditions exceptionnelles et prend le contrôle manuel de l'avion.

Au niveau 4 (processus intelligent), un pilote doit être capable de reconnaître la condition exceptionnelle et de pouvoir spécifier quand l’automatisation est applicable. Aujourd'hui, nous avons des voitures autonomes qui sont déployées dans des applications étroites. Nous avons des voitures qui peuvent se garer et des voitures qui peuvent conduire par beau temps sur l'autoroute. Il s’agit d’automatisation de niveau 4 pour laquelle le conducteur a le choix de s’engager dans l’automatisation. Le pilote automatique dans les avions est automatisé de niveau 4 et est utilisé dans des contextes de faible complexité.

Il y a ensuite le cas du MCAS 737 Max 8 de Boeing. Ceci, je vais le dire, est une automatisation de niveau 5, il s’agit d’un processus entièrement automatisé dans lequel il est prévu de fonctionner dans tous les scénarios. Comme les composants électroniques qui contrôlent les performances des moteurs, les processus entièrement automatisés ne sont généralement pas problématiques. Cependant, lorsque vous impliquez de conduire (ou de piloter des avions), cela pose la question de la maturité de ce niveau d’automatisation.

Airbus propose ce qu’on appelle «Alpha Protection»:

Le logiciel de «protection alpha» est intégré à chaque avion Airbus afin d’empêcher celui-ci de dépasser ses limites de performances en angle d’attaque, et entre automatiquement lorsque ces limites sont atteintes.

De par sa définition, la protection Alpha est une automatisation qui mesure toujours, mais n’est pas toujours active. C'est comme un limiteur de vitesse qui existe dans les voitures d'aujourd'hui, il mesure en permanence, mais n'est activé que lorsque les mesures dépassent les seuils. Cependant, que se passe-t-il lorsque les mesures sont incorrectes en raison de capteurs défectueux? On pourrait soutenir que c'est peut-être ce qui est arrivé à Air France 447. Autrement dit, l'automatisation est devenue active lorsque les pilotes ne s'y attendaient pas. Les capteurs défectueux sont toujours problématiques, mais des capteurs défectueux pouvant déclencher un comportement automatisé peuvent être extrêmement dangereux.

Le Boeing 737 Max 8 est doté d’un système appelé Système d’augmentation des caractéristiques de manœuvre (MCAS). La motivation commerciale derrière MCAS est elle-même assez révélatrice. Apparemment, cela ressemble à un correctif logiciel qui tente de réparer une faille physique de l'aéronef. Le Boeing 737, introduit en 1968, est un avion extrêmement mature et fiable. Le 737 est l’appareil le plus vendu au monde, avec plus de 10 000 appareils vendus depuis sa création. Il a été favorisé par de nombreuses compagnies aériennes à budget court-courrier qui ont augmenté au cours de la dernière décennie. Son principal concurrent, l’Airbus A320, où plus de 8 000 avions ont été livrés depuis sa création en 1988.

En 2008, la société commune franco-américaine CFM a lancé un moteur plus économique et moins polluant, le moteur Leap. Airbus a équipé ses nouveaux avions (Airbus A320neo) de ce nouveau moteur. La raison de l’économie du moteur Leap est son diamètre d’admission d’air beaucoup plus grand.

Pour être compétitif, le Max 8 a également été équipé de ce nouveau moteur. Toutefois, contrairement à l’A320neo, la garde au sol pour le moteur Leap n’était pas suffisante. Pour compenser ce problème, Boeing a réduit la distance entre le moteur et le dessous de l'aile. Ceci, cependant, a eu pour effet de changer le centre de masse de l'avion. Le Max 8 a maintenant la tendance dynamique à lever le nez, ce qui accroît le risque de décrochage.

Pour étayer cette tendance, Boeing a développé MCAS. Le but de MCAS est qu’il s’agisse d’un logiciel dédié à la compensation de cette faille:

Les ingénieurs de Boeing ont à leur tour proposé une autre solution de fortune. Ils ont développé un logiciel qui fonctionnerait en arrière-plan. Dès que le nez de l'aéronef était trop incliné vers le haut, le système activait automatiquement l'avion arrière et ramènerait l'aéronef dans un avion de croisière sûr. Les pilotes n’auraient même pas remarqué l’intervention du logiciel - du moins c’était l’idée.

L’utilisation de logiciels pour compenser l’instabilité naturelle d’un avion n’est pas nouvelle. La plupart des avions de combat les plus avancés sont conçus pour être instables afin de garantir une plus grande maniabilité. Les pilotes de chasse sont également formés pour anticiper les caractéristiques de vol particulières de leurs avions. En revanche, de nombreuses plaintes ont été déposées contre des pilotes du Max 8 n’ayant pas été dûment informés de l’existence du système MCAS:

«Il y a 1 400 pages et une seule mention du tristement célèbre système d’augmentation des caractéristiques de manoeuvre (MCAS)… dans les sections sur les abréviations. Mais le manuel n'inclut pas d'explication sur ce que c'est ... "

Peut-être Boeing a-t-il déterminé que les pilotes ne s'intéressaient pas à ce système. Après tout, le système MCAS avait pour objectif de donner au 737 Max 8 le même «toucher» que le modèle précédent, le 737 NG. C’est ce que nous appelons dans les cercles logiciels la virtualisation. C’est-à-dire qu’il s’agit d’un logiciel qui restitue une machine virtuelle sur l’interface utilisateur du pilote, de sorte qu’elle se comporte et se comporte comme un autre type d’avion (c’est-à-dire dont la structure est équilibrée).

Il existe une «loi» dans le développement de logiciel connue sous le nom de «Loi des abstractions qui fuient» qui stipule «Toutes les abstractions non triviales, dans une certaine mesure, présentent des fuites». MCAS est peut-être une abstraction qui fuit, c'est-à-dire abstraction virtuelle d'un ancien moteur 737 NG sans moteurs Leap, pour masquer un avion déséquilibré. Sûrement, rien ne peut fuir avec ce genre d'abstraction? Abstraire les machines virtuelles, c’est une chose d’essayer d’abstraire les réalités physiques. Cependant, dans les deux cas, quelque chose finira par fuir.

Alors, le MCAS se comporte-t-il lorsque ses abstractions commencent à couler? Voici ce qui est rapporté par les pilotes de l'avion:

"Sur le NG et le MAX, lorsque vous avez un coup de couteau ceci peut être arrêté temporairement en tirant la colonne de contrôle dans la direction opposée. Mais lorsque le MCAS est activé en raison d'un angle d'attaque élevé, cela ne peut être arrêté qu'en coupant le moteur de trim électrique. ”

La manière dont un pilote réagit à une fuite d’abstraction peut être très différente de la réalité qu’elle tente d’abstraire. Avec des capteurs défectueux, on peut désactiver cela et utiliser sa compréhension de la situation et de l’avion pour prendre de bonnes décisions. Cependant, lorsque la compréhension de la nature de l’avion est virtuelle et non réelle, vous ne pouvez tout simplement pas revenir à la réalité. La réalité est en dehors de la compréhension du pilote et est donc une cause de mauvaise prise de décision. Une corbeille virtuelle fonctionne comme une corbeille normale en ce sens que vous pouvez toujours récupérer les documents que vous placez dans la corbeille avant qu'elle ne soit vidée. La réalité est cependant très différente du monde virtuel, bien souvent, il n’ya pas de fonction d'annulation!

Ensuite, il y a cette abstraction qui fuit quand l'avion lui-même a montré ses propres intentions:

Mais l'EFS n'agit jamais seul, nous avons donc été stupéfaits d'apprendre la véritable raison. (…) Cependant, dans certains cas - comme ce fut le cas pour le vol 610 - le MCAS se déplace tout seul.

En effet, une abstraction virtuelle d'un avion réel est identique à l'automatisation de niveau 5! Si le MCAS est désactivé, les pilotes se retrouveront à piloter un avion complètement différent. Lorsque vous abstenez l’interaction distante avec la réalité, vous ne pouvez pas éviter d’introduire un processus qui sert de médiateur entre l’action du pilote et les actions réelles de l’avion. Le comportement du plan réel dépendra de l'environnement dans lequel il se trouve. Le comportement d'un plan virtuel dépendra uniquement des capteurs opérationnels disponibles pour restituer la simulation virtuelle. L'automatisation de niveau 5 nécessite une sorte d'intelligence qui sait quels capteurs sont défectueux et qui est en outre capable de gérer un problème avec des informations partielles et non observées. Le bon sens pour permettre ce type d’intelligence artificielle n’est tout simplement pas disponible dans notre état actuel de développement technologique.

En bref, Boeing a décidé de mettre en œuvre une technologie trop ambitieuse. Tous les logiciels n'ont pas le même niveau de complexité. Ce n’est pas un problème de test insuffisant pour découvrir les failles logiques du logiciel. Ce n’est pas un problème de manipulation robuste de capteur ou de défaillance d’équipement. Il s’agit de tenter de mettre en œuvre une solution trop ambitieuse et donc dangereuse.

Le transport aérien est extrêmement fiable, mais l’introduction de correctifs logiciels en tant que moyen de virtualiser le comportement physique peut avoir des conséquences inattendues. La raison pour laquelle nous pilotons toujours des avions avec des pilotes est que nous nous attendons à ce que les pilotes soient capables de résoudre des situations imprévues que l'automatisation ne peut pas gérer. MCAS aime la virtualisation, menaçant les pilotes de la différenciation entre le réel et le simulé. Je recommanderais donc aux régulateurs qu'à l'avenir, la virtualisation MCAS, comme la virtualisation, soit traitée et testée de manière très différente des autres automatismes. Ils doivent être traités comme une automatisation de niveau 5 avec un niveau d'examen plus exhaustif.

Lectures complémentaires

Show More

SupportIvy

SupportIvy.com : Un lieu pour partager le savoir et mieux comprendre le monde. Meilleure plate-forme de support gratuit pour vous, Documentation &Tutoriels par les experts.

Related Articles

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Close
Close