Quiconque développe dans l'automobile connaît les tampons qui figurent sur chaque cahier des charges : QM, ASIL-A, ASIL-B, ASIL-C, ASIL-D. L'acronyme signifie « Automotive Safety Integrity Level » et provient de l'ISO 26262 — la norme de sécurité fonctionnelle pour les véhicules routiers. Entre QM et ASIL-D s'étend un univers de charge de processus, de volume documentaire et de coûts de développement.
Dans la pratique, ASIL-B est le niveau le plus fréquent pour les calculateurs en série. Commandes moteur, électronique de freinage, prétraitement caméra, gestion de batterie — beaucoup de ces composants sont ASIL-B. Et c'est précisément là que les choses deviennent concrètes pour le développeur C.
Cet article décrit ce qu'ASIL-B a réellement signifié dans les projets auxquels j'ai participé — au-delà des citations de la norme. Pas de théorie, mais les pierres d'achoppement et ce qui compte lors d'un audit.
Ce qu'exige ASIL-B selon la norme
L'ISO 26262-6 (développement produit au niveau logiciel) définit des tableaux avec « highly recommended », « recommended » et « no recommendation » pour chaque activité et niveau ASIL. Pour ASIL-B, cela signifie en résumé :
- Règles de codage : MISRA-C est pratiquement imposé (tableau 1 de la norme : « highly recommended »)
- Analyse statique du code : highly recommended
- Revue de code : highly recommended, avec des relecteurs ayant la qualification requise
- Tests unitaires avec couverture des branches : highly recommended (la couverture des instructions seule ne suffit pas)
- Tests d'intégration : highly recommended
- Injection de fautes : recommended
- Programmation défensive : highly recommended
Et — c'est important — chaque outil utilisé pouvant influencer le code (compilateur, générateur de code, framework de test) doit être qualifié ou classifié selon l'ISO 26262-8. J'y reviens plus bas.
MISRA-C : le portier sous-estimé
MISRA-C n'est pas l'ennemi du développeur C — même si les quelque 170 règles et directives de l'actuelle MISRA-C:2012 paraissent écrasantes au début. La plupart des règles sont simplement raisonnables : pas de conversions implicites, pas de goto en arrière, pas d'ombrage de noms de variables, pas d'allocation dynamique.
Ce qui rend la chose difficile en pratique, c'est autre chose : MISRA distingue Required, Advisory et Mandatory. Et chaque écart nécessite une déviation formelle — un cas d'exception justifié par écrit, revu et signé par le responsable sécurité.
« Nous avions environ 400 déviations à la clôture d'un projet. Chacune nécessitait une justification, une analyse de l'impact sur la sécurité et une contre-signature. Ce n'est pas de la paperasse — c'est un vrai travail. »
Pièges classiques :
- Règle 10.x (conversions implicites) : presque inévitable en manipulation de bits. Chaque ligne du style
uint8_t a = b & 0x0F;est examinée de près. - Règle 11.x (conversions de pointeurs) : l'accès matériel requiert presque toujours un cast de pointeur. Résoluble, mais à documenter.
- Règle 21.3 (pas d'allocation dynamique) : souvent surprenant — même des structures statiques avec pointeurs sont parfois signalées quand le cycle de vie n'est pas clairement documenté.
Recommandation pratique
Quiconque planifie du code ASIL-B dès le départ doit penser MISRA depuis le début. Rendre rétroactivement une base de code existante conforme MISRA coûte trois à cinq fois plus cher que de le faire correctement dès le début. Des outils comme Polyspace, LDRA ou Helix QAC vérifient automatiquement — mais aucune règle n'est 100 % vérifiable automatiquement. Certaines règles exigent un jugement humain.
L'analyse statique, c'est plus qu'une coche verte
La norme exige une analyse statique — ce qui est souvent mal compris comme « faire tourner le checker MISRA ». En réalité, l'ISO 26262 signifie beaucoup plus :
- Analyse de flot de contrôle : trouver tous les chemins inaccessibles.
- Analyse de flot de données : trouver les variables utilisées sans être initialisées.
- Interprétation abstraite : trouver les dépassements de tableaux, divisions par zéro, débordements entiers.
- Analyse sémantique : trouver les conditions de course dans les interruptions, les dépendances de données entre modules.
Des outils comme Polyspace Code Prover rendent les trois premiers points formellement prouvables — pas seulement heuristiques. L'outil parcourt tous les chemins d'exécution possibles et colore chaque opérateur en vert (sûr), rouge (erreur) ou orange (indéterminé). L'orange est l'ennemi : chaque cas doit être analysé manuellement.
Retour de terrain
Un run Polyspace sur un composant moyen de commande moteur peut prendre plusieurs heures. L'analyse identifie typiquement 50 à 200 zones oranges pour 10 000 lignes de code. Chacune doit être évaluée : est-ce une vraie erreur, ou l'outil manque-t-il simplement de contexte ?
La plupart des oranges se révèlent faux positifs. Mais chaque passage trouve aussi 2 ou 3 vraies erreurs qu'aucune revue de code ni test unitaire n'aurait détectées.
Couverture de test : la couverture des instructions ne suffit pas
ASIL-B exige selon l'ISO 26262-6 tableau 12 au minimum la couverture des branches au niveau unitaire. Pour ASIL-C et ASIL-D s'ajoute la couverture MC/DC (Modified Condition/Decision Coverage).
La différence est importante :
| Type de couverture | Ce qui est vérifié | Niveau ASIL |
|---|---|---|
| Statement Coverage | Chaque instruction est exécutée au moins une fois | QM, A |
| Branch Coverage | Chaque branche (if/else) est parcourue dans les deux directions | B |
| MC/DC | Chaque condition d'une combinaison influence indépendamment | C, D |
Un petit exemple pour illustrer :
if (capteur_ok && (rpm > 1000)) {
declencher_action();
}Pour le Statement Coverage, un test suffit où les deux conditions sont vraies et declencher_action() est appelée.
Pour le Branch Coverage, il faut en plus un test où la condition globale est fausse — peu importe laquelle des deux parties fait pencher la balance.
Pour MC/DC, il faut montrer que les deux sous-conditions influencent le résultat indépendamment. Dans ce cas, trois cas de test sont requis. Pour des combinaisons de cinq ou six sous-conditions, le nombre de cas de test explose.
Conséquence pratique
Les tests unitaires ASIL-B sont volumineux mais gérables. Des outils comme Cantata, VectorCAST ou TestWell CTC++ instrumentent le code et mesurent la couverture au niveau du code objet. On a typiquement besoin de 3 à 5 cas de test par fonction.
Passer à ASIL-D (assistance au maintien de voie, déclenchement airbag) devient douloureux : 8 à 20 cas de test par fonction, beaucoup avec des entrées créatives pour combler les lacunes MC/DC.
Programmation défensive : qu'est-ce que cela signifie concrètement ?
L'ISO 26262 exige une programmation défensive sans dire précisément ce que c'est. Dans la pratique automobile, plusieurs patrons se sont imposés :
Vérifier les paramètres d'entrée
void regler_rpm(uint16_t rpm)
{
if (rpm > MAX_RPM) {
rpm = MAX_RPM; /* écrêter plutôt qu'échouer */
/* Optionnel : entrée en mémoire défauts */
}
/* ... */
}Ne pas déclencher d'assertion — cela arrête le véhicule. En code ASIL-B, une entrée fautive est généralement masquée et éventuellement journalisée.
Contrôles de plausibilité à l'exécution
uint32_t lire_capteur_temperature(void)
{
uint32_t t_raw = adc_read(TEMP_CANAL);
if ((t_raw < TEMP_MIN_RAW) || (t_raw > TEMP_MAX_RAW)) {
poser_defaut(DEFAUT_CAPTEUR_TEMP);
return TEMP_DEFAULT; /* valeur de repli */
}
return t_raw;
}Pas de boucles infinies
Chaque boucle while(1) (sauf dans le scheduler principal) a besoin d'un compteur de timeout. Chaque do..while d'une sortie propre.
Watchdog pas seulement au début et à la fin
Erreur classique du débutant : déclenchement du watchdog avant et après la tâche principale. Mieux : à l'intérieur des opérations longues avec plusieurs points de déclenchement, afin qu'une tâche bloquée soit détectée.
Qualification des outils : l'effort souvent négligé
Chaque outil dont la sortie entre dans le produit doit être évalué selon l'ISO 26262-8. Cela concerne :
- Compilateurs (GCC, IAR, Green Hills)
- Générateurs de code (Simulink Embedded Coder, TargetLink)
- Assembleurs, éditeurs de liens, débogueurs
- Outils d'analyse statique
- Frameworks de test
- Gestion de versions (Git, PTC Integrity)
La classification se fait via le TCL (Tool Confidence Level) 1, 2 ou 3. Un compilateur atteint typiquement TCL3 — le niveau le plus élevé — et doit soit être qualifié (par l'éditeur, avec safety manual), soit sécurisé par des mesures compensatoires (décompilation, comparaison désassemblage).
Facteur de coût numéro un
Sous-estimer la qualification des outils est le facteur de coût le plus fréquent des projets ASIL. Découvrir en pleine développement que le compilateur choisi n'a pas de build qualifié oblige soit à changer (coût en millions), soit à introduire de lourdes mesures compensatoires.
Recommandation pratique : avant la première ligne de code, lister la chaîne d'outils et demander la documentation de qualification aux éditeurs. Ce n'est pas une formalité — c'est critique pour le projet.
Tiré d'un projet réel
Je me souviens d'un équipementier automobile d'origine mécanique, qui livre traditionnellement des composants mécaniques et qui avait décidé de développer lui-même le logiciel de commande de son actionneur de frein de parking. L'équipe logicielle était basée à Detroit, aux États-Unis. Le développement s'est déroulé selon le calendrier pendant des mois — jusqu'à ce que, juste avant la livraison du jalon au client européen, la question du safety manual du compilateur surgisse.
La réponse : le compilateur C utilisé à Detroit n'était pas qualifié pour l'ISO 26262. Pas de classement TCL par l'éditeur, pas de safety manual, pas de liste documentée des problèmes compilateur liés aux exigences de sécurité. La panique a été immense. Le frein de parking n'est pas une fonction secondaire — il est critique en sécurité, car un déblocage non désiré sur un véhicule en pente peut entraîner un déplacement incontrôlé.
Ce qui a été fait finalement est le paquet classique de mesures compensatoires : comparaison désassemblage de fonctions clés sélectionnées, tests d'intégration supplémentaires avec injection de fautes renforcée, analyse documentée de l'usage de l'outil. Le tout parce qu'au début du projet, personne n'avait posé la question simple : « Notre compilateur est-il réellement qualifié pour l'ASIL que nous devons livrer ? »
La leçon : si vous êtes un équipementier mécanique qui fait du logiciel pour la première fois, ne traitez pas la qualification des outils comme un détail. Et si vous répartissez le développement sur plusieurs sites géographiques, assurez-vous que les exigences de processus du client final sont connues et appliquées sur chaque site.
Ce qui distingue concrètement ASIL-B de QM
Beaucoup de débutants demandent : « Quelle différence entre du code QM et du code ASIL-B ? Le même code C fait la même chose. » Techniquement, c'est vrai. Organisationnellement, c'est le jour et la nuit :
| Activité | QM | ASIL-B |
|---|---|---|
| Traçabilité des exigences | recommandée | obligatoire (supportée par outils) |
| Revue de code | recommandée | obligatoire, documentée, qualification définie du relecteur |
| Conformité MISRA-C | nice-to-have | obligatoire, déviations formelles |
| Couverture tests unitaires | instructions | branches |
| Qualification des outils | non requise | obligatoire |
| Injection de fautes au niveau HW | non | recommandée |
| Documentation par LOC | 1× | 5 à 10× |
Le facteur de la dernière ligne n'est pas exagéré : la documentation produite autour du code dans un projet ASIL-B dépasse largement le volume du code. Safety Plan, Safety Case, analyse HAZOP, FMEA, plan de validation, plan de vérification, plan d'intégration, rapports de tests — chacun de ces documents n'est pas un formulaire mais un travail à part entière.
Ce que je conseille aux débutants
- Lisez la norme. Pas entièrement, mais ISO 26262-6 (Software Development) et -8 (Supporting Processes) font partie du bagage de base. Celui qui ne lit que le cahier des charges ne comprend pas pourquoi il est écrit ainsi.
- Introduisez MISRA-C tôt. Le premier jour du projet, pas après le premier test d'intégration.
- Fixez la chaîne d'outils en début de projet. Version du compilateur, serveur de build, outil d'analyse statique — ce sont des décisions à peine révocables ensuite.
- Les tests sont obligatoires, pas optionnels. Celui qui garde les tests « pour la fin du projet » ne livrera pas le projet. Les tests s'écrivent en même temps que le code.
- Établir une culture de revue. Les revues ne sont pas une formalité. Un auditeur sécurité examine les protocoles de revue : des vraies questions ont-elles été posées, ou seulement des cases cochées ?
- Les exigences sont l'ancre. Sans exigences propres et traçables, pas de Safety Case. DOORS ou Polarion sont le standard ici.
Conclusion
ASIL-B n'est pas difficile — il est lourd. Celui qui n'en voit pas la valeur ajoutée perçoit le processus comme une contrainte. Celui qui a vu une fois l'analyse statique trouver une vraie condition de course qui aurait causé un accident sur le terrain comprend pourquoi la norme est si détaillée.
En 35 ans de développement automobile, j'ai appris : la qualité ne vient pas des tests à la fin, mais du processus, des outils et de la discipline tout au long du développement. L'ISO 26262 est moins un obstacle qu'une checklist des choses que j'attendrais pour du bon code automobile, même sans norme.
Le plus grand saut pour le débutant n'est pas le code — c'est de comprendre qu'ASIL-B est une qualité, et que la qualité a un prix : en heures, en documentation et en engagement sur chaque étape. En retour, on obtient du code sur lequel on peut compter. Et dans le monde automobile, ça vaut le prix.