Voici un point de nos recherches en cours.
L’expérience est très intéressante et mérite d’être partagée puisque, au-delà de la recherche de panne proprement dite, nous avons découvert un certain nombre d’éléments — et aussi certaines limites — tant en ce qui concerne le fonctionnement du système lui-même que celui de l’interface OBD.
Il me semble également utile de rappeler qu’aucun de nous n’est spécialiste de ces systèmes, encore moins professionnel de la réparation automobile. Et en ce qui me concerne, je n’ai ni Disco, ni Nanocom.
Enfin, il faut constamment garder à l’esprit que les interfaces OBD ne permettent quasiment jamais d’accéder à la réalité physique sous-jacente : tout ce qui remonte via ces outils est le résultat de traitements algorithmiques plus ou moins alambiqués mis en forme par différentes couches logicielles plus ou moins sophistiquées. Le tout restant subordonné à une fréquence d’acquisition qui, par sa relative lenteur, ne permet pas de suivre avec une précision suffisante les phénomènes les plus rapides.
Venons-en au vif du sujet.
Tout d’abord, voici une image partielle de ce que contient l’extraction réalisée par le Nano :
Excepté la colonne « Temps », rajoutée pour les besoins de la cause, on constate que les différentes variables sont bien celles proposées par le menu du Nano auquel on accède par les onglets suivants :
DISCOVERY II/
TD5/
SLABS/
INPUTS/
INPUT ABS
Si, maintenant, sur le menu du Nano (le simulateur est très pratique pour ceux, qui comme moi, ne possèdent pas l’outil) on clique sur la flèche verte orientée vers la droite, on fera dérouler les différents paramètres qui, lors du lancement de l’enregistrement, seront collectés dans un seul et unique fichier :
les tensions délivrées par les capteurs de roue SENS (V)
les vitesses calculées WHEEL SPEED (Km/h)
la tension commandant les tiroirs d’admission de la pression du liquide de frein aux quatre roues INLET VALVE (V)
idem mais pour les tiroirs commandant la chute de pression OUTLET VALVE (V)
la tension de commande de la pompe hydraulique du bloc ABS PUMP MONITOR (V)
celle actionnant le relais de pompe PUMP RELAY (V)
la tension batterie
la tension alimentant le calculateur
la référence à la masse GROUND REFERENCE (V)
la vitesse de rotation du moteur ENGINE SPEED (rpm)
le couple moteur ENGINE TORQUE (N·m)
la position de l’accélérateur électronique THROTTLE POSITION (%)
la tension appliquée à la commande du contrôle de descente HDC Brake (V)
l’intensité parcourant le circuit de contrôle d’état des vannes trois voies (vannes navettes) SHUTTLE SWITCH
Remarques :
- les paramètres moteur sont fournis par l’ECU contrôlant le moteur (via des liaisons filaires dédiées, car il ne semble pas exister de réseau CAN sur ce modèle de 4x4) ;
- nous supposons que la variable d’état des vannes navettes est un courant exprimé en milliampères (mA). La suite du propos va montrer qu’à ce jour, c’est vers cette partie du circuit que sont en train de s’orienter nos recherches : il faut donc s’attendre à des évolutions concernant ce point ;
- la colonne « temps », indispensable aux représentations graphiques et autres analyses mathématiques, a nécessité la détermination de la fréquence d’échantillonnage du Nano, la valeur de ce paramètre n’étant précisée nulle part : nous avons donc chronométré la durée des enregistrements et divisé le nombre de lignes du fichier pour la déterminer. Comme la plupart des OBD, le Nano semble cadencé à la seconde ;
- Enfin, le nombre de données collectées en une fois est plus élevé que sur de nombreux OBD (14 pour cette fonction) et le panel de variables proposé par les concepteurs de l’outil s’avère, à l’usage, assez judicieux.
Venons-en à ce que ce fichier nous enseigne, sachant que le Disco de Pascal constitue évidemment la situation de référence.
On commence par ce qui remonté par l’OBD (paramètre WHEEL SPEED) pour les quatre capteurs de vitesse des roues :
Comme précisé dans la doc du Nano mise en ligne par Laurent le 30/10/2023 à 17:59 (fichier FONCTIONS DIAGNOSTIQUE DE L ABS-SLS SLABS DiscoveryII_V2_05) véhicule à l’arrêt ou en dessous de 1,7 km/h, le système ne voit rien.
C’est bien ce que confirme le graphe : on voit bien la montée, puis la descente en vitesse, qui encadrent un palier, sachant que la consigne était pour cet essai de stabiliser la vitesse aux alentours de 6 km/h. En effet, des recherches effectuées par Pascal ont révélé que le système (ECU + Nano) ne pouvait pas restituer de valeurs au-delà de 8 à 10 km/h, soit au-delà du seuil d’armement de l’ABS.
D’où les interruptions de communication entre l’ECU et le Nano signalées supra.
Très ennuyeux dans la mesure où l’on ne peut pas disposer d’une analyse dynamique de la réponse du système pour des vitesses plus élevées.
J’ai été surpris par la relative dispersion des valeurs restituées par le système de Pascal : on constate en effet que les courbes sont constituées de lignes plus ou moins brisées traduisant des changements, faibles mais rapides, de la vitesse de rotation des roues.
Si on calcule la variation instantanée des vitesses remontées pour le capteur le plus instable (roue ARG), on obtient ceci :
Mathématiquement, la courbe bleue est la dérivée de la vitesse calculée par le système et physiquement, c’est une accélération (la vitesse est constante lorsque l’accélération est nulle). De telles variations n’ont évidemment aucun sens physique : elles sont inhérentes au système lui-même et constituent potentiellement un paramètre permettant d’apprécier la qualité de la restitution de l’interface OBD.
Sur le Disco de Laurent, on constate au contraire que les valeurs sont beaucoup régulières :
Il en résulte que l’accélération est plus homogène :
La comparaison des deux 4x4 ne met en évidence aucun défaut aux capteurs de vitesse de roue : les valeurs sont parfaitement homogènes (aucun capteur ne décroche) et le système répond normalement.
Passons maintenant à la restitution des tensions délivrées par ces mêmes capteurs sur le véhicule de Pascal et voyons comment elles évoluent (SENS (V) et WHEEL SPEED (Km/h)) :
On ne constate aucun lien entre la vitesse remontée et la tension capteur ; tout au plus un léger fléchissement de la tension capteur lorsque la vitesse du véhicule franchit le « seuil de visibilité », soit 1,7 km/h.
Sur le 4x4 de Laurent, on note une faible élévation de tension à partir du seuil de visibilité.
En résumé, aucun signe de dysfonctionnement non plus pour ce paramètre :
Arrêtons-nous un instant sur cette grandeur, car elle est intéressante à plus d’un titre.
Dans la doc postée le 30/10/2023, il est en effet précisé que la « tension d’entrée » doit être comprise entre 2,2 et 2,4 V. Le système étant limité en vitesse comme on l’a vu, ces valeurs s’entendent donc pour une vitesse inférieure à 8-10 km/h.
Pascal reviendra certainement sur le résultat de ses recherches qui, entre autres points très surprenants, précise que la vérification d’un capteur de roue au Nano doit s’effectuer en faisant tourner chaque roue, au préalable levée, à la main…
Surprenante, la méthode.
Par ailleurs, je ne comprends pas ce à quoi la notion de tension d’entrée renvoie : comme le fichier n°397 posté le 03/11/2023 à 23H44 le montrait, la tension brute délivrée par un capteur à réluctance variable est périodique et assimilable à une sinusoïde.
En d’autres termes, il s’agit d’un signal variable en tension comme en fréquence, la variation étant par ailleurs une fonction — non linéaire — de la vitesse linéaire des dents de la mire.
Formulé encore autrement, il ne peut s’agir de la tension de crête ni de la tension efficace du signal.
Pour illustrer comment varie la réponse d’un capteur à réluctance — désolé pour la qualité des graphes pêchés sur le Net, mais ce n’est que depuis peu que j’archive mes oscillogrammes — prenons le cas d’un vilebrequin moteur, généralement équipé du même type de capteurs :
Le repère 2 sur le graphe correspond à la « dent en moins » permettant au calculateur moteur de repérer le point mort haut.
Le repère 4 traduit l’accélération du volant moteur lorsque la combustion fait son œuvre (les gaz cèdent une partie de leur énergie au volant).
Le repère 3 marque le ralentissement du volant lorsque la compression s’amorce : le volant cède une partie de son énergie cinétique pour échauffer l’air.
On constate que le ralentissement, bien que faible (quelques t/mn) est néanmoins suffisant pour provoquer une fluctuation de la tension délivrée par le capteur. Il en serait de même pour la fréquence mais pour le voir, il faudrait de changer la résolution de l’oscilloscope.
Une autre présentation souligne l’amplitude des tensions que peuvent émettre ces capteurs :
Selon les applications, la tension de sortie capteur peut aller de 2 à 20 volts en fonction de la vitesse de passage des dents de la mire devant le capteur.
Il est bien évident que la fluctuation de la vitesse des roues a une influence similaire sur nos capteurs de roue : la notion de tension d’entrée constante mentionnée dans la doc n’a donc pas de sens physique.
Précision du vocabulaire, explicitation claire et nette des notions introduites dans les documentations techniques, rigueur des démonstrations et des explications, c’est la base, non seulement du boulot, mais aussi du respect du lecteur.
Aujourd’hui, on assiste à une diffusion de plus en plus confidentielle des docs. Secret industriel, qui disent.
L’arme des faibles, en somme. Ce qui, d’ailleurs, n’empêche pas une baisse régulière de la qualité des docs, progressivement remplacées par des systèmes-expert, censés permettre à n’importe quelle quiche (à condition que la dite quiche ait payé le « service », de préférence au mois, lui donnant accès au dit système) de résoudre n’importe quel problème.
Les petites bites, bien aidées par le numérique, sont promises à un bel avenir, c’est évident.
Revenons à nos moutons.
J’aurais donc tendance à considérer que la tension capteur en question renvoie à ce que le calculateur voit après traitement approprié du signal (toujours ces couches algorithmiques et logicielles s’interposant entre l’humain et la réalité physique que j’évoquais supra).
Détaillons donc ce point, car il permet, au passage, de mieux cerner les enjeux attachés à une panne capteur un peu taquine.
En principe, le circuit transformant le signal brut émis par un capteur à réluctance afin qu’il devienne exploitable par un circuit numérique est un trigger de Schmitt (bascule de Schmitt en français). Ce montage est utilisé depuis longtemps, car il permet de transformer des signaux périodiques — ou apériodiques — d’amplitude quelconque en signaux rectangulaires dont l’amplitude est fixe car dépendante de la conception de la bascule. Avec la généralisation de l’électronique numérique, tout signal quelconque peut donc être transformé en une impulsion comprenant un niveau haut prédéfini et un niveau bas (égal à 0) et dont la largeur (il s’agit d’un temps) dépend de la pulsation (fréquence) du signal initial.
Noter que les capteurs à circuit de Hall — de plus en plus utilisés comme capteurs d’ABS — conduisent quasiment au même résultat, avec une largeur d’impulsion fixe, toutefois.
L’étude du circuit de Schmitt sort du cadre du propos ; son effet, par contre, y occupe une place centrale.
Si on reprend notre signal brut et qu’on le passe à la bascule, on obtient ceci :
Ici, le seuil de déclenchement des fronts montant et descendant du signal est identique et est fixé à 2 V. Ces seuils pourraient être différents, surtout avec un signal périodique dissymétrique comme c’est le cas pour notre capteur.
Dès que le signal montant dépasse 2 volts, la bascule (le circuit appartient à la famille des amplificateurs) donne naissance, de manière quasi-instantanée, à une tension prédéfinie (ici, 2,7 volts). De même, dès que le front descendant intercepte le seuil bas de déclenchement, la tension émise par la bascule retombe immédiatement à 0.
Le circuit transforme donc le signal brut (en bleu) en un signal parfaitement calibré (en vert) : la tension ne peut prendre que deux valeurs et tous les parasites ont disparu.
Vu la manière dont la doc est rédigée, je suppose que la valeur de la tension d’entrée dont il est question est, soit la tension de seuil, soit la tension délivrée par le trigger. Ce sont en effet les seules qui ne varient pas, quoi qu’il arrive.
L’utilisation de cette grandeur peut laisser perplexe : toutefois, lors de nos échanges avec le regretté Volta, nous pensions qu’une interface OBD judicieusement utilisée pouvait aussi permettre d’identifier l’étage du calculateur défaillant. En l’espèce, si on a une tension capteur à l’OBD mais pas de valeur de vitesse aux roues, cela pourrait signifier que le trigger est opérationnel mais que le circuit convertissant la fréquence en vitesse est HS. De même, si on n’a rien en tension et rien en vitesse, cela pourrait signifier que c’est le d’abord le trigger qui a pris un shoot...
La largeur de l’impulsion vaut t et le cycle total T. On peut calculer le rapport t/T et compter le nombre d’impulsions durant un laps de temps précis (10 millisecondes, par exemple) ce qui permet d’identifier toute anomalie dans le signal.
C’est sans doute ce que l’ECU d’ABS réalise et c’est ce que je craignais initialement comme panne, car le fait d’être limité en vitesse par l’interface OBD ne permet pas de poser un diagnostic fiable sans oscilloscope.
Une coupure ou un court-circuit francs du capteur ou de la ligne sont des cas d’école : pas de signal, pas de tension, le défaut est détectable en dix secondes.
Si, par contre, on est confronté à un défaut du noyau magnétique (aimant fêlé en raison d’un choc ou d’un serrage excessif, ce qui aboutit à deux pôles nord et deux pôle sud) entrefer mal réglé, ligne de transmission coupée ou en court-circuit intermittent, la détection du défaut devient beaucoup plus acrobatique.
Le pire est un défaut du noyau magnétique : comme le montre la figure ci-dessous, les caractéristiques magnétiques du capteur dépendent de la masse métallique évoluant à proximité du capteur. Avec un noyau magnétique perturbé ou endommagé, le signal change totalement. Évidemment, un tel défaut est indétectable à l’ohm mètre, cet instrument ne s’intéressant qu’à l’intégrité du bobinage :
La planche suivante illustre ce qui se passe en cas de faiblesse du diélectrique du fil conduisant le signal au calculateur :
Supposons que la tension de claquage soit de l’ordre de 3,5 volts. Dès que l’isolant « perce », la tension retombe à 0 car le circuit présente alors un défaut qui le met à la masse. Le niveau de tension intercepte donc le seuil de déclenchement descendant du trigger au point indiqué par le repère. La bascule ramène donc la tension à 0 instantanément.
La largeur d’impulsion n’est plus du tout la même (t/T a été divisé par plus de trois) ; mais la fréquence ne change pas, car le nombre d’impulsions décomptées en un temps donné ne changera pas.
Pour que la fréquence change, il faudrait que plusieurs impulsions passent à la trappe.
La détection de ces deux défauts dépend donc de la conception des programmes de calcul, à laquelle généralement personne n’a accès, caviardage systématique oblige ; d’où le recours impératif à l’oscilloscope pour vérifier de manière absolument fiable les capteurs.
On va voir maintenant qu’une autre piste doit être explorée, ce qui conduit à mettre cette possibilité de panne entre parenthèses pour l’instant.
En comparant les fichiers des deux Disco, il est apparu que la grandeur « Shuttle Switch » différait.
Le fichier ci-dessous, issu du 4x4 de Pascal, montre le rapport existant entre la moyenne des quatre capteurs et la valeur de ce qui est probablement le courant traversant les deux vannes navette :
Sur le Disco de Laurent, cette valeur est de 50 et elle ne varie pas.
Après échanges entre nous, il s’est avéré que Pascal avait freiné en début et en fin d’essai. Sur son Disco, on passe donc bien de la position « pédale enfoncée « à « pédale relâchée » puis pédale de nouveau enfoncée.
Par contre Laurent n’a jamais freiné mais le courant dans le circuit correspondrait pourtant au cas de figure « pédale complètement enfoncée ». Information en contradiction avec le capteur de position de la pédale de frein (car il me semble qu’il y en a un) d’où l’apparition d’un défaut.
La question est de savoir pourquoi cette situation conduit à l’inscription d’un code défaut renvoyant au capteur de vitesse de la roue AVD dans les registres du calculateur.
Et aussi de comprendre comment les résistances permettant au calculateur d’analyser l’action du conducteur sur les freins se trouvent incorporées dans le circuit alors que la pédale de frein n’est pas sollicitée.
Pour ne pas alourdir davantage un texte un tantinet copieux — et ce d’autant plus que je n’ai pas encore analysé en détail le fonctionnement du bloc ABS — je vais juste esquisser une hypothèse.
Les vannes navettes peuvent être vues comme des portes logiques régissant un circuit à trois voies : elles mettent en communication, soit le réservoir avec le circuit de freinage actionné par le conducteur, soit le réservoir avec la pompe hydraulique lorsqu’elle intervient seule.
S’agissant d’un circuit en X, il y a donc deux vannes.
Au vu de ce qui lui remonte sur l’état logique du circuit hydraulique, le calculateur du 4x4 de Laurent considère que la pompe n’a pas accès au réservoir de liquide de frein. Or si la fonction HDC est appelée, la pompe devra pouvoir prélever le liquide nécessaire au pilotage automatique des freins directement dans le réservoir, ce qui est impossible puisque la vanne pilotant ce circuit est déclarée fermée.
La fonction ne peut pas s’enclencher et c’est précisément ce que remonte l’OBD.
Pourtant, on vient de voir que lorsque la vitesse tourne aux alentours de 4 km/h, ce qui est précisément le cas pour le HDC, les capteurs de vitesse répondent parfaitement. Ce n’est donc pas un problème de capteur de vitesse qui empêche d’actionner cette fonction.
J’avais initialement soupçonné le moteur de la pompe d’une défaillance, mais l’une des tentatives de Laurent a montré que cet organe semblait opérationnel.
Il semblerait donc qu’on tienne un début de cohérence dans l’analyse du défaut ; mais cela nécessite une nouvelle série d’essais et mesures…
À suivre !
: l'est monofonction, le pépère, dirait-on! 
