Le processeur de surveillance et le watchdog : les trois niveaux
Un calculateur ne se contente pas de piloter le moteur : il se surveille lui-même, et il est surveillé par un autre composant. Comprendre cette architecture explique une bonne partie des comportements les plus déroutants du métier, à commencer par le repli qui survient plusieurs minutes après le démarrage.
Pourquoi une surveillance séparée
Le raisonnement est celui de la sécurité fonctionnelle. Un moteur à papillon motorisé n'a plus de liaison mécanique entre la pédale et la puissance produite. Si le programme se trompe, rien de mécanique ne l'arrête. Il faut donc un dispositif qui vérifie, indépendamment du programme principal, que la puissance produite reste bien celle que le conducteur a demandée.
La solution retenue par l'industrie est une architecture en couches, souvent décrite comme un concept moniteur à trois niveaux. Sa mise en œuvre exacte varie d'un constructeur et d'un fournisseur à l'autre — ce n'est pas un standard unique — mais la logique est très largement partagée.
Niveau 1 : les fonctions
C'est le calculateur au sens habituel : acquisition des capteurs, modèle de couple, arbitrage, régulations, commande des actionneurs. C'est le niveau que décrivent le modèle de couple et les limiteurs chaînés. Il porte aussi ses propres contrôles de cohérence sur les capteurs.
Niveau 2 : la surveillance fonctionnelle
Ce niveau tourne sur le même processeur, mais avec ses propres calculs et ses propres paramètres. Sa mission tient en une phrase : vérifier que le couple effectivement produit ne dépasse pas le couple admissible, recalculé de façon indépendante à partir de la position de la pédale et des conditions du moment.
Deux points le rendent redoutable :
- Il ne réutilise pas le résultat du niveau 1 : il refait le calcul autrement, avec ses propres tables. Une incohérence entre les deux chemins est précisément ce qu'il cherche.
- Sa réaction est franche. Selon la gravité et la persistance : limitation de couple, coupure de l'injection sur tout ou partie des cylindres, mise en repli, voire arrêt du moteur.
C'est le mécanisme qui fait qu'une modification incohérente est détectée par le calculateur lui-même, sans qu'aucun outil extérieur n'intervienne. Si la chaîne fonctionnelle délivre davantage que ce que la chaîne de surveillance juge admissible, la surveillance tranche.
Niveau 3 : la surveillance du calculateur
Ce niveau ne surveille plus la fonction, mais le matériel. Il comprend deux volets.
D'abord des autotests exécutés par le processeur lui-même : vérification du jeu d'instructions, contrôle de la mémoire vive, contrôle des convertisseurs analogique-numérique, contrôle des mémoires de programme.
Ensuite, et c'est le point le plus important, un composant séparé : le circuit de surveillance, souvent intégré au composant d'alimentation du calculateur. Il pose au processeur des questions dont il connaît la réponse, et attend la bonne réponse dans une fenêtre de temps — ni trop tôt, ni trop tard. Une réponse fausse, absente ou hors fenêtre entraîne une réaction matérielle : réinitialisation du processeur et, sur les architectures les plus strictes, coupure directe de l'alimentation des étages de sortie qui commandent les injecteurs.
C'est cela, le watchdog au sens propre : un chien de garde qui n'a pas besoin que le programme principal soit sain pour agir, puisqu'il n'en dépend pas.
L'intégrité du contenu, en plus
À ces trois niveaux s'ajoute un contrôle d'une autre nature, documenté dans le rapport technique interne : beaucoup de firmwares MED17 et EDC17 implémentent une surveillance d'intégrité périodique en fonctionnement. Des tâches de fond recalculent en continu les sommes de contrôle des régions mémoire critiques et déclenchent une réaction de défaut — repli, coupure, mémorisation d'un code — si une altération est détectée.
C'est l'explication technique du cas de terrain le plus décrit du métier : la voiture roulait, et au bout de cinq minutes elle s'est mise en mode dégradé. La vérification au démarrage était passée ; c'est la vérification périodique qui a réagi. Voir qu'est-ce qu'un checksum et le mode dégradé vu de la calibration.
Ce qu'il faut en retenir en atelier
Un repli différé n'est pas un hasard. Un défaut qui apparaît après un délai reproductible désigne un contrôle périodique ou une condition d'activation de moniteur, pas un composant qui « chauffe ».
Une coupure franche n'est pas la même chose qu'une limitation progressive. Une limitation progressive vient d'un limiteur de niveau 1. Une coupure nette, immédiate, éventuellement suivie d'une réinitialisation du calculateur, oriente vers les niveaux 2 et 3.
Un calculateur qui se réinitialise en roulant — instrumentation qui s'éteint une fraction de seconde, compteurs qui se remettent à zéro — est un cas de watchdog ou d'alimentation, pas de cartographie. La première mesure à faire est alors électrique. Voir la chute de tension et le 5 volts de référence.
Enfin, cette architecture explique pourquoi la cohérence d'ensemble d'un fichier n'est pas une question de style : elle est vérifiée en permanence par le calculateur. C'est le motoriste qui en répond, et c'est une raison de plus pour que le reprogrammateur n'improvise pas sur des paramètres isolés.
Voir aussi les seuils de plausibilité, bootloader et BSL et les protections du microcontrôleur.
Sur ANP Engineering — file service de reprogrammation moteur pour professionnels : file service ECU, correction de checksum, calculateurs pris en charge, tarifs.
