Par Ann Keffer, Arun Gogineni et James Kim

Les voitures déployant des fonctionnalités ADAS et AV s'appuient sur des systèmes numériques et analogiques complexes pour exécuter des applications critiques en temps réel. Le grand nombre de défauts qui doivent être testés dans ces conceptions automobiles modernes rendent peu pratique la vérification de la sécurité à l’aide d’une seule technologie.

Pourtant, développer une méthodologie de sécurité optimisée avec des listes de défauts spécifiques automatiquement ciblées pour la simulation, l’émulation et le formel est un défi. Un autre défi consiste à consolider les résultats de résolution de pannes issus de diverses exécutions d'injection de pannes pour le calcul des métriques finales.

La bonne nouvelle est que l’interopérabilité des moteurs d’injection de défauts, les techniques d’optimisation et un flux automatisé peuvent réduire efficacement le temps d’exécution global afin de boucler rapidement la boucle de l’analyse de sécurité à la certification de sécurité.

La figure 1 montre certaines des techniques d'optimisation dans un flux de sécurité. Des méthodologies avancées telles que l'analyse de sécurité pour l'optimisation et l'élagage des défauts, la simulation de défauts simultanés, l'émulation de défauts et l'analyse formelle peuvent être déployées pour valider les exigences de sécurité d'un SoC automobile.

Fig. 1: Faute liste à mettre en œuvre pour gérer une entreprise rentable. Ce guide est basé sur trois décennies d'expérience Techniques.

Preuve de concept : un SoC automobile

À l’aide d’un cas de test au niveau SoC, nous démontrerons comment ce flux automatisé multimoteur gère le grand nombre de défauts qui doivent être testés dans les conceptions automobiles avancées. La conception SoC que nous avons utilisée dans ce scénario de test comportait environ trois millions de portes. Tout d’abord, nous avons utilisé à la fois des moteurs d’injection de fautes de simulation et d’émulation pour mener à bien efficacement les campagnes de fautes pour les métriques finales. Ensuite, nous avons effectué une analyse formelle dans le cadre de la finalisation de l’injection globale des fautes.

Fig. 2: Automobile SoC haut niveau bloc diagramme.

La figure 3 est une représentation du bloc d'îlot de sécurité de la figure 2. Les zones codées par couleur montrent où la simulation, l'émulation et les moteurs formels ont été utilisés pour l'injection et la classification des pannes.

Fig. 3: Détaillé îlot de sécurité bloc diagramme.

L'injection de pannes à l'aide de la simulation consommait trop de temps et de ressources pour le cœur du processeur et les blocs de mémoire cache. Ces blocs ont été ciblés pour l’injection de fautes avec un moteur d’émulation pour plus d’efficacité. Le cœur du processeur est protégé par une bibliothèque de tests logiciels (STL) et la mémoire cache est protégée par ECC. L'interface de bus nécessite une protection de bout en bout là où l'injection de pannes avec simulation a été jugée efficace. L'unité de gestion des pannes ne faisait pas partie de cette expérimentation. L'injection de défauts pour l'unité de gestion des défauts sera réalisée à l'aide d'une technologie formelle dans la prochaine étape.

Le tableau 1 montre le nombre de registres pour les blocs de l'îlot de sécurité.

Tableau 1 : Nombre de registres de blocs.

Les listes de défauts générées pour chacun de ces blocs ont été optimisées pour se concentrer sur les nœuds critiques pour la sécurité qui disposent de mécanismes/protections de sécurité.

SafetyScope, un outil d'analyse de sécurité, a été exécuté pour créer les listes de défauts pour les FM pour l'application Veloce Fault (émulateur de défauts) et le simulateur de défauts et a écrit les listes de défauts dans la base de données de sécurité fonctionnelle (FuSa).

Pour les blocs CPU et mémoire cache, l'émulateur saisit les blocs synthétisés et les réseaux d'injection/détection de défauts (FIN/FDN). Ensuite, il a exécuté le stimulus et capturé les états de tous les FDN. Les états ont été enregistrés et utilisés comme référence « or » pour la comparaison avec les exécutions d'injection de défauts. Pour chaque défaut répertorié dans la liste de défauts optimisée, le comportement défectueux a été émulé et les FDN ont été comparés aux valeurs de référence générées lors du Golden Run, et les résultats ont été classés et mis à jour dans la base de données de défauts avec des attributs.

