Conformité des logiciels ISO 26262 dans l'industrie automobile

Exigences réglementaires du WP.29 de la CEE-ONU

La Commission économique des Nations Unies pour l'Europe (CEE-ONU) a publié le 23 juin 2020 des exigences réglementaires qui décrivent les nouveaux processus et technologies que les constructeurs automobiles doivent intégrer à leur organisation et à leurs véhicules. Ces réglementations s'appliquent également aux fournisseurs de composants logiciels et matériels de niveau 1 et de niveau 2, y compris les services mobiles.

Les constructeurs automobiles sont tenus d’intégrer dans leur structure organisationnelle un cadre de gestion basé sur les risques pour découvrir, analyser et se protéger contre les menaces, les vulnérabilités et les cyberattaques pertinentes.

Les catégories suivantes nécessitent des tests de cybersécurité et des inspections de réussite.

• La catégorie M couvre les voitures standard à quatre roues.
• La catégorie N est réservée aux camionnettes et aux fourgonnettes.
• Les catégories L6 et L7 comprennent les voitures électriques et les capacités autonomes.

Une note de passage aux exigences clés du WP.29, tant organisationnelles que pour les véhicules, signifie que le constructeur reçoit un certificat de conformité. Les nouveaux véhicules sans ce certificat ne pourront pas être vendus dans l'UE après juillet 2024. Sachez que les États-Unis ne participent pas à ce programme et n'ont pas de réglementation similaire. Cependant, la situation est déjà claire.

Épices pour l'automobile

L'amélioration des processus logiciels et la détermination des capacités dans le secteur automobile (ASPICE) fournissent un cadre de mesure permettant aux évaluateurs indépendants d'évaluer la capacité d'une organisation à développer des logiciels. Assurer la sécurité des logiciels et la cybersécurité ne se limite pas aux aspects techniques du développement du système électronique, mais nécessite également que l'organisation intègre des processus et des contrôles.

Ces processus et contrôles doivent inclure des moyens de suivre et de surveiller les progrès dans toutes les pratiques de l’organisation afin de garantir :

1. Des pratiques de sécurité et de cybersécurité ont été adoptées.
2. Les exigences de sécurité et de cybersécurité sont satisfaites.

Il s’agit également de l’un des deux principaux critères de certification du WP.29 de la CEE-ONU sur la capacité organisationnelle en matière de cybersécurité.

Scénarios dangereux

Elle a permis de concrétiser d'autres développements de la norme ISO 26262, comme la norme ISO/PAS 21448, plus communément appelée SOTIF (sécurité de la fonctionnalité prévue). La norme SOTIF vous aide à analyser et à prévenir l'utilisation abusive de la fonctionnalité prévue lorsqu'elle crée un scénario dangereux. Par exemple, votre véhicule s'arrête par inadvertance pendant que vous le conduisez, en raison d'une mise à jour logicielle lancée.

Les vulnérabilités de sécurité peuvent également entraîner des scénarios dangereux. Un attaquant pourrait utiliser la connexion Wi-Fi du véhicule pour exploiter à distance un port exposé. Il pourrait d'une manière ou d'une autre passer du système d'infodivertissement embarqué avancé (IVI) au contrôle ou à l'influence de composants critiques pour la sécurité, comme le freinage ou la direction, en raison du partage de la même infrastructure de communication.

Le rôle des normes

Des normes telles que la norme SAE J3061, remplacée par la norme ISO/SAE 21434, précisent qu'une analyse initiale des menaces et une évaluation des risques (TARA) doivent être réalisées pour évaluer les menaces potentielles liées à l'exploitation, à la confidentialité et à d'autres facteurs pouvant affecter un usager/conducteur de la route. Si le risque d'une menace est suffisamment élevé, un processus de cybersécurité est alors nécessaire. Il existe différentes approches pour éliminer les vulnérabilités en matière de sécurité et les exigences qui atténuent les risques. En savoir plus sur TARA et pourquoi votre équipe de développement a besoin de TARA.

Des normes telles que la norme UL 4600 existent désormais spécifiquement pour le fonctionnement entièrement autonome des véhicules. Cela signifie qu'il n'y a aucune supervision humaine et que l'autonomie assume l'entière responsabilité. Cette norme se concentre sur la construction d'un dossier de sécurité pour le déploiement de véhicules SAE de niveau 4/5, et non sur la manière de tester la sécurité des véhicules autonomes sur la voie publique. Cela impliquerait une norme différente.

Ces normes et d’autres jouent un rôle crucial dans la sécurité et la sûreté de l’industrie automobile. Les constructeurs automobiles assument les coûts de responsabilité liés à la livraison de véhicules dangereux et peu sûrs au grand public. Pour atténuer ces risques, les constructeurs automobiles doivent adopter et respecter ces normes. Cependant, ils doivent exiger la même qualité et le même respect de la part de leurs fournisseurs. Une faiblesse dans un composant peut compromettre la sécurité et la sûreté de l’ensemble du système.

