Comment tirer parti des normes de développement de logiciels automobiles pour atténuer les risques

Certaines organisations considèrent la conformité à la norme ISO 26262, MISRA et à d'autres normes comme un fardeau supplémentaire, mais la vérité est que le coût des pannes associées aux défauts logiciels est beaucoup, beaucoup plus élevé que le coût de la garantie de la qualité.

Lorsque les consommateurs non-ingénieurs moyens pensent aux systèmes électroniques dans les automobiles, ils pensent probablement au GPS intégré, aux systèmes d'infodivertissement et probablement à une vague idée qu'il y a un ordinateur quelque part dans la voiture contrôlant certaines des fonctions de sécurité. Bien sûr, la réalité est que les voitures modernes sont beaucoup plus complexes, les logiciels jouant un rôle de plus en plus important dans toutes les facettes de la fonctionnalité, y compris de nombreuses fonctions critiques pour la sécurité.

En fait, les voitures exploitent les systèmes électroniques pour des fonctionnalités critiques depuis des décennies, et les changements du marché, tels que la poussée vers un «Internet des objets», ont poussé les constructeurs automobiles à intégrer un plus grand nombre de systèmes informatiques complexes qui couvrent toute la gamme de la criticité.

Les structures commerciales et les chaînes d'approvisionnement associées au développement du système ajoutent encore à la complexité. Il est rare, voire pas du tout, qu'un fabricant conçoit et construit chaque composant et sous-système de sa voiture à partir de zéro, ce qui entraîne des problèmes d'intégration potentiels. Une transmission est tirée de ce modèle, un bon système de freinage de celui-là. Bien qu'ils aient bien fonctionné dans leur environnement précédent, dans un système complexe totalement nouveau, ils peuvent très bien avoir des résultats inattendus et inattendus. En conséquence, les logiciels automobiles sont souvent un méli-mélo complexe de systèmes qui peuvent ou non avoir été suffisamment testés. La mise en œuvre de composants de manière ad hoc sans tests appropriés, en particulier dans les applications critiques pour la sécurité, peut être extrêmement coûteuse.

L'avantage, cependant, est qu'il existe des pratiques connues pour aider les constructeurs automobiles à atténuer le risque de défaillance en intégrant la qualité des logiciels dans leurs processus de développement. Dans cet article, nous aborderons certains des problèmes contribuant à la complexité des logiciels automobiles, ainsi que les risques associés au développement de logiciels automobiles. Nous discuterons également de la manière dont la mise en œuvre des meilleures pratiques de développement connues, telles que ISO 26262, aide les organisations à atténuer ces risques.

Plus de code entraîne-t-il plus de risques?

Selon certaines estimations, une voiture standard de milieu de gamme peut avoir plus d'une centaine d'unités de commande électroniques (ECU) traitant des millions de lignes de code - et ce nombre est en augmentation. Il n'est pas rare qu'un constructeur dispose de plusieurs modèles de voitures avec plus de cent millions de lignes de code.

On a l'impression que plus la voiture est chère, plus le logiciel est intégré et que la plupart des logiciels sont dédiés aux composants d'infodivertissement haut de gamme. S'il est vrai que ces systèmes deviennent de plus en plus complexes à mesure que vous progressez dans la gamme de modèles, même les gammes de voitures de lancement utilisent un logiciel pour contrôler la direction, les systèmes de freinage, la distribution d'énergie électrique, etc. Et même des changements apparemment mineurs dans les fonctionnalités, telles que Bluetooth, le contrôle de la température, le régulateur de vitesse, etc., conduisent à une croissance exponentielle du code.

Nous pouvons supposer que plus de code se traduit par plus de complexité - et donc de risque, mais l'impact peut ne pas être nécessairement significatif. L'intégration de code développé à partir de diverses sources à plusieurs niveaux est un facteur plus important du risque commercial associé aux logiciels automobiles. La plupart des composants, y compris les composants basés sur des calculateurs, sont sous-traités à des fournisseurs de deuxième niveau qui sous-traitent à des fournisseurs de troisième niveau, etc. Chaque niveau précédent a des exigences spécifiques associées au composant qu'ils développent. Les organisations ont souvent (mais pas toujours) des pratiques en place pour analyser le code entrant afin de s'assurer que les composants fonctionnent comme prévu.

Mais cela suppose que chaque composant de la chaîne d'approvisionnement est un nouveau développement. En réalité, les niveaux en aval dérivent du code écrit pour une marque, un modèle et une année spécifiques. La mutation et la réutilisation du code ont lieu tout au long de la chaîne d'approvisionnement, ce qui conduit à un problème de test. Comment le fabricant met-il en œuvre des tests de bout en bout dans un écosystème de développement logiciel aussi chaotique? Lorsque l'ECU du volant a été initialement développé pour un véhicule et l'ECU du tableau de bord a été développé pour un autre véhicule, et qu'aucun ECU n'a été conçu pour le véhicule dans lequel ils sont actuellement intégrés, quel est l'impact? Comment pouvez-vous vous assurer que le système complet fonctionne comme prévu? Il est tout à fait possible que les deux systèmes réussissent les tests comme fonctionnels, mais ne peuvent pas communiquer correctement dans toutes les situations. Quel est le risque associé à cet écart?

Le coût de la qualité des logiciels

Lorsque les organisations tentent de mesurer le coût du développement de logiciels, elles ont tendance à se pencher sur des paramètres généraux: temps de développement pour les ingénieurs; temps de test pour l'assurance qualité; «Matériaux de construction» sous forme d’acquisition de licences d’outils, de compilateurs et d’autres composants d’infrastructure. Ce sont des paramètres importants, mais les coûts de l'échec sont souvent négligés.

