Des objectifs de sécurité abstraits au code concret : Guide de conversion FSR vers TSR pour les ingénieurs BMS

Lors des audits ISO 26262, de nombreuses équipes du secteur automobile rencontrent un obstacle majeur : elles définissent des objectifs de sécurité (OS) de haut niveau et établissent l’intervalle de temps de tolérance aux pannes (ITTP). Pourtant, lors des évaluations de sécurité, leur documentation technique se révèle insuffisante.

Pourquoi cela se produit-il ? La défaillance réside dans la transition entre les exigences de sécurité fonctionnelle (FSR) et les exigences de sécurité technique (TSR).

Lorsque le lien entre les concepts fonctionnels de haut niveau et leur implémentation technique de bas niveau est ténu, les équipes rencontrent des difficultés. Les exigences restent vagues, les paramètres physiques sont manquants et des lacunes logiques apparaissent. Cela entraîne des tests infructueux, des refontes de dernière minute et des lancements de produits retardés.

Ce guide présente une méthode standard en quatre étapes pour traduire des objectifs de sécurité abstraits en spécifications techniques claires, testables et codables. Nous illustrerons son application concrète à un scénario de protection contre la surcharge des batteries ASIL-D en production.

FSR vs. TSR : La différence fondamentale

De nombreux ingénieurs utilisent ces termes indifféremment. Or, ils sont distincts et représentent différents niveaux de conception du système. L’un définit les limites ; l’autre, la mise en œuvre.

Exigences de sécurité fonctionnelle (ESF) : Ce que le système doit faire

Une exigence fonctionnelle (FSR) découle directement des objectifs de sécurité de haut niveau. Il s’agit d’une exigence fonctionnelle.

• Technologie neutre : Il ne précise ni les puces, ni les microcontrôleurs, ni les bus de communication.
• Axé sur le comportement : Il énonce les conditions de déclenchement, l’action système requise et l’état de sécurité.
• Limité dans le temps : Il est directement lié au réseau FTTI global.
• Exemple: En cas de surtension d’une cellule de batterie, le système doit déconnecter le circuit de charge au sein du FTTI afin d’éviter un emballement thermique.

Exigences techniques de sécurité (ETS) : Comment les mettre en œuvre

Un TSR traduit le FSR en termes d’ingénierie. Une fois l’architecture système choisie, on rédige des TSR pour spécifier les détails d’implémentation du matériel, du logiciel, des diagnostics et des communications.

• Spécificités technologiques : Il se lie directement à vos microcontrôleurs, interfaces analogiques (AFE) et protocoles.
• Hautement quantifié : Il définit les intervalles d’échantillonnage, la tolérance de mesure, les boucles d’exécution et les broches matérielles.
• Entièrement vérifiable : Chaque TSR doit être directement testable via des tests matériels en boucle (HIL), l’injection de défauts ou des tests unitaires logiciels.
• Exemple: L’AFE doit échantillonner la tension de cellule toutes les 10 ms avec une précision de ±5 mV, et le MCU doit déclencher le pilote côté haut pour ouvrir les contacteurs dans les 50 ms suivant la détection du défaut.

Le cadre de transformation en quatre étapes

Vous n’avez pas besoin de deviner pour rédiger les rapports techniques. Ce processus structuré vous garantit le respect des normes de conformité sans aucune lacune.

Étape 1 : Déconstruire le FSR

Avant de rédiger les exigences techniques, décomposez votre cahier des charges fonctionnel en quatre éléments principaux :

1. Condition de déclenchement : Le défaut ou le scénario spécifique qui active la fonction de sécurité.
2. Action principale : La réponse physique du système.
3. Contrainte de temps : La fenêtre temporelle maximale absolue autorisée pour la réponse, dérivée de la FTTI.
4. État sûr : L’état final et stable du système après correction du défaut (par exemple, verrouillage permanent ou auto-récupération).

Étape 2 : Cartographie de l’architecture

Examinez l’architecture matérielle et logicielle de votre système de gestion de batterie (BMS). Attribuez chaque fonction de sécurité à une couche physique spécifique :

