Architecture logicielle de sécurité fonctionnelle des voitures intelligentes

01 Pensée sur l'architecture de sécurité E-GAS

La sécurité fonctionnelle automobile vise à contrôler le risque de dommages corporels causés par une défaillance des systèmes électroniques et électriques systèmes à un niveau raisonnable dans la plage. La figure suivante est un schéma courant de composition matérielle d'un système électronique et électrique. Les composants d'un système électronique et électrique, en plus du matériel visible sur la figure, incluent également des logiciels qui ne sont pas visibles sur la figure.

Figure 1 Systèmes matériels électroniques et électriques couramment utilisés# 🎜🎜 #

Les pannes des systèmes électroniques et électriques comprennent à la fois les pannes systémiques causées par des erreurs de conception logicielle et matérielle et les pannes causées par des pannes matérielles aléatoires. Selon l'architecture du système, divers mécanismes de sécurité doivent être conçus pour prévenir et détecter les pannes fonctionnelles, et pour éviter ou réduire les dommages lorsqu'une panne survient. Cela nécessite une architecture logicielle de sécurité fonctionnelle solide pour gérer et contrôler ces mécanismes de sécurité et réduire la difficulté globale de développement de la sécurité fonctionnelle.

Actuellement, E-GAS (Standardized E-Gas Monitoring Concept for Gasoline and Diesel Engine Control Units) est sans aucun doute la solution d'architecture logicielle de sécurité la plus utilisée. Bien qu'E-GAS ait été initialement proposé comme solution d'architecture de sécurité pour les systèmes de gestion des moteurs essence/diesel, après une simple adaptation, il peut également être utilisé dans les systèmes de carrosserie, les systèmes de transmission et les systèmes triélectriques à nouvelle énergie, etc., avec de très bonnes performances. Extensible et largement utilisé.

L'image ci-dessous est la conception de l'architecture logicielle à trois couches d'E-GAS De haut en bas, le logiciel est divisé en niveaux 1 à 3, avec un total de. trois couches. Level1 est la couche de mise en œuvre des fonctions (niveau de fonction), Level2 est le niveau de surveillance des fonctions et Level3 est le niveau de surveillance du contrôleur. Cette architecture forme un bon cadre de surveillance en couches et réalise efficacement la décomposition de la sécurité fonctionnelle. La stratégie de décomposition de la sécurité de QM (ASIL X) + ASIL X (ASIL X) est généralement adoptée, c'est-à-dire que le logiciel de mise en œuvre des fonctions (niveau 1) est développé selon. le niveau QM, les logiciels fonctionnels redondants ou les mesures de sécurité (niveau 2, niveau 3) sont développés selon le niveau d'exigence le plus élevé ASIL X (ASIL X), ce qui peut réduire efficacement le coût de développement de sécurité des logiciels fonctionnels.

Figure 2 Architecture de surveillance à trois couches E-GAS solution

Couche d'implémentation de fonction de niveau 1 # 🎜 🎜#

Level1 est la couche d'implémentation de fonction, qui complète l'implémentation de fonctions spécifiques. Par exemple, pour un contrôleur de moteur, cette couche convertit le couple demandé en couple de sortie du moteur.

Couche de surveillance fonctionnelle niveau 2#🎜 🎜#Level2 est la couche de surveillance des fonctions, utilisée pour vérifier si la fonction Level1 fonctionne normalement. Le cœur de Level2 est de concevoir une méthode permettant de déterminer si Level1 fonctionne normalement. Bien que la méthode permettant de déterminer si le niveau 1 fonctionne normalement soit souvent liée à la fonction surveillée, différentes fonctions surveillées ont des méthodes de jugement différentes, telles que : via la diversification et la redondance logicielles. Cependant, il existe également des méthodes de jugement ayant une application plus large, comme le contrôle de rationalité.

Figure 3 Contrôle de raisonnabilité

# 🎜 🎜#Comme le montre la figure ci-dessus, lorsque Level2 utilise la méthode de vérification de rationalité pour déterminer si la fonction Level1 fonctionne normalement, elle calcule d'abord la sortie raisonnablement autorisée de la quantité de contrôle en fonction sur le signal entré par la plage du capteur, puis calculez la sortie réelle renvoyée par l'actionneur, et enfin déterminez si la sortie réelle du niveau 1 est dans la plage raisonnable autorisée. Si elle dépasse la plage raisonnable, il sera déterminé que. Le niveau 1 est fonctionnellement anormal et une gestion des erreurs sera effectuée.

Couche de surveillance du contrôleur de niveau 3

# 🎜 🎜#Level3 est la couche de surveillance du contrôleur, qui se compose principalement de trois parties de fonctions.

Diagnostic matériel du système électronique et électrique : surveillez les pannes matérielles du système électronique et électrique, telles que : panne du cœur du processeur du contrôleur, panne de RAM, panne de ROM, etc.

