Découvrez comment intégrer facilement l'analyse statique, les tests unitaires et d'autres méthodes de test de logiciels C et C++ dans votre pipeline CI/CD. Inscrivez-vous pour la démo >>

Défauts de génie logiciel automobile à la hausse

Par Alan Zeichick

25 août 2016

3  min lire

«Il faut des dizaines de microprocesseurs exécutant 100 millions de lignes de code pour sortir une voiture haut de gamme de l'allée, et ce logiciel ne fera que devenir plus complexe.» - Robert N. Charette, Spectre IEEE: Cette voiture fonctionne sur code

La citation ci-dessus a été tirée d'un article écrit il y a sept ans - avant que la Model S de Tesla ne sorte de la chaîne de montage, avant que Google ne commence à tester des voitures autonomes et avant que les systèmes d'infodivertissement intégrés ne deviennent la norme sur les modèles encore plus bas de gamme. L'ingénierie logicielle automobile pour les voitures d'aujourd'hui est considérablement plus complexe. De nombreux modèles ont plus de 100 unités de commande électroniques (ECU), qui sont responsables de tout, de la surveillance d'un capteur à la commande d'un actionneur. Avec autant de complexité intégrée aux logiciels automobiles, il n'est pas étonnant que les défauts liés aux logiciels soient à la hausse.

Qu'est-ce qu'un ECU?

Un ECU se compose généralement d'un assemblage de boîte noire avec un microprocesseur intégré, une mémoire, un micrologiciel, une connexion réseau et des circuits pour exécuter sa fonction. Les automobiles modernes se composent d'un nombre croissant de calculateurs connectés par un bus de communication réseau sophistiqué qui utilise de plus en plus couramment Ethernet.

Le logiciel embarqué de l'ECU peut être conçu et codé par le constructeur automobile ou fourni par un tiers de la vaste chaîne d'approvisionnement automobile. Lorsque les calculateurs sont assemblés dans un véhicule fini, l'ensemble du système doit être testé pour s'assurer que tous les composants - pas seulement les composants essentiels et critiques pour la sécurité - fonctionnent correctement. En fait, le moteur, les freins, les airbags et d'autres caractéristiques et fonctions ne fonctionneront même pas sans logiciel. C'est pourquoi, comme l'écrivait M. Charette en 2009, la voiture fonctionne autant avec le code qu'avec le carburant.

Assurer la qualité des logiciels automobiles

Le constructeur automobile a l'entière responsabilité juridique et éthique de s'assurer que le véhicule est sûr à posséder et à utiliser, ce qui comprend l'exécution de l'assurance qualité à plusieurs niveaux. Par exemple:

  • S'assurer que les freins se déclenchent lorsque vous appuyez sur la pédale (sécurité fonctionnelle)
  • Prévention des fuites de mémoire qui dégradent les performances des capteurs d'oxygène du moteur au fil du temps (sécurité non fonctionnelle)
  • Empêcher un hacker d'exploiter le système de surveillance de la pression des pneus ou d'accéder à la télémétrie téléchargée via des liens cellulaires (cybersécurité)

Lorsqu'un défaut est détecté, le fabricant peut réagir de plusieurs manières. Si le défaut est très mineur et ne constitue pas une menace pour les performances ou la sécurité du véhicule, le fabricant peut simplement choisir de l'ignorer. Si le défaut représente un coût potentiel, mais n'est pas critique pour la sécurité, le micrologiciel peut être mis à niveau lors de la prochaine révision de la voiture. Une version plus récente d'un sous-ensemble remplaçable peut également inclure un micrologiciel mis à jour. Certains constructeurs automobiles ont opté pour des mises à niveau en direct (OTA) pour les modèles et les calculateurs compatibles. Dans de nombreux cas, le fabricant peut ne pas être tenu de divulguer le correctif logiciel au client ou à une agence de réglementation.

Le vrai coût de la qualité comprend le coût des rappels

Si un défaut grave ayant des implications critiques pour la sécurité est détecté, le fabricant peut être amené à émettre un rappel. Les rappels ont lieu soit volontairement, soit à la «demande» d'un organisme de réglementation. Le rappel inclurait des logiciels, qui pourraient devoir être testés et approuvés avant d'être expulsés.

Il est difficile de connaître avec certitude le coût des logiciels défectueux dans les voitures, mais comme les rappels sont rendus publics, nous avons un aperçu des coûts et des tendances. De 2005 à 2012, il y a eu 32 rappels automobiles incluant des correctifs logiciels affectant 3.6 millions de véhicules. Au cours des 3.5 années suivantes, de 2012 à juin 2015, 63 rappels ont été associés à un composant logiciel affectant 6.4 millions de voitures. En deux fois moins de temps, l'impact des défauts logiciels a presque doublé.

De plus, seulement 5% environ des rappels de véhicules automobiles comportaient une composante logicielle en 2011. En 2015, ce nombre est passé à près de 15%.

Ces rappels liés au logiciel affectent chaque partie du véhicule. De 2006 à 2015, il y a eu des rappels liés à des logiciels pour les systèmes de pneus (p. Ex., Les systèmes de surveillance de la pression des pneus), la structure du véhicule, les loquets et les verrous, le système d'alimentation en carburant, le groupe motopropulseur, le régulateur de vitesse du véhicule (c.-à-d. visibilité et éclairage extérieur, freins de stationnement, propulsion hybride, refroidissement moteur et moteur, direction, airbags et électricité. Pour en savoir plus sur les rappels liés aux logiciels, consultez notre article précédent, "Quantification du risque de défaillance des logiciels automobiles: le rapport de garantie et de rappel SRR. »

Par Alan Zeichick

Alan Zeichick est analyste principal chez Camden Associates; auparavant, Alan était rédacteur en chef du SD Times de BZ Media. Suivez-le @zeichick.

Recevez les dernières nouvelles et ressources sur les tests de logiciels dans votre boîte de réception.