Surveillance et gestion à l’exécution pour la sécurité fonctionnelle des véhicules automobiles

Lee Harrison, responsable des solutions de test pour les CI automobiles, Tessent Group – Siemens EDA

La promesse des véhicules autonomes entraîne de profonds changements dans la conception et le test des composants semi-conducteurs automobiles. Les circuits intégrés (CI) automobiles sont de plus en plus développés et fabriqués selon des procédés de pointe. Ces composants ne sont plus seulement déployés pour des fonctions simples comme les commandes de lève-vitres ou la signalisation lumineuse. Ils sont désormais nécessaires pour des fonctions complexes liées aux systèmes avancés d’aide à la conduite (ADAS) et de plus en plus pour des applications de conduite autonome. La puissance de traitement requise pour ces fonctions avancées entraîne la nécessité de fabriquer des CI très grands et complexes pour une efficacité énergétique optimale. Si vous ajoutez à cette situation la nécessité de satisfaire aux exigences de sécurité strictes de la norme ISO 26262, vous obtenez une nouvelle série de défis pour les fabricants de composants et de systèmes automobiles. Des solutions doivent être trouvées pour garantir un fonctionnement sûr des nouveaux systèmes électroniques automobiles complexes en toutes circonstances pendant la durée de vie du véhicule. C’est ce qu’on appelle la sécurité fonctionnelle.

La sécurité fonctionnelle repose sur des mécanismes de sécurité appliqués durant le processus de conception, afin de pouvoir surveiller et vérifier le bon fonctionnement du composant pendant son utilisation. La capacité de ces mécanismes de sécurité à couvrir les défauts potentiels, qu’ils soient latents ou transitoires, déterminera la couverture diagnostique globale du composant et donc le niveau ASIL pouvant être atteint. Une approche extrêmement populaire consiste à utiliser un ensemble de fonctions de surveillance embarquées, réparties dans chaque composant semi-conducteur et reliées entre elles par une infrastructure de communication globale, qui permet de détecter et de signaler rapidement les pannes aléatoires n’importe où dans le système. Les dispositifs de surveillance doivent fonctionner sans interférer avec les opérations normales et offrir différents degrés de couverture des pannes en fonction de l’application finale du semi-conducteur et de la classification ASIL (Automotive Safety Integrity Level) associée. La figure 1 illustre un exemple d’architecture de test au niveau de la puce, qui permet de surveiller l’ensemble du système distribué.

Figure 1 : Architecture de test au niveau de la puce pour le test in-situ

Un TAP (Test Access Port) conforme IEEE 1149.1 fournit un portail vers toutes les ressources de test sur puce pour le test de fabrication. Ce TAP se connecte à un réseau d’accès série reconfigurable basé sur la norme IEEE 1687 (souvent appelée norme IJTAG). Ce réseau IJTAG est constitué de commutateurs SIB (Segment Insertion Bits). Comme chaque SIB permet d’activer ou de contourner un sous-réseau, l’accès à toutes les ressources de test au sein du réseau s’en trouve optimisé. Le réseau IJTAG est également accessible par un contrôleur IST (In-System Test). Dans ce cas, le contrôleur Tessent MissionMode communique via une interface CPU avec le monde extérieur ou un gestionnaire de sécurité interne et effectue la conversion des données parallèle à série et série à parallèle nécessaire pour transporter les informations entre le bus CPU et le réseau IJTAG interne. Ce contrôleur IST permet une architecture de communication au niveau du système, comme l’illustre la figure 2.

Figure 2 : Architecture de test au niveau du système

Un processeur de service peut accéder au contrôleur IST de chaque puce et donc à toute ressource de test sur puce par l’intermédiaire de n’importe quel bus de véhicule de fond de panier implémenté comme CAN (Controller Area Network) ou I²C (Inter Integrated Chip).

Pour les SoC avancés, le processeur du gestionnaire de sécurité peut être intégré au composant. Cette architecture est communément appelée « îlot de sécurité ». Si le gestionnaire de sécurité est placé sur un îlot de sécurité, il court moins de risques d’être affecté par des défauts sur la partie fonctionnelle du composant. Le terme « îlot » fait référence au fait qu’il est traité comme une partition physique et de puissance distincte sur le silicium, recevant souvent des signaux de puissance et de contrôle dédiés et physiquement isolé (autant que possible) de la logique fonctionnelle. Les liaisons avec le réseau de test constituent la seule connexion de données entre l’îlot de sécurité et l’autre logique fonctionnelle. La figure 3 montre les principaux éléments qui composent un îlot de sécurité type.

Figure 3 : Îlot de sécurité sur puce

L’efficacité de ce système distribué sur un seul ou plusieurs composants dépend des moyens de test mis en œuvre dans les divers composants. Pour obtenir la certification ISO 26262, ces ressources se composent généralement d’un mélange de mécanismes de sécurité fonctionnelle et structurelle.  MBIST (Memory Built-In Self-Test) représente probablement la forme la plus courante de ressource structurelle sur puce. Un moteur MBIST teste entièrement une mémoire embarquée en générant de manière algorithmique une séquence d’opérations de lecture et d’écriture qui couvrent l’ensemble de l’espace d’adressage.