Surveillance indépendante : après une panne liée au contrôleur, le contrôleur ne peut plus exécuter de manière fiable la logique liée à la sécurité. Afin de garantir la sécurité, un module de surveillance externe indépendant supplémentaire est nécessaire pour garantir que même après une panne grave du MCU. , Il est toujours possible d'entrer dans un état sûr. Ce module de surveillance indépendant supplémentaire est généralement une puce de gestion de l'alimentation avec chien de garde intégré.

Vérification du flux d'application : vérifiez si les programmes de surveillance de niveau 1 et de niveau 2 fonctionnent normalement. Cette fonction de surveillance est mise en œuvre par l'inspection du flux du programme contraignant et l'alimentation du chien de garde. Si les programmes de surveillance liés aux niveaux 1 et 2 ne s'exécutent pas dans l'ordre défini ou ne sont pas exécutés dans le délai spécifié, la vérification du déroulement du programme échoue et le chien ne peut pas être nourri normalement, entrant ainsi dans l'état de sécurité du système.

Figure 4 Schéma fonctionnel de niveau 3

02 Le développement d'une architecture logicielle de sécurité fonctionnelle étrangère

Quand il s'agit de sécurité fonctionnelle et d'architecture logicielle, nous pouvons partir de "logiciel "architecture conforme à la sécurité fonctionnelle" et "architecture logicielle de sécurité fonctionnelle" pour examiner la relation entre elles.

Le premier se concentre sur la conformité de notre processus de conception d'architecture logicielle avec la sécurité fonctionnelle du point de vue du développement logiciel, c'est-à-dire que notre processus de conception d'architecture logicielle doit répondre aux différentes exigences avancées par la norme ISO 26262, telles que : les méthodes de marquage , les principes de conception, les exigences des éléments de conception, les exigences d'analyse de sécurité, les exigences des mécanismes de détection d'erreurs, les mécanismes de gestion des erreurs et les méthodes de vérification de la conception, etc. Parmi eux, les méthodes principales d'analyse de sécurité au niveau de l'architecture logicielle sont les « AMDEC logicielles (mode de défaillance et effets). Analysis)" et "logiciel DFA" (Dependent Failure Analysis)".

Ce dernier se concentre sur la prise en charge de la sécurité fonctionnelle au niveau du système du point de vue des systèmes logiciels embarqués. Sur la base de l'idée de l'architecture de sécurité E-Gas, nous pensons que les « idées de surveillance en couches », les « mesures de sécurité » et le « cadre de diagnostic » sont au cœur de « l'architecture logicielle de sécurité fonctionnelle » et des « idées de surveillance en couches » et « les mesures de sécurité" sont ci-dessus. Comme indiqué dans l'article, le reste de cette section se concentre principalement sur le "cadre de diagnostic". Que la plate-forme de développement logiciel de base que nous utilisons soit AUTOSAR CP, AP ou non-AUTOSAR, les idées de conception de l'architecture logicielle de sécurité fonctionnelle sont similaires et sont expliquées ici sur la base d'AUTOSAR CP.

1) Exigences techniques du cadre de diagnostic de sécurité fonctionnelle

Figure 5 Temps de réponse aux pannes et intervalle de temps de tolérance aux pannes

Nous combinons FTTI (intervalle de temps de tolérance aux pannes, fourmi intervalle de temps) pour comprendre le processus de diagnostic des pannes. La période allant de l'apparition d'un défaut à l'apparition de dangers possibles est le temps FTTI. Au cours de cette période, il y a principalement des tests de diagnostic, des processus de réponse aux pannes et l'espoir d'entrer dans un état sûr avant que d'éventuels dangers ne surviennent (Figure 4.1-8). ). Le processus de test de diagnostic doit prendre en compte le déclenchement du test de diagnostic, la confirmation des défauts (anti-rebond), etc. Le processus de réponse aux défauts doit envisager d'entrer dans un mode de fonctionnement raisonnable (tel que Fail safe, Fail opération, fonctionnement d'urgence, etc.), le stockage des défauts, etc.

Pour résumer, la conception de base du « cadre de diagnostic » doit prendre en compte la couverture des tests de diagnostic et des processus de réponse aux pannes. Les principales exigences techniques du cadre de diagnostic de sécurité fonctionnelle sont :

