URL: https://linuxfr.org/users/zarmakuizz/journaux/encore-un-exemple-de-code-spaghetti-toyota Title: Encore un exemple de code spaghetti : Toyota Authors: Zarmakuizz Date: 2014年03月05日T22:11:19+01:00 License: CC By-SA Tags: c, génie_logiciel, automobile, toyota, embarqué et mauvaises_pratiques Score: 96 Cher nourjal, Après les journaux successifs sur l'instruction goto, je reçois un mail d'un de nos professeurs par rapport à une affaire où les freins d'une Toyota ont refusé de fonctionner à cause d'un code spaghetti : http://www.safetyresearch.net/2013/11/07/toyota-unintended-acceleration-and-the-big-bowl-of-spaghetti-code/ L'article est très long et en angliche, ça date du 13 novembre 2013, je vais tenter un résumé : Jean Bookout et Barbara Schwarz avaient une Toyota Camry de 2005. Le système de freinage est contrôlé par l'électronique du système. Mais voilà qu'un jour Jean Bookout perd le contrôle de sa voiture, la pédale de frein n'a aucun effet sur la vitesse de la voiture. Qu'à cela ne tienne, elle utilise donc le frein à main, ce qui fait une grosse marque de dérapage sur la route mais la vitesse du véhicule ne diminue pas, eeeeeeeet c'est le crash. Barbara Schwarz meurt des blessures, Jean Bookout se retrouve à l'hôpital pendant 5 mois. Suite logique, procès à Toyota. Bon, on est aux États-Unis, on ne sait pas si c'est surtout sur les raisons techniques évoquées plus loin ou plutôt par patriotisme que les jurés ont déclaré Toyota coupable dans l'affaire, mais passons ce détail pour nous concentrer sur la suite. Mais comment les freins ont pu ne plus marcher ? Deux experts ont été désignés par l'accusation pour analyser le code source de Toyota pour juger par eux-même d'où pouvait provenir la défaillance. [Michael Barr](http://en.wikipedia.org/wiki/Michael_Barr_%28software_engineer%29) est resté 20 mois dans une salle semblable à une chambre d'hôtel, avec des gardes pour s'assurer qu'aucun document ne rentre ou ne sortirait de sa salle pendant tout le temps de son analyse. [Phillip Koopman](https://www.ece.cmu.edu/~koopman/) est plutôt à l'aise dans le domaine de l'embarqué. On peut résumer le reste de l'article en : "c'est un gros code spaghetti impossible à maintenir, impossible à prédire, impossible à tester, des corruptions mémoires arrivent trop facilement, etc". Mais il y a quand même quelques perles : > There are a large number of functions that are overly complex. By the standard industry metrics some of them are untestable, meaning that it is so complicated a recipe that there is no way to develop a reliable test suite or test methodology to test all the possible things that can happen in it. Some of them are even so complex that they are what is called unmaintainable, which means that if you go in to fix a bug or to make a change, you’re likely to create a new bug in the process. Just because your car has the latest version of the firmware — that is what we call embedded software — doesn’t mean it is safer necessarily than the older one....And that conclusion is that the failsafes are inadequate. The failsafes that they have contain defects or gaps. But on the whole, the safety architecture is a house of cards. It is possible for a large percentage of the failsafes to be disabled at the same time that the throttle control is lost.> Even a Toyota programmer described the engine control application as "spaghetti-like" in an October 2007 document Barr read into his testimony. Ce qui donnerait en bon françois : > Une grande proportion des fonctions du code sont bien trop compliquées. D'après les mesures aux normes du secteur, certaines d'entre elles sont impossibles à tester, signifiant que son fonctionnement est tellement compliqué qu'il n'est pas possible de développer une suite de test fiables ou d'avoir une méthodologie de test pour vérifier tout ce qui se passe à l'intérieur. Certaines sont tellement compliquées qu'on peut les qualifier d'impossibles à maintenir, ce qui veut dire que si vous rentrez dedans pour corriger un bug ou faire un changement, vous êtes assuré de créer un nouveau bug au passage. Ce n'est pas parce que votre voiture a la dernière version d'un firmware (c'est ce qu'on appelle du logiciel embarqué) que c'est nécessairement plus fiable que le firmware plus ancien... Et la conclusion de cela est que les sécurités [employées] sont inappropriées. Les sécurités employées ici contiennent des défauts ou des lacunes. Mais dans l'ensemble, l'architecture de sécurité est un château de cartes. Il est possible d'avoir une majeur partie des sécurités désactivées au même moment que le contrôle de l'accélération est perdu.> Même un programmeur de chez Toyota a décrit l'application de contrôle du moteur comme "du spaghetti" dans un document d'octobre 2007 que Barr a cité dans son témoignage. La suite de l'article parle de règles de bonne pratique définies par le [MISRA](http://en.wikipedia.org/wiki/MISRA) pour le développement en C dans l'automobile. Phillip Koopman dit que pour chaque pack de 30 violations de ces règles, on peut s'attendre à 3 bugs mineurs et 1 bug critique en moyenne. Michael Barr a analysé le code en suivant l'édition 2004 de la MISRA (rappel, la voiture date de 2005) et a trouvé... 81 514 violations. D'après les statistiques moyennes, on devrait donc s'attendre à environs 2720 bugs majeurs. Les programmeurs de Toyota ont défini leurs propres règles de bonne conduite et n'ont pas réussi à les respecter. Il y avait aussi plus de 10 000 variables globales, alors que les standards dans les développements de l'automobile réclament le 0 absolu. Le programme superviseur censé détecter si les tâches du moteur tournent toujours était incapable de détecter quoi que ce soit car il se contentait de monitorer le CPU, ce qu'il n'arrivait même pas à faire ! Les codes d'erreurs renvoyés par les tâches étaient complètement ignorés, aucune tracabilité possible. La NASA était censé passer le code en revue, sauf qu'apparemment le code qu'on leur a donné n'était pas le code applicatif final, et des délais trop courts ont empêché les ingénieurs de la NASA de faire leur travail d'inspection. Des mails de Toyota relatent qu'ils ont mis en place des sécurités contre les erreurs de [Bit flipping](http://en.wikipedia.org/wiki/Bit_flipping) alors que Michael Barr n'a vu absolument aucun contrôle de ce côté-là. La [NTHSA](http://en.wikipedia.org/wiki/National_Highway_Traffic_Safety_Administration), l'entité ayant autorisé la mise sur le marché de la Toyota Camry, n'avait donc pas les informations nécessaires pour savoir que la partie informatique du véhicule était complètement foireuse. Michael Barr a dû expliquer à un jury non compétent pourquoi tout ce qu'il a trouvé est un problème, ce qui fait donc d'excellentes ressources pour les étudiants et autres curieux : * Retranscription (version brouillon) du témoignage de Phillip Koopman [partie 1](http://safetyresearch.net/Library/Koopman%2010年11月13日%20a.m.PDF) et [partie 2](http://www.safetyresearch.net/Library/Koopman%2010年11月13日%20p.m.pdf) * [Retranscription du témoignage de Michael Barr](http://www.safetyresearch.net/Library/Bookout_v_Toyota_Barr_REDACTED.pdf) * [Diapositives de sa présentation au jury](http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUBBED.pdf) > [Barr's slides are] long, but well worth a read for anyone interested in understanding more about embedded software systems in automobiles and how not to design one; where NHTSA went wrong: and the unbelievably shaky software at the foundation of Toyota’s electronic architecture. Soit en français : > [Les diapos de Barr sont] longues, mais méritent la lecture pour quiconque est intéressé pour en savoir plus sur les systèmes embarqués en automobile et comment il ne faut pas en concevoir, où est-ce que la NTHSA a eu tort, et le logiciel incroyablement fragile aux fondations de l'architecture électronique de Toyota. L'article conclut sur le fait que Toyota n'aurait donc pas voulu que l'on voit son code source, non pas pour garder secret ses algorithmes, mais plutôt pour cacher le fait que c'est un merdier total.

AltStyle によって変換されたページ (->オリジナル) /