Incidents associés
De nos jours, 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 décès par billion de miles de voyages aériens commerciaux. Cela contraste fortement avec les 7 864 décès par billion de kilomètres parcourus sur l'autoroute (vous pouvez consulter les statistiques ici : décès et kilomètres parcourus par mode de transport). L'amélioration progressive du transport aérien est une merveille d'innovation technique. Cependant, lorsqu'un accident d'avion se produit, nous sommes obligés d'en tenir compte en raison de l'ampleur d'un seul événement. Aujourd'hui, le transport aérien est à un niveau de maturité technique tel que lorsqu'un avion s'écrase par accident (c'est-à-dire non dû à des causes d'origine humaine comme le terrorisme ou des ratés de missiles), cela n'est étonnamment pas dû à une erreur du pilote ou à une défaillance de l'équipement physique, mais plutôt parce que d'une erreur informatique. Autrement dit, un accident d'avion est causé par un bogue logiciel. Aujourd'hui, tout le monde connaît intimement les bogues logiciels. L'écran bleu de la mort de Microsoft et l'utilisation de ctrl-alt-delete 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 devons souvent rechercher la procédure, mais cela arrive quand même. Les logiciels sont notoirement difficiles à rendre exempts de bogues. C'est la nature de la bête. En effet, pour créer des systèmes logiciels sans bogues, nous devons répertorier 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 restreignent pas la portée de l'applicabilité d'un logiciel. En bref, les développeurs de logiciels sont capables de gérer la complexité illimitée en réduisant le champ d'application. C'est pourquoi même les applications « artificiellement intelligentes » les plus sophistiquées fonctionnent bien dans les zones les plus étroites. Il est très facile d'être frustré par les limitations des assistants vocaux comme Alexa. C'est parce que la technologie de l'IA n'a pas atteint le niveau de maturité requis pour une conversation générale ouverte. En bref, l'absence de bogue dépend fondamentalement d'un champ d'application étroit et de tests approfondis dans ce cadre étroit. Au fur et à mesure que nous construisons des logiciels plus sophistiqués qui ont des degrés de complexité plus élevés, nous devons comprendre la portée d'une application et une portée toujours croissante exige davantage de tests de ces systèmes. Ainsi, pour mieux comprendre cette complexité, nous devons comprendre les types d'automatisation que nous construisons. Comme je l'ai mentionné plus tôt, l'USDOT montre qu'il y a eu plus de 37 000 décès dans des accidents de la route en 2017 seulement. Il est donc logique de comprendre comment l'automatisation affecte la sécurité des véhicules routiers. La Society of Automation Engineering (SAE) a une norme internationale qui définit six niveaux d'automatisation de la conduite (SAE J3016). Il s'agit d'un cadre utile pour classer les niveaux d'automatisation dans des domaines autres que 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 conscients du lancement 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 enchaînement des tâches. Niveau 2 (processus multiples assistés) Les utilisateurs sont conscients du lancement et de l'achèvement d'un ensemble de tâches. L'utilisateur, cependant, n'est pas responsable de l'enchaînement correct des tâches. Un exemple sera la réservation d'un hôtel, d'une voiture et d'un vol. L'ordre exact de la réservation peut ne pas concerner l'utilisateur. Cependant, l'échec de l'exécution de cette tâche peut nécessiter des actions correctives manuelles plus étendues. Un exemple malheureux d'échec d'une action corrective est le relogement du client payant d'United Airlines. Niveau 3 (Processus sans surveillance) Les utilisateurs ne sont avisés que dans des situations exceptionnelles et sont tenus d'effectuer les travaux dans ces conditions. Un exemple de ceci est dans les systèmes qui surveillent en permanence la sécurité d'un réseau. Les praticiens 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, cependant, tous les aspects de l'exécution du processus, ainsi que la gestion 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 est cependant toujours 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 où l'intervention humaine n'est plus nécessaire dans les processus. Ceci, bien sûr, peut ne pas être 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) Il s'agit d'une automatisation qui ne nécessite aucune intervention humaine et qui est également capable de s'améliorer au fil du temps. Ce niveau va au-delà des exigences SAE mais peut être requis dans certains environnements compétitifs de haute performance tels que les courses de Robocar et les transactions boursières. Les automobiles d'aujourd'hui ont 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 dans une portée extrêmement étroite dont nous ignorons qu'ils fonctionnent. Ainsi, par exemple, le système d'injection de carburant d'une voiture est, en fait, entièrement automatisé. Nous pouvons dire cela à propos de nombreuses fonctions d'une voiture qui traitent de la performance de son moteur. Ainsi, par exemple, de nombreux passionnés de voitures achètent des programmeurs et des puces qui fournissent des ajustements après-vente sur les caractéristiques de performance d'une voiture. La défaillance de l'un de ces types de systèmes peut toujours être fatale. Les normes SAE décrites ci-dessus s'appliquent cependant à l'automatisation de la conduite et non à l'automatisation du moteur. Il existe une nette différence entre l'automatisation qui affecte 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 étroites exceptionnelles pour assurer une plus grande sécurité des passagers. Un comportement contrôlé est injecté dans une situation afin qu'un conducteur puisse acquérir un meilleur contrôle d'un véhicule qu'il n'aurait autrement pas pu faire lui-même. Dans ce contexte, un conducteur ne contrôle momentanément pas la voiture. Il y a eu de nombreux cas d'avions tombant du ciel en raison de bogues logiciels. Mon premier souvenir de ce genre de catastrophe est le vol 004 de Lauda Air en mai 1991. C'est quand l'un des moteurs inversés s'est engagé en plein vol, forçant l'avion à devenir incontrôlable et à s'écraser. Il n'y avait pas de conclusion officielle quant à la cause, cependant, l'écrivain aéronautique Macarthur Job a déclaré que "si ce Boeing 767 avait été d'une version antérieure du type, équipé de moteurs contrôlés mécaniquement plutôt qu'électroniquement, alors cet accident n'aurait pas pu avoir passé." Plus récemment, il y a 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 à la suite de l'obstruction des tubes de Pitot par des cristaux de glace, provoquant 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. Autrement dit, les pilotes ont reçu des informations erronées 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 le processeur de l'unité de référence inertielle des données aérodynamiques (ADIRU) avait corrompu les données d'angle d'attaque (AOA). Malaysia Air 124 qui a plongé de 200 pieds en plein vol. L'instrumentation indiquait que l'avion "allait trop vite et trop lentement simultanément". En général, il est de la responsabilité des pilotes d'effectuer correctement les actions compensatoires en cas de panne d'équipement (loi dite alternative). Le point est cependant que l'erreur informatique due à une panne d'équipement ne devrait pas être différente de l'erreur d'équipement normale et il est de la responsabilité des pilotes de prendre les mesures appropriées. En règle générale, en cas d'erreur d'équipement, le pilote automatique est désengagé et l'avion doit être piloté manuellement. Il s'agit d'une automatisation de niveau 3 (processus sans surveillance) où la portée lorsque l'automatisation est en jeu est explicite. Au niveau 3, un pilote est mis au courant d'une condition exceptionnelle 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 est capable de 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 nous avons des voitures qui peuvent rouler par beau temps sur l'autoroute. Il s'agit d'automatisation de niveau 4 où il appartient au conducteur d'engager l'automatisation. Le pilote automatique dans les avions est une automatisation de niveau 4 et est engagé dans des contextes de faible complexité. Ensuite, il y a le cas du MCAS du 737 Max 8 de Boeing. Je soutiendrai que c'est une automatisation de niveau 5, c'est un processus entièrement automatisé dans lequel on s'attend à ce qu'il fonctionne dans tous les scénarios. Comme l'électronique qui contrôle les performances du moteur, les processus entièrement automatisés ne posent généralement pas de problème, cependant, lorsque vous impliquez la conduite (ou le pilotage d'avions), cela soulève la question de la maturité de ce niveau d'automatisation. Airbus a ce qu'on appelle "Alpha Protection": un logiciel de "protection Alpha" est intégré à chaque avion Airbus pour empêcher l'avion de dépasser ses limites de performances en angle d'attaque, et s'active automatiquement lorsque ces limites sont atteintes. D'après la définition, la protection Alpha est une automatisation qui mesure toujours, cependant, elle n'est pas toujours active. C'est comme un limiteur de vitesse qui existe dans les voitures aujourd'hui, il mesure en permanence, mais n'est activé que lorsque les mesures dépassent des seuils. Cependant, que se passe-t-il lorsque les mesures sont incorrectes en raison de capteurs défectueux ? On pourrait dire que c'est peut-être ce qui est arrivé à Air France 447. C'est-à-dire que l'automatisation est devenue active alors que les pilotes ne s'y attendaient pas. Les capteurs défectueux sont toujours problématiques, mais les capteurs défectueux qui peuvent déclencher un comportement automatisé peuvent être extrêmement dangereux. Le Boeing 737 Max 8 dispose d'un système connu sous le nom de 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, c'est analogue à un correctif logiciel qui tente de corriger un défaut physique de l'avion. L'avion Boeing 737, introduit en 1968, est un avion extrêmement mature et fiable. Le 737 est l'avion le plus vendu au monde, vendant plus de 10 000 appareils depuis sa création. Il a été favorisé par de nombreuses compagnies aériennes à petit budget court-courriers qui ont augmenté au cours de la dernière décennie. Son principal concurrent est l'Airbus A320, où plus de 8 000 avions ont été livrés depuis sa création en 1988. En 2008, une société franco-américaine CFM a lancé un moteur plus économe en carburant et plus économique connu sous le nom de moteur Leap. Airbus a équipé ses nouveaux avions (Airbus A320neo) de ce nouveau moteur. La raison de l'économie du moteur Leap est due à 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. Cependant, contrairement à l'A320neo, il n'y avait pas assez de garde au sol pour le moteur Leap. Pour compenser ce problème, Boeing a réduit la distance entre le moteur et le dessous de l'aile. Cependant, cela a eu pour effet de modifier le centre de masse de l'avion. Le Max 8 avait désormais la tendance dynamique de relever le nez et par conséquent d'augmenter le risque de décrochage. Pour masquer cette tendance, Boeing a développé le MCAS. Le but du MCAS est d'être un logiciel dédié à pallier ce défaut : les ingénieurs de Boeing, à leur tour, ont imaginé une autre solution de fortune. Ils ont développé un logiciel qui fonctionnerait en arrière-plan. Dès que le nez de l'avion pointait trop vers le haut, le système activait automatiquement l'empennage et ramenait l'avion vers un avion de croisière sûr. Les pilotes ne remarqueraient même pas l'intervention du logiciel - du moins c'était l'idée. L'utilisation d'un logiciel pour masquer l'instabilité naturelle d'un avion n'est pas nouvelle. La plupart des avions de chasse les plus avancés sont conçus pour être instables afin d'assurer 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, il y a eu de nombreuses plaintes selon lesquelles les pilotes du Max 8 n'étaient pas correctement 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 manœuvre (MCAS)… dans les sections sur les abréviations. . Mais le manuel n'inclut pas d'explication de ce que c'est..." Peut-être que Boeing a déterminé que les informations sur ce système ne méritaient pas l'attention des pilotes. Après tout, l'intention du système MCAS était de faire en sorte que le 737 Max 8 donne la même "sensation" que le modèle précédent, le 737 NG. C'est ce que nous appelons dans les cercles du logiciel la virtualisation. C'est-à-dire qu'il s'agit d'un logiciel qui rend une machine virtuelle sur l'interface utilisateur du pilote à l'avion afin qu'elle se sente et agisse comme un autre type d'avion (c'est-à-dire un avion structurellement équilibré). Il existe une « loi » dans le développement de logiciels connue sous le nom de « La loi des abstractions qui fuient » qui stipule que « Toutes les abstractions non triviales, dans une certaine mesure, sont des fuites ». Le MCAS est peut-être une abstraction qui fuit, c'est-à-dire qu'il essaie de créer une abstraction virtuelle d'un ancien 737 NG sans moteurs Leap, pour cacher un avion déséquilibré. Sûrement, rien ne peut fuir avec ce genre d'abstraction ? C'est une chose d'abstraire les machines virtuelles et c'en est une autre de tenter d'abstraire la réalité physique. Cependant, dans les deux cas, quelque chose finira par fuir. Alors, le MCAS se comporte-t-il lorsque ses abstractions commencent à fuir ? Voici ce qui est rapporté par les pilotes de l'avion : « Sur le NG comme sur le MAX, lorsque vous avez un emballement du trim, cela peut être arrêté temporairement en tirant la colonne de commande dans la direction opposée. Mais lorsque le MCAS est activé à cause d'un angle d'attaque élevé, cela ne peut être arrêté qu'en coupant le moteur de trim électrique. La façon dont un pilote répond à une fuite d'abstraction peut être très différente de celle de la chose réelle qu'il essaie 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 donc une cause de prise de décision inappropriée. Une corbeille virtuelle fonctionne comme une corbeille ordinaire 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, souvent il n'y a pas de fonction d'annulation ! Ensuite, il y a cette abstraction qui fuit lorsque l'avion lui-même a montré ses propres intentions : mais l'EFS n'agit jamais par lui-même, alors nous avons été stupéfaits quand nous avons entendu quelle était la vraie raison. (…) Cependant, dans certains cas — comme cela s'est produit sur le vol 610 — le MCAS se déplace tout seul. et ceci : le MCAS est activé sans intervention du pilote et ne fonctionne qu'en vol manuel, volets rentrés. En effet, une abstraction virtuelle d'un avion réel est la même que l'automatisation de niveau 5 ! Si le MCAS est désactivé, les pilotes se retrouveront à piloter un avion entièrement différent. Lorsque vous faites abstraction de l'interaction avec la réalité, vous ne pouvez pas éviter d'introduire un processus qui sert d'intermédiaire entre l'action d'un pilote et les actions réelles de l'avion. Le comportement de l'avion réel dépendra de l'environnement dans lequel il se trouve. Le comportement d'un avion virtuel dépendra uniquement des capteurs de travail disponibles pour rendre 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. L'intelligence permettant ce type d'intelligence artificielle n'est tout simplement pas disponible dans notre état actuel de développement technologique. Bref, Boeing a décidé de mettre en place une technologie tout simplement trop ambitieuse. Tous les logiciels n'ont pas le même niveau de complexité. Ce n'est pas un problème de tests insuffisants pour découvrir des failles logiques dans le logiciel. Il ne s'agit pas d'un problème de gestion robuste des pannes de capteur et d'équipement. Il s'agit de tenter de mettre en place une solution trop ambitieuse et donc dangereuse. Les voyages en avion sont extrêmement fiables, mais l'introduction de correctifs logiciels comme moyen de virtualiser le comportement physique peut avoir des conséquences imprévues. La raison pour laquelle nous pilotons toujours des avions avec des pilotes à bord est que nous attendons des pilotes qu'ils soient capables de résoudre des situations inattendues que l'automatisation ne peut pas gérer. Le MCAS, comme la virtualisation, empêche les pilotes de faire la différence entre le réel et le simulé. Je recommanderais donc aux régulateurs qu'à l'avenir, les MCAS comme la virtualisation soient traités et testés très différemment des autres automatisations. Ils devraient être traités comme une automatisation de niveau 5 avec un niveau de contrôle plus exhaustif.