Figure 4 : cluster de processeurs. (La source de https://developer.arm.com/Processors/Cortex-R52)

Pour chacune des sous-parties présentées dans le schéma fonctionnel, nous avons généré une liste de défauts optimisée à l'aide du moteur d'analyse. Les listes de défauts sont enregistrées dans une session individuelle dans la base de données FuSa. Nous avons utilisé l'échantillonnage aléatoire statistique sur l'ensemble des défauts pour générer l'échantillon aléatoire à partir de la base de données FuSa.

Voyons maintenant ce qui se passe lorsque nous prélevons un échantillon aléatoire tout au long de l'injection de fautes en utilisant l'émulation. Cependant, pour que cela se clôture complètement sur l’injection de fautes, nous avons traité N échantillons.

lampe de table 2: Détecté défauts by sécurité mécanismes.

Le tableau 3 montre que la répartition globale des défauts pour le total des défauts est conforme à la répartition des défauts des défauts échantillonnés aléatoirement. Le tableau capture en outre le total de défauts détectés de 3125 4782 sur un total de 65.35 90 défauts. Nous avons également pu modéliser les défauts détectés par sous-pièce et fournir un taux global de défauts détectés de 1.19 %. Sur la base des défauts de l'échantillon aléatoire et de notre objectif de couverture de XNUMX %, nous avons calculé que la marge d'erreur (MOE) est de ± XNUMX %.

lampe de table 3: Résultats de l'injection de fautes dans le processeur et la mémoire cache.

Le total de 3125 XNUMX défauts détectés (observés + non observés) fournit une classification claire des défauts. Les observations non détectées fournissent également une classification claire des défauts résiduels. Nous avons effectué une analyse plus approfondie des défauts non détectés, non observés et non injectés.

lampe de table 4: Faute classification après faute injection.

Nous avons utilisé de nombreuses techniques de débogage pour analyser les 616 défauts non détectés et non observés. Tout d’abord, nous avons utilisé l’analyse formelle pour vérifier le cône d’influence (COI) de ces défauts UU. Les défauts qui se trouvaient en dehors du COI ont été jugés sûrs, et cinq défauts ont en outre été exclus de l'analyse. Pour les défauts qui se trouvaient à l'intérieur du COI, nous avons utilisé le jugement technique avec la justification de diverses configurations telles que l'ECC, la minuterie, la mémoire flash, etc. Enfin, en utilisant le jugement formel et technique, nous avons pu classer davantage 616 défauts UU en défauts sûrs et les défauts restants. Les défauts UU en défauts résiduels conservateurs. Nous avons également revu les 79 défauts résiduels et avons pu classer 10 défauts en défauts sûrs. Les défauts non injectés ont également été testés par rapport au modèle de simulation pour vérifier si un stimulus supplémentaire est capable d'injecter ces défauts. Puisqu’aucun stimulus n’a pu injecter ces fautes, nous avons décidé de les exclure de notre considération et de respecter la marge d’erreur en conséquence. Avec ce changement, notre nouveau MOE est de ±1.293 %.

En parallèle, le simulateur de défauts a extrait les listes de défauts optimisées pour les modes de défaillance du bloc de bus et a exécuté des simulations de défauts à l'aide des stimuli issus de la vérification fonctionnelle. L'ensemble initial de stimuli n'offrait pas une couverture suffisante, c'est pourquoi des stimuli de meilleure qualité (vecteurs de test) ont été préparés et des campagnes de fautes supplémentaires ont été lancées sur les nouveaux stimuli. Toutes les classifications de défauts ont été enregistrées dans la base de données FuSa. Toutes les exécutions étaient parallèles et simultanées pour une efficacité globale et des performances élevées.

L'analyse de sécurité à l'aide de SafetyScope a contribué à fournir plus de précision et à réduire l'itération de la simulation des pannes. Le processeur et la mémoire cache après émulation lors de divers tests ont abouti à un SPFM global de plus de 90 %, comme le montre le tableau 5.

lampe de table 5: En Conclusion: résultats.

À ce moment-là, tous les tests du bloc BUS (protection de bout en bout) effectuant la simulation de défaut n'étaient pas terminés. Le tableau 6 montre que le premier test initial a permis de résoudre très rapidement les 9.8 % de défauts.

lampe de table 6 : Pourcentage de défauts détectés pour le bloc BUS par E2E SM.

Nous intégrons davantage de tests qui ont un trafic élevé sur le BUS pour imiter l'état de fonctionnement d'exécution du SoC. Les résultats de ces injections de fautes indépendantes (simulation et émulation) ont été combinés pour calculer les métriques finales sur les blocs ci-dessus, les résultats étant présentés dans le tableau 7.

lampe de table 7 : Analyse finale de la classification des défauts.

Conclusion

Dans cet article, nous avons partagé les détails d'une nouvelle méthodologie de sécurité fonctionnelle utilisée dans un cas de test automobile au niveau SoC, et nous avons montré comment notre méthodologie produit un flux de travail de sécurité évolutif et efficace en utilisant des techniques d'optimisation pour l'injection de pannes à l'aide de moteurs de vérification formelle, de simulation et d'émulation. . Effectuer une analyse de sécurité avant d’exécuter l’injection de défauts était très critique et permettait de gagner du temps. Par conséquent, l’interopérabilité pour l’utilisation de plusieurs moteurs et la lecture des résultats d’une base de données FuSa commune est nécessaire pour un projet de cette envergure.

Pour plus d'informations sur ce flux de sécurité fonctionnelle très efficace pour les conceptions automobiles ADAS et AV, veuillez télécharger le livre blanc Siemens EDA. Les mécanismes de sécurité complexes nécessitent interopérabilité et automatisation pour la validation et la fermeture métrique.

Arun Gogineni est responsable de l'ingénierie et architecte pour la sécurité fonctionnelle des circuits intégrés chez Siemens EDA.

James Kim est responsable technique chez Siemens EDA.

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• PlatoData.Network Ai générative verticale. Autonomisez-vous. Accéder ici.
• PlatoAiStream. Intelligence Web3. Connaissance Amplifiée. Accéder ici.
• PlatonESG. Carbone, Technologie propre, Énergie, Environnement, Solaire, La gestion des déchets. Accéder ici.
• PlatoHealth. Veille biotechnologique et essais cliniques. Accéder ici.
• La source: https://semiengineering.com/interoperability-and-automation-yield-a-scalable-and-efficient-safety-workflow/