Si le logiciel du système de freinage échoue, combien cela coûtera-t-il à l'entreprise en termes de retouches, de rappels, d'audits, de litiges et de perte de valeur des stocks? Et s'il y a une perte de vie? Nous soutenons que le coût de la qualité est le coût de développement et de test du logiciel, y compris toutes les mesures normales que nous avons identifiées plus les coûts très tangibles associés à une défaillance sur le terrain.

Les défauts coûtent beaucoup d'argent aux constructeurs automobiles. La NHTSA estime que les rappels et les correctifs dans l'ensemble de l'industrie coûtent aux constructeurs automobiles 3 milliards de dollars par an. En ce qui concerne le coût des problèmes liés aux logiciels, une estimation de 2005 de IEEE a fixé le coût pour les fabricants à 350 $ par voiture. Si l'on considère les faibles marges bénéficiaires sur une gamme de véhicules, il est concevable qu'un défaut logiciel suffisamment grave puisse gravement nuire à l'entreprise.

L'essentiel est important, mais encore plus important, les gens peuvent être gravement blessés ou même mourir à la suite d'un défaut logiciel. Et peu importe à quelle distance dans la chaîne d'approvisionnement le défaut peut provenir, les défauts et toutes leurs conséquences associées deviennent la responsabilité du constructeur automobile. En tant que telle, toute analyse des coûts liés au développement de logiciels doit prendre en considération les coûts potentiels d'une défaillance.

L'état actuel du développement logiciel

Nous avons fait valoir que la complexité de la chaîne d'approvisionnement à plusieurs niveaux pour les logiciels automobiles contribue au risque global associé aux systèmes critiques pour la sécurité. Nous avons également rappelé les coûts potentiels pour les entreprises automobiles. Mais il y a une autre dimension à ce problème qui réside dans la différence culturelle entre l'ingénierie et le développement de logiciels.

Le développement de logiciels n'est presque jamais de l'ingénierie. Autrement dit, certains concepts issus des principes d'ingénierie, tels que la répétabilité, les meilleures pratiques bien appliquées et le recours aux normes de construction ne sont pas encore fermement établis dans le développement de logiciels. De plus, la formation des développeurs de logiciels peut être incohérente, voire inexistante, et les organisations devraient passer beaucoup de temps pour vérifier que leurs développeurs possèdent les connaissances adéquates pour créer des logiciels critiques pour la sécurité.

Cela contraste avec l'ingénierie dans laquelle les attitudes, les mentalités et l'histoire de la discipline imposent un processus moins sujet aux défauts que le développement de logiciels. Cela ne veut pas dire que les ingénieurs savent ce qu'ils font et que les développeurs de logiciels ne le savent pas. C'est plutôt dire que l'ingénierie automobile en tant que domaine est deux fois plus mature que le développement logiciel, et que la nature intangible et temporelle du logiciel perpétue une attitude cavalière dans laquelle si cela fonctionne, alors c'est fait.

Dans le développement logiciel, l'accent est mis sur une livraison plus rapide et des exigences fonctionnelles - à quelle vitesse pouvons-nous avoir cette fonctionnalité? La direction n'est guère incitée à mettre en œuvre de saines pratiques d'ingénierie dans le cycle de vie du développement logiciel. Atteindre la sécurité fonctionnelle dans le logiciel nécessite la mise en œuvre de certains principes d'ingénierie:

• La sécurité fonctionnelle doit être proactive
• Les processus doivent être contrôlés, mesurés et reproductibles
• Les défauts doivent être évités grâce à la mise en œuvre de normes
• Les tests doivent être efficaces et déterministes
• Des tests doivent être effectués pour des problèmes de mémoire complexes

La bonne nouvelle est que les attitudes vis-à-vis du développement logiciel ont évolué. ISO 26262, MISRA et d'autres normes visent à normaliser le développement de logiciels pour les applications automobiles en fournissant une base pour la mise en œuvre de concepts d'ingénierie dans les processus de développement de logiciels. Certaines organisations considèrent la conformité à la norme ISO 26262 et à d'autres normes comme une charge supplémentaire sans aucune valeur directe, mais la vérité est que le coût de l'échec associé aux défauts logiciels est beaucoup, beaucoup plus élevé que le coût de la garantie de la qualité. Comme dans les normes électriques qui spécifient un calibre spécifique de fil pour transporter une tension connue, les normes de codage peuvent fournir des directives qui aident à éviter une catastrophe.

ISO 26262 , MISRA et d'autres normes cherchent à normaliser le développement de logiciels pour l'automobile applications en fournissant une base pour la mise en œuvre de concepts d'ingénierie dans les processus de développement de logiciels. Certaines organisations considèrent la conformité à la norme ISO 26262 et à d'autres normes comme un fardeau supplémentaire, mais la vérité est que le coût de l'échec associé aux défauts logiciels est beaucoup, beaucoup plus élevé que le coût de la garantie de la qualité.

« MISRA », « MISRA C » et le logo triangulaire sont des marques déposées de The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. Tous droits réservés.

Par Parasoft

Les outils de test de logiciels automatisés de pointe de Parasoft prennent en charge l'ensemble du processus de développement logiciel, depuis le moment où le développeur écrit la première ligne de code jusqu'aux tests unitaires et fonctionnels, jusqu'aux tests de performance et de sécurité, en exploitant des environnements de test simulés en cours de route.