La complexité croissante des plateformes automobiles

Les véhicules modernes sont passés de systèmes mécaniques contrôlés par des microcontrôleurs simples à des plates-formes informatiques distribuées fonctionnant sur des dizaines d'unités de commande électroniques (ECUs).Les véhicules haut de gamme contiennent maintenant plus de 100 millions de lignes de code couvrant plusieurs systèmes d'exploitation, piles de mi-milieu et couches d'application.Ce logiciel fonctionne sur du matériel hétérogène – des microcontrôleurs à faible coût gérant des ascenseurs de fenêtre aux systèmes à puces haute performance (SoCs) exécutant la détection d'objets en temps réel pour la conduite autonome.La vérification de ces systèmes nécessite des méthodes qui peuvent faire face à des espaces d'état exponentiels, l'exécution simultanée sur des nœuds distribués et des exigences de sécurité strictes qui ne laissent pas de place à des cas de bord non manipulés.

Domaines de traitement des substances hétérogéniques

Une architecture de véhicule unique peut intégrer des microcontrôleurs (MCU) fonctionnant avec AUTOSAR Classic, des SoC haute performance avec des GPU embarqués pour l'inférence AI, et des tableaux de portages programmables sur le terrain (FPGA) pour le traitement des signaux à faible latence. Chaque élément de traitement fonctionne sous différents modèles de mémoire, domaines d'horloge et comportements de faille. La vérification de l'intégrité des données à travers les connexions de cache-cohérents, en veillant à ce que les transferts directs d'accès à la mémoire (DMA) ne corrompent pas les tampons critiques pour la sécurité et en prouvant que la communication interprocesseur respecte les délais de temps, tout cela nécessite des techniques de vérification spécialisées.

Piles logicielles multi-layered

Au-delà de cela, les intergiciels tels que AUTOSAR Adaptive ou Data Distribution Service (DDS) fournissent une communication orientée vers le service sur les réseaux IP. Fonctions d'application – allant du contrôle électronique de la stabilité à la tenue automatisée des voies – sont exécutées comme tâches réparties. La vérification doit confirmer que l'hyperviseur partitionne correctement la mémoire et le temps CPU, que la pile intergiciel n'introduise pas de latences non limitées et que les tâches d'application respectent leurs délais dans toutes les conditions de charge spécifiées. Le défi est que les bogues émergent souvent aux limites entre ces couches. Un protocole d'héritage prioritaire mal configuré dans le système d'exploitation peut faire bloquer une tâche de freinage critique en matière de sécurité par un processus d'infodivertissement peu prioritaire.

Concurrence et fonctionnalité distribuée

Une seule manœuvre, telle qu'un changement de voie autonome, nécessite la coordination entre les capteurs de perception, une unité centrale de planification, des actionneurs de direction de puissance et le contrôleur électronique de stabilité.Ces composants communiquent sur des systèmes de bus hétérogènes, notamment CAN FD, FlexRay et l'Ethernet automobile avec le réseau sensible au temps (TSN). Chaque réseau a différents latences, mécanismes de tolérance aux défauts et propriétés de synchronisation. La vérification qu'une demande de changement de voie se propage dans toute la chaîne dans une fenêtre de temps déterministe, même en cas de congestion du réseau ou de défaillance du nœud, exige une analyse rigoureuse du moment de fin de série.

Les normes de sécurité fonctionnelle et de cybersécurité constituent l'épine dorsale de la vérification intégrée des véhicules automobiles.Des normes telles que ISO 26262 pour la sécurité fonctionnelle et ISO 21434 pour la cybersécurité définissent des cycles de vie complets de développement qui exigent des activités rigoureuses d'analyse, de conception et de vérification.

Profondeur de la vérification ASIL D

Les systèmes auxquels le niveau d'intégrité de sécurité automobile (ASIL D) est le plus élevé, comme les systèmes de freinage par fil ou de freinage par fil, doivent être vérifiés de la manière la plus rigoureuse.Les ingénieurs doivent démontrer que les valeurs de défaut à un seul point et les valeurs de défaut latent dépassent les seuils définis (p. ex., la couverture par filage ou par filage pour les défauts à un seul point). La difficulté consiste à maintenir une couverture de défaut acceptable sans dénombrement exhaustif des défauts, ce qui est calculable et inextricable pour les SoC complexes. Les techniques comme l'injection statistique de défauts et l'analyse de propagation des défauts sont utilisées pour estimer la couverture, mais elles nécessitent une validation attentive. Les cadres d'injection automatisés de défauts qui s'intègrent aux bancs d'essai HIL permettent des campagnes répétables et évolutives, bien qu'elles exigent encore une expertise pour définir des modèles de défaut significatifs et interpréter les résultats.

Construire une valise de sécurité cohérente