Élaboration de normes de codage personnalisées

En collaboration avec certains de ses constructeurs automobiles, Parasoft a élaboré des normes de codage personnalisées qui intègrent MISRA, AUTOSAR C++14, CERT, CWE et d'autres règles personnalisées à utiliser par leurs fournisseurs. Cela garantit que le même niveau de qualité de logiciel existe tout au long de la chaîne d'approvisionnement.

Parasoft C/C++test est une solution de test unifiée qui inclut les tests unitaires et la couverture du code structurel dans le cadre de ses fonctionnalités. Cette solution de développement de logiciels C/C++ prend en charge un ensemble complet de cibles matérielles et d'écosystèmes de développement que les fournisseurs et les OEM peuvent utiliser avec différentes infrastructures de développement. C/C++test a été certifié par TÜV SÜD pour une utilisation sur des systèmes critiques pour la sécurité et la sûreté. Pour les ADAS et les voitures connectées sécurisées, les intégrations transparentes de C/C++test avec SOAtest et Virtualiser combinez les tests d'API avec la couverture des applications d'exécution et les bancs d'essai virtuels simulés.

Réalisation d'une analyse des dangers et d'une évaluation des risques

Dans la norme ISO 26262, une analyse des dangers et une évaluation des risques (HARA) doivent être effectuées sur le système en cours de développement. Une fois l'HARA terminée, un ASIL est attribué au composant logiciel et il existe des niveaux A à D. Le niveau A représente l'attribution du danger le plus faible et le niveau D représente l'attribution du danger le plus élevé. Cela signifie que la défaillance d'un système avec l'attribution ASIL D pourrait être catastrophique.

Il existe également une attribution de niveau de gestion de la qualité (QM), ce qui signifie qu'il n'y a aucune exigence de sécurité. L'ASIL est attribué en prenant la gravité de la blessure multipliée par la probabilité de la défaillance multipliée par la contrôlabilité. Le tableau suivant détaille chaque niveau de gravité, d'exposition et de contrôlabilité.

Gravité = Quel serait l’impact ou les dommages si la panne se produisait ?

Exposition = La fréquence ou la probabilité que la défaillance se produise.

Contrôlabilité – La mesure dans laquelle nous pouvons garantir que l’événement ne se produira pas.

Plusieurs tableaux sont disponibles gratuitement et permettent de déterminer la valeur ASIL. Le tableau ci-dessous est un exemple beaucoup plus facile à lire et présente les niveaux ASIL en couleurs en fonction de la gravité, de l'exposition et de la contrôlabilité.

Sécurité Active et Passive

Les véhicules routiers sont équipés de nombreux systèmes de sécurité, certains étant considérés comme des systèmes de sécurité active et d'autres comme des systèmes de sécurité passive.

La sécurité active est utilisée pour désigner la technologie qui contribue à prévenir un accident. Vous avez le contrôle de traction, le système de freinage antiblocage, le Vision ADAS et d'autres.

Les systèmes de sécurité passive assurent la sécurité des passagers. Par exemple, en cas d'accident, vous disposez d'airbags et de ceintures de sécurité. L'essuie-glace électronique et le combiné d'instruments sont également des systèmes de sécurité passive.

Réalisation de tests, de vérification et de validation de la conception et de la mise en œuvre d'unités logicielles

Étant donné que ce guide est axé sur les logiciels, il est important de couvrir les méthodes de vérification et de validation des tests recommandées par la norme. Par exemple, le tableau 7 répertorie les méthodes de vérification 1a à 1k à appliquer lors de la conception et de la mise en œuvre de l'unité. La méthode 1h, « Analyse de code statique », est fortement recommandée pour les niveaux ASIL A à D.

Les colonnes du tableau 7 à droite indiquent les niveaux ASIL de A à D. Un seul symbole « + » indique que la norme le recommande, un double « ++ » indique qu'il est fortement recommandé et un « o » indique qu'il n'y a aucune recommandation.

D’autres méthodes de vérification clés sont réalisées par analyse dynamique, pour les tests basés sur les exigences et l’injection de fautes. Le tableau 26262 de la norme ISO 8, par exemple, contient une « analyse des valeurs limites ». Il s’agit d’une méthode permettant de dériver un cas de test pour éliminer les défauts en prouvant des entrées dans l’unité qui ne sont pas seulement les valeurs minimales, moyennes et maximales, mais aussi les limites en dehors de la portée de sa plage, pour voir si l’unité est suffisamment robuste pour gérer ces cas aberrants.

Le tableau 9 répertorie les mesures de couverture du code structurel recommandées pour garantir la couverture des tests, éliminer le code mort et les défauts cachés.