• Gestion unifiée des défauts : gestion unifiée de l'état des défauts signalés par chaque couche de surveillance des défauts du cadre de surveillance multicouche E-GAS
• Exigences en matière de temps de réponse aux pannes : l'intervalle de temps de tolérance aux pannes (FTTI) doit être respecté à partir du défaut détection pour entrer dans un état sûr) exigences
• Exigences d'indépendance : il existe des problèmes de cause commune entre les mécanismes et les fonctions de sécurité sur puce, et une surveillance indépendante (surveillance hors puce MCU) doit être prise en charge
• Exigences diversifiées : L'architecture logicielle doit répondre à la généralisation et au support de la conception du framework. Stratégies de sécurité diversifiées (différents projets ont des exigences différentes en matière de mécanismes de sécurité)
• Calendrier des tests de diagnostic : mise sous et hors tension, cycle, déclenchement de condition, etc. Contrôle anti-rebond/retard de défaut : nécessité de prendre en charge les tests anti-rebond des mécanismes de sécurité Fonction, prendre au moins en charge les algorithmes anti-rebond basés sur le temps et le nombre
• Découplage des événements et des fonctions de diagnostic : les événements et les fonctions de diagnostic sont gérés indépendamment, et il y a une relation de cartographie entre eux
• Stockage des défauts : prend en charge le stockage non volatile des informations sur les défauts
2) Interprétation de la technologie du cadre de diagnostic étranger

Avant d'interpréter la technologie du cadre de diagnostic, il y a deux suggestions pour référence.

① Suggestion 1 : Déterminez le moment du test de diagnostic en fonction des besoins

a Lors de la mise sous tension : Voici une explication basée sur une exigence d'application typique. Le mécanisme de sécurité et les fonctions correspondantes forment un double point. Afin de réduire le taux de défaillance des défauts multipoints latents, le mécanisme de sécurité doit généralement effectuer une auto-vérification pendant la phase de démarrage du système (sous tension). De plus, les problèmes de synchronisation des tests de diagnostic doivent être pris en compte dans les systèmes multiprocesseurs.

b. Durée d'exécution : généralement divisée en tests de diagnostic périodiques et tests de diagnostic conditionnels. La définition du cycle de diagnostic doit prendre en compte les contraintes du FDTI (intervalle de temps de détection des défauts), et les tests de diagnostic conditionnel sont généralement des diagnostics d'une fonction lorsqu'une transition d'état se produit ou avant l'activation d'une fonction.

c. Lors de la mise hors tension : vous pouvez choisir d'effectuer des tests fastidieux, et les résultats des tests sont généralement traités au prochain démarrage.

② Recommandation 2 : Effectuer des tests de diagnostic groupés

Afin de faciliter la gestion des diagnostics (y compris le déclenchement du diagnostic et la réponse aux défauts, etc.), regroupez-les en fonction des défauts critiques/défauts non critiques, du timing des tests de diagnostic et d'autres facteurs. Si un défaut critique est détecté lors de la mise sous tension, tel qu'un défaut de base, un défaut de test de RAM, etc., la réponse au défaut peut alors être traitée dans un état silencieux (par exemple : le MCU est dans un état de réinitialisation continue).

Figure 6 « Cadre de diagnostic de sécurité fonctionnelle » et « Flux de contrôle du diagnostic de sécurité fonctionnelle »

Cadre de surveillance à trois couches E-Gas Niveau 1 (niveau de fonction) et Niveau 2 (niveau de surveillance des fonctions) ) est situé dans la couche ASW (logiciel d'application, c'est-à-dire : SWC dans la figure 4.1-9), et Level3 (niveau de surveillance du contrôleur) est situé dans la couche BSW (logiciel de base). Le « Cadre de diagnostic » est également situé au niveau de la couche BSW. Comme mentionné ci-dessus, il couvre principalement les processus de tests de diagnostic et de réponse aux pannes. Sa composition et son processus de travail sont présentés ci-dessous :

.

• BswM et EcuM sont principalement responsables de la gestion de la mise sous et hors tension et effectuent des tests de diagnostic sur la mise sous tension, le temps d'exécution et la mise hors tension respectivement dans les phases de DÉMARRAGE, DE MISE EN MARCHE et d'ARRÊT
• ASW-Level1 (E- Diagnostic d'entrée/sortie de la fonction de couverture Gas Level1) ; ASW-Level2 (E-Gas Level2) est généralement implémenté comme un algorithme redondant de la fonction ASW-Level1 pour réaliser la décomposition du niveau ASIL ASW-Level1 (E-GasLevel3) ; surveille les pannes matérielles au niveau de l'ECU et du MCU (il est recommandé de se référer à l'ISO26262 (2018) -Part5 Annexe D et au manuel de sécurité du MCU), couvrant le diagnostic des pannes de cause commune de niveau 1 et de niveau 2 et mettant en œuvre le mécanisme de surveillance des questions et réponses pour diagnostic indépendant de la logique et du temps avec le "contrôleur de surveillance"
• TestManager est chargé de déclencher les tests de diagnostic du mécanisme de sécurité TestLib et de collecter les résultats des tests correspondants
• DEM collecte les résultats des tests du niveau E-Gas 1/2/3. , anti-rebond des événements de diagnostic, marque les codes d'erreur et collecte les informations sur les erreurs via le stockage NvM. FiM marque les fonctions configurées en fonction des résultats du test de diagnostic DEM (après anti-rebond) et le logiciel de fonction (ASW-Level1) détermine la suppression des fonctions en fonction des marques.

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!