Au-delà des essais, la norme ISO 26262 exige la création d'un dossier de sécurité, argument structuré selon lequel le système est acceptablement sûr. Cet argument doit être étayé par des preuves, y compris des analyses de risques, des spécifications du système, des documents de conception et des rapports de vérification. La traçabilité doit être maintenue de toutes les exigences de sécurité jusqu'à un résultat d'essai correspondant. En pratique, le maintien de cette traçabilité dans des centaines de milliers d'objets est un défi majeur.Les changements d'un élément peuvent invalider les arguments de sécurité ailleurs, exigeant une analyse continue des impacts et une vérification de régression.

S'attaquer à la sécurité de la fonctionnalité prévue (SOTIF)

La norme ISO 21448, également connue sous le nom de Sécurité de la Fonctionnalité prévue (SOTIF), étend la vérification au-delà des défauts matériels pour corriger les limitations de la fonctionnalité elle-même. Cela est particulièrement pertinent pour les systèmes qui se basent sur l'apprentissage machine ou le traitement complexe des capteurs. Par exemple, un système de détection des piétons peut ne pas détecter une personne portant des vêtements inhabituels, non pas à cause d'une défaillance matérielle, mais parce que les données de formation ne couvrent pas ce scénario. La vérification de la SOTIF exige l'identification des conditions de déclenchement – cas de référence où le comportement du système est dangereux en raison de limitations de performance.

Intégration et co-vérification des logiciels et matériels

L'interface entre le matériel et le logiciel est une source persistante de bogues subtils et catastrophiques. Un firmware enregistre une erreur de configuration, une tension transitoire non manipulée corrompant une lecture de capteur, ou un événement de throttling thermique qui déplace le calendrier d'exécution peut tous conduire à des défaillances qui restent cachées jusqu'à ce que le système fonctionne sur le terrain.

La chaîne de vérification MIL, SIL et HIL

Les tests de type « Model-in-the-Loop » (MIL) permettent de tester la régression à haut débit. Les tests de type « Hardware-in-the-Loop » (HIL) relient le vrai ECU à une simulation du véhicule et de son environnement, permettant ainsi une exécution en temps réel avec des capacités d'injection de défauts. Chaque étape révèle différentes classes de problèmes. MIL peut exposer des erreurs logiques dans les lois de contrôle, SIL peut découvrir des bogues d'implémentation logicielle, et HIL valide que le logiciel fonctionne correctement sur le matériel cible dans des conditions de temps et d'électricité réalistes.

Plateformes virtuelles pour une intégration précoce

Pour déplacer la vérification plus tôt dans le cycle de développement, les OEM et les fournisseurs adoptent de plus en plus de plateformes virtuelles.Ce sont des modèles logiciels de la carte matérielle complète qui peuvent exécuter le code compilé par cible avant que le silicium physique ne soit disponible.Les plateformes virtuelles permettent de rejouer de façon déterministe des interactions complexes et de soutenir des essais automatisés à grande échelle.Le défi consiste à obtenir une fidélité suffisante dans le modèle – des modèles de chronométrage imprécis des contrôleurs de mémoire, des caches ou des arbiters de bus peuvent masquer des problèmes réels.Les ingénieurs doivent continuellement calibrer les modèles de plate-forme virtuelle contre les mesures matérielles physiques afin de s'assurer que les résultats de la vérification sont dignes de confiance.L'émergence d'interfaces de plate-forme virtuelle standard, telles que celles basées sur SystemC TLM-2.0, améliore l'interopérabilité et la précision des modèles.

Vérification de l'intégrité de l'interface et du signal

Les interfaces hardware-software sont définies par des registres macnés par mémoire, des lignes d'interruption et des régions de mémoire partagée. Les structures de données mal alignées, les conditions de course sur les tampons partagés et la synchronisation incorrecte ne se font souvent que sur des surfaces spécifiques d'événements matériels et logiciels. Les outils d'analyse statiques qui font appliquer les contrats d'interface, comme s'assurer que le logiciel respecte le minimum et le maximum de temps pour les accès aux registres, sont essentiels. De plus, la vérification de l'intégrité du signal au niveau du matériel, y compris l'analyse des intersections, du bruit d'alimentation et des interférences électromagnétiques, doit être coordonnée avec l'analyse du calendrier du logiciel pour s'assurer que les conditions électriques marginales ne causent pas de corruption de données que le logiciel ne peut détecter ou gérer. ]Les environnements à double signe qui combinent la simulation de circuits analogiques avec la logique numérique et les logiciels intégrés deviennent nécessaires pour les interfaces critiques comme les lectures de capteurs et les pilotes actionneurs.

Assurer un comportement déterministe en temps réel