Si un tel test de mémoire est exécuté pendant le fonctionnement du véhicule, la mémoire doit d’abord être mise hors ligne pour permettre au moteur BIST de prendre le contrôle. Il peut également s’avérer nécessaire de sauvegarder le contenu de la mémoire avant d’exécuter le test et de restaurer ce contenu par la suite, car le test détruira tout ce que le la mémoire contenait avant le test. Autre complication : mettre la mémoire hors ligne risque également de dégrader les performances du système, ce qui peut ne pas être acceptable dans certaines applications. Une technique MBIST non destructive a été développée pour éviter tous ces problèmes. Dans cette approche, le moteur MBIST teste la mémoire à l’aide d’une série de courtes séquences de transactions, souvent appelées « bursts » (rafales ou salves). Une rafale ne dure généralement qu’un petit nombre de cycles d’horloge (peut-être 20 à 30) et cible à chaque fois des emplacements de mémoire différents. L’ensemble de la mémoire est donc testé sur un grand nombre de courtes sessions MBIST. L’approche est non destructive, car les emplacements de mémoire qui sont modifiés par une rafale sont sauvegardés et restaurés à chaque rafale par le moteur MBIST. Les performances fonctionnelles ne sont pas affectées de manière significative, car les rafales ne sont déclenchées que lorsque la logique d’arbitrage mise en œuvre entre le moteur MBIST et la logique fonctionnelle détermine que la mémoire est libre.

Le BIST logique est une autre forme populaire de ressource de test structurel dans le système qui peut être accessible via le contrôleur IST. Cette solution de test implique la génération sur puce de vecteurs aléatoires appliqués aux chaînes de scan pour tester la partie logique d’une puce. Les réponses du circuit à tous les vecteurs aléatoires sont accumulées dans une signature, qui est examinée à la fin du test pour un résultat de réussite/échec. La couverture de test obtenue en appliquant un nombre croissant de vecteurs aléatoires croît de manière logarithmique, comme le montre la figure 4a.

Figure 4 : Gestion de la durée du test BIST logique

Cette approche ne permet souvent pas d’obtenir une couverture de test suffisamment élevée dans le temps et le budget impartis. Une solution à ce problème consiste à découper le test en plusieurs sessions, comme le montre la figure 4b. Chaque tranche successive est appliquée pendant une pause disponible dans l’opération fonctionnelle. Par exemple, dans un processeur d’images utilisé pour traiter des données visuelles, chaque session de test pourrait être appliquée entre le traitement des images individuelles. La gestion des multiples tranches de test nécessite une coordination minutieuse entre le contrôleur IST et le moteur BIST logique. Le contrôleur IST doit garder la trace de la tranche de test à appliquer ensuite, initialiser le moteur BIST logique pour qu’il génère le bon ensemble de vecteurs aléatoires, puis récupérer et comparer la signature intermédiaire pour déterminer l’état de réussite ou d’échec.

Dans les cas où cette forme de distribution n’est pas possible ou ne peut toujours pas fournir la couverture requise dans le FTTI (Fault Tolerant Time Interval), une nouvelle technologie réduit considérablement la durée du test de ces moniteurs BIST logiques, ce qui améliore considérablement leur temps de réponse global.

Le BIST logique avec technologie OST (Observation Scan Technology) utilise des points de test spéciaux insérés dans la conception, ainsi qu’une petite chaîne de scan de cellules d’observation dédiée. Il est ainsi en mesure de couvrir efficacement les défauts de la logique fonctionnelle, et ceci en capturant les résultats à chaque cycle de travail, plutôt qu’à la fin de chaque vecteur (voir figure 5).

Figure 5 : BIST logique avec OST

Il en résulte une rampe de couverture nettement plus rapide pour la logique fonctionnelle, permettant à ces mécanismes de sécurité d’atteindre leurs objectifs de qualité plus vite que ne le permet le BIST logique traditionnel. La figure 6 compare cette rampe de couverture LBIST-OST à celle du BIST logique traditionnel.

Figure 6 : Amélioration de la durée des tests avec LBIST-OST

Toutes ces technologies et méthodologies décrites ici permettent d’implémenter un nombre illimité de fonctions de sécurité au niveau du système. Les tests de démarrage et d’arrêt peuvent être facilement réalisés en envoyant des commandes à tous les contrôleurs IST pour que toutes les ressources de test effectuent des tests spécifiques, en fonction du scénario sélectionné. Les échecs de test peuvent être signalés au gestionnaire de sécurité, qui peut utiliser les résultats pour mettre en place une forme d’action corrective, allant de l’affichage d’un message d’avertissement sur le tableau de bord à l’arrêt du véhicule pour un entretien. Les contrôleurs IST peuvent également être chargés d’effectuer des tests périodiques pendant que le véhicule fonctionne sur les parties du système électronique qui sont impliquées dans les fonctions critiques de sécurité. Là encore, les résultats négatifs de ces tests peuvent être contrôlés par le gestionnaire de sécurité et la mesure appropriée peut être prise. Cela peut être aussi simple que de désactiver certaines fonctions ADAS ou aussi drastique que de mettre le véhicule dans un état opérationnel sûr. Le temps de réponse de ces mécanismes de sécurité est essentiel, car il permet de prendre rapidement des mesures correctives.

À mesure que la quantité et la complexité des fonctions critiques de sécurité continueront de croître, la surveillance régulière en ligne des systèmes électroniques automobiles s’avérera sans aucun doute de plus en plus nécessaire. Pour répondre à ce besoin, des solutions commerciales ont déjà été introduites et continueront très probablement à évoluer au fil du temps.

En tant que Directeur des solutions de test des CI automobiles au sein du groupe Tessent de Siemens EDA, Lee Harrison est responsable des solutions de test automobile de l’entreprise. Auparavant, il était directeur des services de conseil DFT chez Siemens EDA, où il dirigeait une équipe mondiale de consultants fournissant des solutions DFT et de test dans de nombreux domaines de produits différents. Il a également occupé des postes d’ingénieur principal chez 3COM et BAE Systems. Il a obtenu son BEng en microélectronique à l’Université Brunel de Londres.