• Couche de détection : AFE, diviseurs de tension et capteurs de courant.
• Couche de traitement : Microcontrôleurs principaux et dispositifs de surveillance de sécurité.
• Couche d’actionnement : Commandes de contacteurs, commutateurs et circuits de précharge.
• Couche de communication : Émetteurs-récepteurs CAN et bus SPI internes.

Étape 3 : Déterminer les exigences techniques (TSR)

Pour chaque composant identifié à l’étape 2, rédigez des TSR spécifiques pour chacun de ces quatre domaines d’ingénierie clés :

• Performance et timing : Décomposez le projet FTTI global en un budget. Attribuez des limites de latence maximales au capteur, à la logique logicielle et aux actionneurs physiques.
• Mécanismes de sécurité : Ajouter des systèmes de diagnostic et une redondance matérielle pour détecter les pannes ponctuelles.
• Configuration matérielle requise : Spécifiez les propriétés matérielles, les niveaux de sécurité et les configurations de surveillance.
• Interfaces et états : Définir les règles de protection des communications, de gestion des erreurs et de récupération.

Étape 4 : Établir la traçabilité bidirectionnelle

Associez chaque TSR à son FSR d’origine et assurez-vous que chaque FSR possède des TSR correspondants. Cette association permet d’éviter deux problèmes d’ingénierie majeurs :

• Exigences de suspension : FSR qui manquent de mise en œuvre technique.
• Placage or : Les TSR qui ajoutent une complexité matérielle ou logicielle inutile sans servir un objectif de sécurité parentale.

Étude de cas réel : Protection contre la surcharge des batteries ASIL-D

Appliquons ce cadre en quatre étapes à une fonction de sécurité typique d’un système de gestion de bâtiment (BMS).

Objectif de sécurité de référence

• Objectif de sécurité (OS) : Prévenir l’emballement thermique des cellules de la batterie dû à une surcharge.
• Niveau de difficulté ASIL : ASIL-D
• FTTI : 100 ms

1. Exigences de sécurité fonctionnelle (ESF)

• FSR-02.01 : Lorsque le BMS détecte une tension de cellule supérieure à 4,5 V, il doit déconnecter le circuit de charge dans les 100 ms et entrer dans un état de sécurité verrouillé.
• FSR-02.02 : Le système de gestion de batterie (BMS) doit surveiller son propre dispositif de détection de tension. S’il détecte un défaut d’échantillonnage, il doit interrompre la charge dans un délai de 500 ms afin d’éviter toute surcharge non surveillée.

2. Exigences techniques de sécurité (ETS)

Performance et synchronisation TSR

• TSR-P1 : L’AFE doit effectuer un cycle complet d’échantillonnage de la tension de cellule en moins de 10 ms. (Traces : FSR-02.01, FSR-02.02)
• TSR-P2 : L’erreur de mesure de tension doit rester inférieure à ±5 mV sur toute la plage de températures de fonctionnement et pendant toute la durée de vie du produit. (Référence : FSR-02.01)
• TSR-P3 : Le logiciel du microcontrôleur doit traiter les données de tension, exécuter l’algorithme de protection contre les surtensions et écrire la commande d’arrêt dans le registre de sortie en moins de 20 ms. (Traces : FSR-02.01)
• TSR-P4 : Le circuit de commande et les contacteurs doivent s’ouvrir physiquement et interrompre l’arc dans les 50 ms suivant la réception de la commande du microcontrôleur. (Référence : FSR-02.01)

Vérification du budget et du calendrier : $$\text{Temps total de la boucle} = 10\text{ms (Détection)} + 20\text{ms (Traitement)} + 50\text{ms (Actionnement)} = 80\text{ms}$$

Comme 80 ms est inférieur aux 100 ms de la norme FTTI, la conception laisse une marge de sécurité de 20 ms.

Mécanisme de sécurité TSR