Les fonctions critiques en matière de sécurité imposent des exigences de temps strictes, souvent mesurées en microsecondes. La date limite manquée pour une commande d'intervention de frein est une violation de la sécurité. La vérification que le système respecte toutes les contraintes de temps dans les pires conditions est l'un des aspects les plus difficiles de la vérification embarquée automobile.

Délai d'exécution des pires cas (WET)

Les processeurs modernes avec pipelines profonds, prédictions de branche et caches partagés rendent extrêmement difficile l'exécution de la norme. L'analyse de la durée basée sur la mesure dépend de la qualité des vecteurs d'essai utilisés; des cas pathologiques peuvent être omis. Les outils d'analyse statiques WCET tirent des limites en analysant le code binaire par rapport à un modèle microarchitectural, mais ils produisent souvent des estimations prudentes qui peuvent être plusieurs fois supérieures aux délais d'exécution habituels. Les ingénieurs doivent équilibrer la nécessité de limites sûres par rapport à la nécessité de concevoir un système réalisable. Si l'estimation WCET est trop élevée, le système peut être surprovisé, augmentant les coûts. Si elle est trop faible, le système peut manquer de délais sur le terrain.

Vérification du temps et de la partitionnement de l'espace

La vérification de la partition consiste à démontrer que les ressources partagées (mémoire, temps CPU, cache et bande passante du bus) sont correctement réparties et appliquées. Les techniques comprennent l'audit de la configuration de l'unité de protection de la mémoire (UMP) ou de l'unité de gestion de la mémoire (UMM), l'essai sous la pire charge avec des tâches interférantes, et la vérification que le système d'exploitation impose des budgets pour l'attribution du temps et de la mémoire du CPU. Des méthodes formelles peuvent être utilisées pour prouver que les mécanismes de partition sont correctement mis en œuvre, mais cela nécessite des modèles officiels de la pile matérielle et logicielle, qui sont complexes à construire et à entretenir. Les solutions de surveillance des temps qui vérifient les invariants de partition pendant l'exploitation fournissent une couche d'assurance supplémentaire, en particulier pour les systèmes de criticité mixte.

Vérification officielle du calendrier

Des méthodes formelles telles que les automates chronométrés et la vérification des modèles sont de plus en plus appliquées à la vérification en temps réel. Des outils comme UPPAAL permettent aux ingénieurs de modéliser les schémas d'activation des tâches, le partage des ressources et les latences de communication. Le modèle peut ensuite être vérifié de façon exhaustive pour vérifier que les propriétés des délais sont respectées pour tous les chemins d'exécution possibles. Le principal défi consiste à construire des modèles fidèles du comportement du système qui ne simplifient pas les détails importants.

Vérification de la cybersécurité pour les véhicules connectés

L'intégration de la communication véhicule-tout (V2X), des mises à jour en direct (OTA) et des services basés sur le cloud a considérablement élargi la surface d'attaque des véhicules modernes. La vérification de la cybersécurité est désormais une activité obligatoire guidée par des normes telles que ISO 21434 et la réglementation R155.

Modélisation des menaces et évaluation des risques

La vérification commence par une analyse systématique des menaces et une évaluation des risques (TARA), qui identifie les actifs, les acteurs de la menace et les vecteurs d'attaque, ce qui permet de définir les exigences de sécurité.Les exigences communes comprennent une mise à jour sécurisée des boot, un firmware sécurisé avec protection en cas de renversement, une surveillance de l'intégrité des runtimes et des canaux de communication sécurisés. La vérification doit alors confirmer que ces exigences sont correctement mises en œuvre. La vérification doit non seulement comprendre des tests fonctionnels des mécanismes de sécurité, mais aussi des tests contradictoires tels que des tests de pénétration, des embrunements d'interfaces de protocole et une analyse des canaux latéraux.

Module de sécurité du matériel Co-vérification

La covérification doit garantir que les clés ne sont jamais exposées en dehors de la limite HSM, que les opérations cryptographiques sont effectuées correctement et que le HSM réagit de façon appropriée aux attaques d'injection de failles. Cela nécessite une coordination étroite entre la vérification matérielle (assurer que le HSM est correctement conçu) et la vérification logicielle (assurer que les conducteurs et le code d'application utilisent correctement le HSM). Les techniques comprennent la vérification formelle des implémentations de protocole cryptographique, l'injection de failles sur l'interface HSM et les tests pour les canaux latéraux de synchronisation qui pourraient fuir le matériel clé. L'analyse des fuites sur le côté du canal utilisant des méthodes statistiques devient une partie standard de la vérification HSM, car les attaques physiques sur l'électronique automobile deviennent plus sophistiquées.

Validation de la sécurité du cycle de vie

