Le logiciel du véhicule se trouve à environ 300 millions lignes de code aujourd’hui et devrait atteindre 600 millions ou plus d’ici 2027. Les nouveaux constructeurs automobiles construisent déjà des véhicules définis par logiciel (SDV), dans lesquels les fonctionnalités du véhicule sont fournies principalement par le biais de logiciels plutôt que de matériel fixe, dans 24 à 30 mois; Les anciens cycles des fabricants d’équipement d’origine (OEM) durent encore de 48 à 60 mois. Les SDV pourraient représenter 90 % de la production de véhicules d’ici 2029, contre seulement 3,4 pour cent en 2021. Entre autres facteurs, ce qui différencie les nouveaux entrants des anciens OEM est la vitesse de validation : la rapidité avec laquelle un OEM peut tester les logiciels qu’il construit.
Validation physiquey compris le matériel dans la boucle (HIL), les flottes d’essai et les terrains d’essai ont été construits à un rythme différent. Les commentaires sont liés à la disponibilité du matériel, de sorte que les défauts apparaissent tardivement, lorsque les correctifs deviennent très coûteux. La couverture physique a également un plafond : les cas rares et critiques pour la sécurité que les systèmes avancés d’aide à la conduite doivent gérer ne peuvent pas être reproduits de manière fiable sur une piste ou dans une flotte.
La conformité est également une considération importante. Les mises à jour OTA (Over-the-Air) permettent aux constructeurs de livrer de nouveaux logiciels de véhicules à une cadence beaucoup plus rapide qu’une version traditionnelle de l’année modèle. Mais la preuve que chaque mise à jour répond à des normes telles que la norme ISO 26262, la norme de sécurité fonctionnelle de l’industrie pour les véhicules routiers, n’est généralement rassemblée qu’à une date de publication programmée. Cela signifie que si les mises à jour sont accélérées, ces preuves doivent être reconstruites à partir de zéro plus souvent.
Trois fonctionnalités constituent une pile de validation virtuelle, construite les unes sur les autres plutôt que côte à côte. Les unités de contrôle électroniques virtuelles (vECU) viennent en premier : des répliques logicielles des unités de contrôle des véhicules qui permettent aux équipes de tester le code d’intention de production avant même que le matériel physique n’existe. C’est cette fondation qui rend les deux prochaines possibles. La simulation de scénarios à l’échelle du cloud atteint les conditions de longue traîne et les conditions critiques pour la sécurité que les tests physiques n’atteindront jamais. La traçabilité continue maintient les preuves de conformité à jour au fur et à mesure que le travail se déroule, au lieu d’être reconstruite au moment de la sortie.
Décaler la découverte des défauts avec les calculateurs virtuels
Un vECU exécute du code d’intention de production sans que le matériel ait encore besoin d’exister. Les vECU remplacent également un dispositif physique au stade de la conceptualisation du produit, avant le début des tests. L’insertion de vECU dans des pipelines de tests automatisés permet de tester le logiciel dans la boucle (SIL) dès les premières étapes de développement, de sorte que les défauts qui apparaissaient auparavant tard dans les tests HIL apparaissent au moment de la construction.
Les vECU se connectent à AUTOSAR, l’architecture logicielle standard sur laquelle la plupart des équipementiers automobiles sont déjà construits, de sorte que les composants virtuels et physiques se mélangent en un seul processus continu au lieu de fonctionner en phases distinctes. Les équipes construisent des vECU à différents niveaux de détail, depuis des simulations simplifiées jusqu’à des modèles qui se comportent comme le matériel réel. Dans le travail d’Infosys SDV, la virtualisation a réduit les exigences matérielles de 70 pour cent.
Couvrir les scénarios que les tests physiques ne peuvent pas atteindre
Une flotte de test couvre une tranche étroite des conditions du monde réel uniquement sur le plan logistique et économique. Un étude récente a découvert que la distribution d’une campagne de tests de conduite automatisée de 200 scénarios sur un cluster de Kubernetes – un système permettant d’exécuter de nombreuses tâches informatiques en parallèle sur un pool de machines – réduisait le temps d’exécution de 475 minutes à moins d’une heure, soit une accélération plus de huit fois supérieure à une exécution séquentielle. Les campagnes orchestrées dans le cloud à cette échelle peuvent atteindre les cas extrêmes à basse fréquence et critiques pour la sécurité, l’éblouissement des capteurs, les modèles d’occlusion et le comportement de trafic rare, requis par l’analyse de la sécurité des fonctionnalités prévues (SOTIF). SOTIF est la norme qui traite des risques pour la sécurité liés à un véhicule se comportant exactement comme prévu dans des conditions imprévues.
Des bibliothèques de scénarios structurés qui combinent des tests dérivés des exigences avec des conditions synthétiques à longue traîne génèrent les mesures de couverture et les arguments de risque résiduel sur lesquels l’analyse SOTIF est basée.
Rendre les preuves de conformité continues
La norme ISO 26262 exige déjà la traçabilité, qui relie les exigences, les décisions de conception, les modifications de code et les résultats des tests en une seule chaîne continue. La SOTIF considère la même discipline comme essentielle, même lorsqu’elle reste en deçà d’un mandat formel. Le Règlement ONU 156 impose un système de gestion des mises à jour logicielles avec traçabilité et auditabilité. La validation virtuelle change la cadence. Au lieu que la chaîne de preuves soit reconstruite aux étapes de publication programmées, le système reste à jour presque en temps réel, à mesure que chaque changement se produit.
Un changement tardif n’oblige plus les équipes à régénérer les livrables de validation pour les tests SIL, HIL et au niveau du véhicule à partir de zéro, car les preuves seront toujours à jour. Une telle capacité est particulièrement importante lorsque les programmes peuvent le moins se permettre de retarder, comme dans les enquêtes de rappel de sécurité, les audits réglementaires ou les annulations d’OTA, qui doivent montrer exactement ce qui a changé et pourquoi.
La validation virtuelle rééquilibre l’ensemble de la pile de tests. La couverture, la découverte des défauts et la génération de preuves évoluent vers un environnement évolutif axé avant tout sur le logiciel. La validation physique effectue la confirmation matérielle importante. Aujourd’hui, un tel rééquilibrage est une exigence structurelle pour que les programmes SDV rivalisent sur la cadence de sortie.