Maison > Article > Périphériques technologiques > Un article sur la conception de la sécurité fonctionnelle des contrôleurs de domaine de conduite autonome avancés
Le processus de conception du contrôleur de domaine central de conduite autonome avancée nécessite une compréhension complète des principes de conception de sécurité, car dès le début de la conception, qu'il s'agisse d'architecture, de logiciel, de matériel ou de communication, il est nécessaire de bien comprendre ses règles de conception dans afin de faire jouer pleinement les avantages correspondants, tout en évitant certains problèmes de conception.
La conception de la sécurité fonctionnelle des contrôleurs de domaine haut de gamme dont nous parlons ici fait principalement référence à l'analyse de scénarios impliquée dans la sécurité fonctionnelle attendue dans le développement front-end et à tous les sous-éléments impliqués dans la sécurité fonctionnelle back-end. Premièrement, le niveau matériel de base est utilisé comme point de base de connexion, et l'ensemble de la communication de l'architecture du système et la transmission du flux de données sont réalisés via l'extrémité de communication de données. Le logiciel est gravé dans le matériel, en utilisant le matériel comme support, et le logiciel est gravé dans le matériel. L'unité de communication est chargée d'appeler les modules entre eux. Donc pour le côté conception de sécurité du contrôleur de domaine. Du point de vue de l'analyse des capacités de sécurité des véhicules, le processus d'analyse principal comprend également les trois aspects suivants : analyse théorique du système STPA (analyse des processus théoriques des systèmes), analyse des modes de défaillance et de leurs effets FMEA et analyse de l'arbre de défaillances (FTA).
Pour le contrôleur de domaine au cœur de l'architecture, un niveau très fort de sécurité fonctionnelle est impliqué. Nous pouvons généralement la diviser en trois niveaux : la sécurité de la communication des données, la sécurité matérielle de base et la sécurité logicielle de base. Le processus d'analyse spécifique doit prendre pleinement en compte plusieurs aspects, notamment la sécurité fonctionnelle au niveau de base du matériel, la sécurité fonctionnelle au niveau du logiciel de base et les capacités de communication de données, et l'analyse de chaque aspect doit être complète.
À la fin de la connexion et des entrées et sorties de données, l'extrémité de communication joue un rôle décisif dans l'ensemble de la communication de l'architecture du système. Pour le niveau de communication de données, ses exigences de sécurité fonctionnelle se réfèrent principalement à des exigences générales. mécanisme d'intégrité des données, mécanisme de comptage en ligne (Rolling Counter), actualisation des données de diagnostic du système, informations d'horodatage (Time Stamp), dépassement de temps (CheckSum), code d'autorisation de gestion, redondance des données, passerelle et autres aspects majeurs. Parmi eux, pour la communication de données, telles que le comptage en ligne, le diagnostic, la vérification du dépassement de temps, etc. sont cohérents avec le signal Canbus point à point traditionnel, tandis que pour la prochaine génération de conduite autonome, la redondance des données, l'optimisation de la gestion centrale de la passerelle, et l'autorisation des données, l'accès, etc. sont des domaines sur lesquels il faut se concentrer.
Leurs exigences globales en matière de sécurité fonctionnelle sont les suivantes :
Les exigences de sécurité fonctionnelle au niveau de base du matériel se réfèrent principalement aux modules de microcontrôleur, aux modules de stockage, au support d'alimentation, aux ports série. Communication de données et autres modules majeurs.
Le microcontrôleur ici est ce que nous appelons souvent la puce AI (SOC), la puce d'opération à virgule flottante (GPU) et la puce d'opération logique (MCU) fonctionnant dans la voiture. le contrôleur de domaine final. Du point de vue de la conception de la sécurité fonctionnelle, divers types de modules de microcontrôleur comprennent des modules de conception générale, la vérification du noyau à étape de verrouillage (y compris la comparaison du noyau à étape de verrouillage, l'autotest du noyau à étape de verrouillage), la vérification de l'horloge (y compris la comparaison d'horloge, l'auto-test d'horloge). test), surveillance du flux de programme, surveillance du rythme cardiaque, fonction de surveillance du matériel, protection contre les interruptions, surveillance/auto-test de la mémoire/flash/registre, surveillance et auto-test de l'alimentation électrique, protection des communications, etc.
Il convient de noter que le microcontrôleur doit fournir le signal de commutation périodique « battement de cœur actif » à l'unité de surveillance via des fils durs. Les signaux de commutation doivent être gérés par un organisme de surveillance de sécurité qui fournit également des capacités de surveillance du flux du programme. Le chien de garde de sécurité est uniquement autorisé à activer/désactiver le « battement de cœur actif » pendant le service de surveillance. Le logiciel de sécurité du microcontrôleur doit alors activer le « battement de cœur actif » chaque fois que le chien de garde de sécurité interne est entretenu, ce qui indique à l'unité de surveillance que le microcontrôleur est en cours d'exécution et que le minuteur du chien de garde de sécurité est en cours d'exécution. L'arrière-plan du système doit surveiller le signal de commutation « battement de cœur actif » en vérifiant que les heures de commutation du signal et les états haut et bas se situent dans la plage valide. Une fois qu'une défaillance de « battement de cœur actif » est détectée, le SMU active le déclassement de sécurité.
Pour les programmes de surveillance, ils doivent être testés lors de l'initialisation du système pour éviter des pannes potentielles. Les types de défauts suivants doivent être testés au cours du processus :
- Temps de déclenchement du chien de garde incorrect (déclenché dans une fenêtre fermée) ;
- Aucun chien de garde déclenché
Stockage Le module est un partie intégrante de l'ensemble du contrôle du domaine. Pendant tout le processus de fonctionnement de la puce, il est principalement utilisé pour le stockage de fichiers temporaires et couramment utilisés, ainsi que pour l'échange de données pendant le processus de fonctionnement. Par exemple, notre programme de démarrage du système d'exploitation est stocké dans un SOC. /Dans l'unité de stockage branchée sur le MCU, par exemple, nos produits de conduite autonome de nouvelle génération doivent utiliser des cartes de conduite/stationnement de haute précision, qui sont généralement stockées dans l'unité de stockage branchée sur la puce, ainsi que certains diagnostics et journaux. dans le logiciel sous-jacent, les fichiers de classe sont également stockés dans notre puce plug-in. Alors, quelles conditions doivent être remplies pour l’ensemble de l’unité de stockage afin de garantir des conditions de sécurité fonctionnelle appropriées ? Voir la figure ci-dessous pour une explication détaillée.
La sécurité de l'ensemble de l'unité de stockage comprend principalement la surveillance des registres, l'unité de stockage générale, la RAM/mémoire ECC, l'auto-test ECC, la redondance flash, la protection en écriture du registre, la protection de plage, l'auto-test du registre et d'autres aspects.
Le test de la méthode de sécurité d'intégrité de l'alimentation électrique s'effectue principalement sur l'ensemble de l'état de fonctionnement de l'alimentation électrique. Elle s’effectue par injection de fautes et surveillance en temps réel.
Un exemple de méthode de test consiste à configurer un seuil de surveillance supérieur ou inférieur pour forcer le moniteur à détecter un défaut de sous-tension ou de surtension et vérifier que le défaut est correctement détecté. Lorsqu'un défaut est injecté, le contrôleur de puissance doit activer le chemin d'arrêt auxiliaire. Le microcontrôleur doit surveiller le chemin d'arrêt auxiliaire et considérer le test comme une « réussite » uniquement si le chemin d'arrêt auxiliaire se comporte comme prévu dans la procédure de test, sinon il sera considéré comme un « échec ». Une fois une panne détectée, le microcontrôleur active la dégradation de la sécurité. Ce test est supporté par une fonction BIST dédiée et doit être configuré par le logiciel du microcontrôleur selon une procédure détaillée.
Les considérations de conception pour le niveau de sécurité logicielle de base sont principalement des considérations complètes sur les pannes logicielles qui peuvent survenir lors du développement d'un logiciel de conduite intelligente embarqué. Ceux-ci incluent la conception de documents logiciels, le langage et le style du logiciel, les variables critiques pour la sécurité, la détection et la correction des défauts, l'architecture logicielle, le code critique pour la sécurité, la surveillance du flux du programme, la gestion des modifications et d'autres aspects majeurs. Les descriptions de conception de logiciels à tous les niveaux doivent utiliser un langage naturel pour définir l'objectif du modèle ou du code. Par exemple, lorsque l'indépendance entre plusieurs variables est essentielle à la sécurité du système, ces variables ne doivent pas être combinées en un seul élément de données en utilisant l'adresse publique de la variable. Cela peut conduire à des défaillances systématiques de mode commun impliquant tous les éléments de la structure. Si les variables ont été regroupées, une justification appropriée doit être apportée pour les fonctions critiques pour la sécurité.
Cet article part du point de vue de la sécurité fonctionnelle et analyse en détail les éléments et processus complets de l'ensemble de la conception du contrôleur de domaine de conduite autonome sous différents aspects. Parmi eux, cela comprend divers aspects tels que la base matérielle, les méthodes logicielles, la communication de données, etc. Ces capacités de conception de sécurité fonctionnelle se concentrent sur l'ensemble du niveau de l'architecture tout en accordant également toute l'attention aux connexions entre ses composants internes pour garantir la conformité et l'intégrité du processus de conception et éviter des conséquences imprévisibles dans les étapes ultérieures de la conception. Par conséquent, en tant que règles détaillées de conception de sécurité, elles peuvent fournir la référence nécessaire aux ingénieurs de développement.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!