Chaque mise à jour en direct doit être vérifiée pour s'assurer qu'elle n'introduise pas de nouvelles vulnérabilités et qu'elle ne brise pas les mécanismes de sûreté ou de sécurité existants.Le mécanisme de mise à jour lui-même doit être vérifié, y compris l'authentification, la vérification de l'intégrité et la protection contre les renversements.Des plans de surveillance et d'intervention en cas d'incidents doivent être en place en continu, et l'infrastructure de vérification doit soutenir des tests de régression rapide lorsqu'une vulnérabilité est découverte dans un composant tiers.Cela déplace le processus de développement vers DevSecOps, la sécurité étant intégrée à chaque étape du pipeline d'intégration et de déploiement continus. Les suites de tests de régression de sécurité automatisées qui fonctionnent sur les plateformes virtuelles et les bancs de test HIL permettent une validation rapide des mises à jour sans compromettre la sécurité.

Défis de vérification croisés

Outre les défis propres à un domaine particulier, plusieurs questions transversales touchent tous les aspects de la vérification intégrée de l'automobile, qui nécessitent des stratégies holistiques qui couvrent les disciplines de l'ingénierie et les limites organisationnelles.

Qualification et confiance en l'outil

Un bogue de compilateur, un outil d'analyse statique qui manque une violation, ou un harnais de test HIL qui interprète mal un signal peut tous conduire à des conclusions erronées sur la justesse du système. ISO 26262 exige que les outils soient classés par leur impact potentiel (niveau de confiance en outil) et que les outils classés TCL1 nécessitent une qualification pour des niveaux ASIL plus élevés. La qualification d'un compilateur ou d'un outil de vérification officiel est un effort majeur – il implique des suites de tests étendues, des arguments de validation et parfois une vérification redondante avec divers outils. Le méta-défi de la vérification des outils de vérification entraîne des ressources et met l'accent sur la nécessité de chaînes d'outils robustes et bien caractérisées. Les cadres de vérification open-source avec une validation communautaire sont émergents, mais ils nécessitent toujours une évaluation minutieuse pour être utilisés dans des développements critiques en matière de sécurité.

Interférence entre le système de criticité mixte

L'intégration de fonctions de différentes criticités sur le matériel partagé introduit le risque d'interférence.Une fonction non critique générant une bande passante de mémoire élevée peut faire passer à côté d'une tâche critique en matière de sécurité en raison de l'expulsion de caches ou de l'opposition de bus. La vérification doit démontrer, par une combinaison d'analyse et de tests, que l'interférence ne compromet pas les garanties de sécurité.Les techniques comprennent l'analyse d'interférence limitée, la coloration du cache pour la partition spatiale et les essais de charge des pires cas.

Vérification de l'IA et de l'apprentissage automatique

La vérification traditionnelle fondée sur les exigences ne s'applique pas bien aux modèles appris. Au contraire, les ingénieurs s'appuient sur des bases de données de scénarios massives, des tests guidés par la couverture et des mesures de robustesse. La vérification doit aborder des questions telles que les biais de l'ensemble des données, des exemples contradictoires et des performances dans des conditions hors distribution. SOTIF est à l'origine de la nécessité de valider statistiquement les performances de perception, mais la définition d'un niveau de performance suffisamment sûr pour une fonction autonome opérant dans un environnement ouvert est un problème de recherche continu.

Intégration de la chaîne d'approvisionnement et de l'héritage

Les essais d'intégration révèlent souvent des hypothèses erronées sur le calendrier, les formats de données ou la gestion des erreurs. L'utilisation des composants logiciels existants, bien qu'ayant un avantage économique, porte sur la sécurité.Les artefacts de vérification des composants plus anciens peuvent être incomplets ou périmés. Lorsqu'un ECU existant est intégré dans une nouvelle architecture, son interaction avec des systèmes modernes peut exposer des défauts qui étaient dorment auparavant. La vérification progressive, où seuls les changements sont revérifiés, exige une compréhension précise de l'impact du changement, qui est difficile à réaliser dans des systèmes intégrés complexes.Des approches numériques jumelées qui maintiennent des modèles vivants de comportement du système et de l'état de vérification dans toute la chaîne d'approvisionnement sont en cours d'étude afin d'améliorer la traçabilité et l'analyse des impacts.

Conclusion

La vérification des systèmes embarqués dans le domaine de l'automobile exige une approche disciplinée qui intègre diverses méthodologies techniques et procédurales.Les défis couvrent la complexité matérielle, la cohérence en temps réel, les règlements de sécurité et les nouvelles frontières de la fonctionnalité basée sur l'IA.Ces défis sont étroitement liés : une solution de sécurité peut modifier le comportement en temps réel, un changement matériel peut invalider un cas de sécurité et une mise à jour logicielle peut introduire de nouvelles conditions de déclenchement pour le SOTIF. Pour y remédier, il faut une stratégie de vérification globale qui combine une intégration virtuelle précoce, des méthodes analytiques rigoureuses, des essais dynamiques approfondis et une validation continue du cycle de vie.