Perso, je considère que dans 99% des cas tordus, le problème technique est loin d'être le problème dominant : il faut essayer de se glisser dans la peau du gus qui a pondu le truc, sans oublier qu'il a pissé du code en fonction de sa propre expérience, elle aussi limitée...

En d'autres termes, rien n'indique que quelqu'un, quelque part, même parmi les concepteurs eux-mêmes, n'ait la méthode et encore moins la réponse.
Le cas d'école est une connexion endommagée ou corrodée qui va générer des parasites interprétés par l'électronique comme une banale donnée d'entrée. Si aucune analyse du paramètre n'est effectuée avant transfert au calculateur — ce qui est souvent le cas par souci d'économie car cela charge le µ-contrôleur et les mémoires, sans parler des circuits de filtrage, toujours plus ou moins encombrants et coûteux — son exploitation peut donner lieu à des interprétations fantaisistes et à des réactions totalement incohérentes.
J'ai récemment eu le cas sur un modem : le niveau de marge de bruit indiqué juste avant le décrochage n'avait absolument aucun sens physique, ce qui mettait le système en vrac par dépassement de ses capacités de traitement (run time error comme dirait l'autre).
En en discutant avec les techniciens, il s'est avéré que l'armoire connectique la plus proche encaissait les vibrations dues au trafic automobile, lesquelles provoquaient, sur une connexion légèrement corrodée, des parasites, traduits par le convertisseur analogique/numérique en une série de signaux haut, lesquels étaient alors interprétés par l'électronique numérique comme une valeur très élevée du paramètre.
Dans les nombreux sujets restés en suspend et assimilable à ce type de problème, il y avait celui-là.
Il aurait été intéressant de savoir quelle était l'origine des valeurs aberrantes délivrées par le système, même si aucun défaut de fonctionnement n'était constaté par ailleurs.
Pour le cas du Hilux, la seule chose qui me semblerait logique de faire c'est d'enregistrer en continu les signaux délivrés par les capteurs de freinage et de transmission et voir si, à un moment, le signal décroche et si cela provoque un défaut.
Le problème est que c'est long et compliqué et qu'il faut disposer d'un matériel adapté.
Un cas assez tordu qui me vient en tête est celui d'un débitmètre dont une partie du circuit électronique était soumise à la condensation (point de rosée) à cause d'un minuscule défaut dans le collage du boîtier complété par un point faible dans le vernis d'isolement des composants électroniques.
Je l'ai d'abord vérifié avec un anémomètre à fil chaud que j'utilise pour mesurer et régler les débits d'air sur, par exemple, des ventilations mécaniques.
Les informations délivrées étaient justes, très justes même.
Puis, saisi d'un doute, j'ai injecté de l'air chaud et humide alors que le bazar avait séjourné plusieurs heures au frigo et là, bingo.
Les soucis avaient généralement lieu à l'automne lors de brusques réchauffements de la température...
Le problème de ces beaux systèmes est qu'ils viennent quasiment tous de l'univers militaire mais ont été « dégradés » lors de leur passage à la vie civile : les redondances et la qualité des circuits ont été largement revues à la baisse pour des questions de coût.
Ce qui n'empêche pas, même dans des univers très exigeants, des boulettes magistrales comme celle qui a provoqué la perte d'une fusée Ariane il y a quelques années : de mémoire, les mecs ont oublié de vérifier que le calculateur originel était suffisamment rapide pour encaisser le surcroit de vitesse — et donc d'informations — qui caractérisait la nouvelle génération de lanceurs dont l'une des composantes de trajectoire était plus exigeante en calcul.
La suite, on la connaît : le calculateur a jeté l'éponge car il n'était pas assez puissant...
Les systèmes électroniques équipant les véhicules actuels ne sont pas si performants qu'on ne le croit, pas plus que leur code, leurs redondances et leurs contrôles en fonctionnement, ce qui relativise la nécessité d'en connaître les arcanes pour intervenir dessus.
Une démarche intéressante est celle des « valises constructeur » qui s'efforcent de capitaliser les expériences des équipes de maintenance, notamment en fixant des bornes et des évolutions dynamiques types pour les principaux paramètres. Comme l'avait — toujours de mémoire — indiqué LØLØ, ces valises sont en réalité des oscilloscopes dont les valeurs relevées sont interprétées par un système expert, ce qui permet de gagner du temps dans la reconstitution des scenarii et arbres des causes de pannes.
De mon point de vue, le seul organe quasiment impossible à réparer est le calculateur lui-même car sans doc — ce qui est aujourd'hui la règle — explicitant notamment les références des composants et l'architecture générale, on ne peut quasiment rien faire, sauf à s'être spécialisé dans un modèle spécifique après en avoir tripatouillé des dizaines des années durant, comme l'avait fait le regretté Volta.