Le calculateur en sommeil qui ne répond pas : le réveiller proprement

Un calculateur qui ne répond pas — non parce qu'il est en panne, mais parce que le bus s'est endormi (le véhicule « dort »), ou parce que le module est resté en sommeil. C'est une fausse panne très fréquente, et elle se règle non pas en changeant une pièce, mais en remettant le véhicule et la session dans le bon état. Encore faut-il savoir comment ces réseaux dorment et se réveillent.

Diagnostic

Les réseaux modernes se mettent en sommeil peu après la coupure du contact, pour ménager la batterie : les modules passent en basse consommation et ne gardent active qu'une voie de réveil. Si l'outil ne place pas le véhicule dans le bon état (contact mis, parfois moteur tournant), ou s'il ne maintient pas la session vivante, le calculateur se rendort et cesse de répondre au beau milieu d'un échange. Sur les architectures à réseau partiel (partial networking), certains calculateurs ne se réveillent que sur une trame de réveil spécifique, et pas sur n'importe quel trafic : d'où des cas où « le bus est là » mais où un module précis reste silencieux.

Le symptôme typique est parlant : la lecture démarre, puis l'opération retombe après quelques secondes d'inactivité. Côté protocole, le mécanisme est simple à comprendre : quand l'outil ouvre une session non par défaut, le calculateur arme un temporisateur d'inactivité — le fameux S3, de l'ordre de 5 secondes. Chaque requête le réarme. Le service Tester Present (0x3E) existe précisément pour réarmer ce temporisateur sans rien demander d'autre : c'est le « je suis toujours là » de l'outil. On peut même demander de supprimer la réponse positive pour garder le bus calme et n'envoyer qu'un battement discret. Le service CommunicationControl (0x28), lui, sert à piloter la communication — utile pour réveiller un nœud ou, à l'inverse, faire taire des émissions pendant une opération.

Résolution

Pour tenir le calculateur éveillé :

• placer le véhicule dans le bon état : contact mis, moteur tournant si l'opération l'exige ; éviter d'ouvrir et fermer les portes sans arrêt, ce qui fait basculer certains réseaux entre veille et réveil ;
• laisser l'outil envoyer un Tester Present régulier, sur un rythme fixe — de l'ordre de S3 divisé par deux, soit environ 2,5 s — pendant toute une opération longue, et pas seulement quand le bus semble au repos ; beaucoup d'outils ont une option « maintenir éveillé » à activer ;
• garder un chargeur branché, pour que la tension ne devienne jamais une raison de retomber en veille ;
• pour les calculateurs à réseau partiel, prévoir la trame de réveil spécifique attendue par ce module.

À éviter absolument : laisser la session « traîner » entre deux étapes. Un blanc de quelques secondes suffit à faire retomber le calculateur en session par défaut — on perd l'accès de sécurité durement obtenu, et l'opération échoue là où tout se passait bien. Sur un flash long, le keep-alive doit tourner du début à la fin.

Ce qu'on en retient

Un calculateur muet n'est pas forcément mort : très souvent, il dort. Contact mis, chargeur branché, keep-alive qui tourne, et il répond. Si le silence date d'une intervention sur l'alimentation, on croise avec la reprise après changement de batterie ; si le lien saute par à-coups, c'est plutôt une perte intermittente ; et si l'initialisation ne s'ouvre pas du tout, on repart de l'erreur d'initialisation.

Sur ANP Engineering — file service de reprogrammation moteur pour professionnels : file service ECU, correction de checksum, calculateurs pris en charge, tarifs.