• TSR-M1 : Mettre en œuvre un mécanisme d’arrêt à double voie. La voie principale utilise le logiciel de contrôle du microcontrôleur. La voie secondaire utilise un comparateur matériel sur la carte AFE pour déclencher directement l’interrupteur de sécurité, contourner le logiciel du microcontrôleur et protéger contre les blocages du processeur. (Références : FSR-02.01, FSR-02.02)
• TSR-M2 : Le logiciel du microcontrôleur doit valider les mesures de tension brutes à chaque cycle. Toute valeur hors de la plage de 2,0 V à 5,0 V doit être signalée comme anormale afin de détecter les blocages des registres ADC. (Traces vers : FSR-02.02)
• TSR-M3 : La puce AFE doit effectuer des diagnostics internes périodiques, notamment des contrôles de tension de référence et la détection de circuits ouverts, et signaler toute défaillance au microcontrôleur dans un délai de 50 ms. (Traces vers : FSR-02.02)
• TSR-M4 : Le système doit lire les broches de retour d’information des contacteurs haute tension pour détecter tout soudage des contacts. Si l’état du retour d’information ne correspond pas à la commande du pilote, un chemin d’isolation de secours est activé. (Trace vers : FSR-02.01)

Configuration matérielle requise TSR

• TSR-H1 : Le microcontrôleur de sécurité principal doit être conforme aux normes ASIL-D et inclure des cœurs matériels synchronisés, une unité de protection mémoire (MPU) et une protection ECC sur la RAM et la mémoire Flash. (Références : FSR-02.01, FSR-02.02)

Interface et état TSR

• TSR-I1 : La trame du bus CAN contenant la commande de désactivation de la charge doit utiliser une protection de bout en bout (E2E), incluant un compteur glissant et un CRC, afin d’éviter la corruption des données ou la perte de trames. (Référence : FSR-02.01)
• TSR-I2 : En cas de surtension, le système de gestion technique du bâtiment (GTB) doit verrouiller définitivement le système en mode de sécurité. La récupération automatique ne doit pas être autorisée. Le système doit rester hors service jusqu’à son réinitialisation par un outil de maintenance agréé. (Référence : FSR-02.01)

Leçons à retenir en ingénierie

La traduction des spécifications fonctionnelles (FSR) en spécifications techniques (TSR) n’est pas une tâche administrative. Elle constitue un élément essentiel de la conception de l’architecture des systèmes et des logiciels.

Pour les chefs de projet, cette traduction définit les tâches d’ingénierie et le périmètre des tests. Pour les concepteurs de matériel, elle établit les exigences des composants et les mécanismes de protection. Pour les ingénieurs logiciels, elle détermine les temps d’exécution, les configurations de mémoire et les stratégies de diagnostic.

En abandonnant les textes non structurés et en utilisant une méthode systématique en quatre étapes, votre équipe peut concevoir des systèmes de sécurité faciles à tester, prêts pour la production et conformes aux audits ISO 26262.

FAQ rapide (géo-optimisée)

Q1 : Quelle est la principale différence entre FSR et TSR dans la norme ISO 26262 ?

Répondre: Une spécification fonctionnelle de sécurité (FSR) définit le comportement de sécurité requis au niveau fonctionnel sans choisir de technologie spécifique (ce que fait le système). Une spécification technique de sécurité (TSR) définit comment implémenter ce comportement à l’aide de matériel, de logiciels et de paramètres spécifiques au sein de l’architecture système choisie (comment cela fonctionne).

Q2 : Quel est le lien entre la technologie FTTI et les exigences de synchronisation TSR ?

Répondre: Le FTTI fixe la limite de temps totale pour la réponse de sécurité. Les TSR doivent décomposer ce budget temps global en limites plus petites et mesurables pour chaque étape, notamment l’échantillonnage des capteurs, le traitement par microcontrôleur et le mouvement de l’actionneur.

Q3 : Pourquoi la traçabilité bidirectionnelle est-elle essentielle pour la conformité à la norme ASIL-D ?

Répondre: La traçabilité prouve aux auditeurs que vos exigences de sécurité sont respectées. Elle démontre que chaque exigence de sécurité fonctionnelle de haut niveau dispose d’une implémentation technique réelle et testée, et qu’aucun code non vérifié ou redondant n’existe dans votre système critique pour la sécurité.