J’ai travaillé il y a quelque temps sur un capteur de couple, du genre construit autour d’une jauge de contrainte collée sur un arbre en métal. Deux unités sorties de la même ligne, avec la même image firmware, la même nomenclature, rapportaient des chiffres nettement différents sous une charge identique. Ce n’était pas un bug firmware. Ce n’était pas un lot défectueux. C’est simplement ce qui arrive quand on colle une jauge de contrainte sur du métal à la main, ou même avec un procédé bien maîtrisé : la couche d’adhésif, le positionnement exact, la préparation de surface, tout cela varie légèrement d’une unité à l’autre, et cette variation se répercute directement sur l’offset et le gain du capteur.

C’est la partie que les gens n’anticipent pas. Le firmware est identique parce que le code est identique. Mais le code lit une tension, et la relation entre cette tension et le couple physique réel est une propriété de l’assemblage collé qui se trouve devant lui, pas du code. Chacun de ces capteurs avait besoin de son propre offset et de son propre gain, mesurés par rapport à une charge de référence connue et écrits dans l’unité en production, avant que les calculs du firmware n’aient le moindre sens.

C’est là le vrai problème avec la calibration par unité : ce n’est pas une fonctionnalité firmware, c’est une étape de fabrication. L’offset et le gain ne sont pas des constantes qu’on code en dur une fois pour toutes et qu’on expédie. Ce sont des données propres à chaque numéro de série, qui doivent être capturées à un poste de calibration, associées à cette unité précise, et appliquées à l’exécution. Sautez cette étape, et le firmware fait de l’arithmétique précise sur une entrée imprécise, ce qui vous donne simplement une réponse fausse, mais très sûre d’elle.

Voici la partie qui surprend les gens même après qu’ils aient accepté que la calibration est nécessaire : on ne peut pas tout rattraper sur le plancher de production. Une calibration en deux points, offset et gain, au test final corrige une erreur linéaire, et c’est réellement utile, mais cela suppose que le comportement du capteur est linéaire et stable sur la plage qui vous intéresse. Si le comportement réel est non linéaire, ou s’il dérive avec la température d’une manière qui varie d’une unité à l’autre, une calibration rapide en ligne de production ne le détectera pas. Cela doit venir d’un travail de caractérisation fait en laboratoire au préalable : prélever un échantillon d’unités sur toute leur plage de fonctionnement réelle et leur plage de température réelle, comprendre à quel point elles varient réellement, et utiliser cela pour décider ce que votre calibration en production doit mesurer et quelle tolérance est acceptable à l’expédition. Sautez cette étape de laboratoire, et vous devinez ce que « suffisamment bon » veut dire au moment d’écrire les critères d’acceptation du poste de calibration, et vous découvrirez que vous avez mal deviné le jour où un client verra des lectures incohérentes sur le terrain, en dehors de la fenêtre étroite que vous aviez testée.

Ce travail de caractérisation est aussi l’endroit où interviennent les chiffres auxquels la plupart des gens ne pensent jamais. Tout le monde a déjà entendu « 3 sigma » et « 6 sigma » comme synonymes vagues de « plutôt bon » et « vraiment très bon », mais l’écart réel entre les deux est énorme. Un procédé centré sur une tolérance à 3 sigma laisse environ 0,27 % des unités hors spécification, soit environ 2 700 par million. Poussez ce même procédé à 6 sigma, et vous descendez à environ 3,4 défauts par million, une amélioration d’un facteur mille pour ce qui ressemble à un petit changement sur une fiche de spécification. La question de savoir si cet écart compte pour vous dépend entièrement de ce que coûte une unité défectueuse : pour un gadget grand public, 2 700 ppm peut n’être qu’un arrondi dans votre taux de retour ; pour quelque chose intégré dans une boucle de sécurité, c’est une tout autre conversation. Et les calculs en sigma ne tiennent que si la distribution sous-jacente se comporte réellement comme la loi normale qu’ils supposent. Une bonne part de la variabilité réelle des capteurs ressemble effectivement à une loi normale, mais les comptages de défauts, les occurrences de défaillances et certaines sources de bruit se comportent davantage comme un processus de Poisson, avec des queues plus épaisses qu’une courbe normale ne le prédirait. Supposez une loi normale alors que la distribution réelle a des queues plus épaisses, et vous sous-dimensionnerez votre plage de calibration et vos limites d’acceptation, avant d’être surpris par des valeurs aberrantes que vos statistiques disaient impossibles.

Mon opinion honnête sur la solution, et ce n’est pas la réponse de manuel scolaire : j’aime passer au numérique le plus tôt possible dans la chaîne de signal, directement au niveau du capteur si je le peux, parce que chaque étage analogique supplémentaire entre le capteur et le convertisseur est une source de plus de variation d’une unité à l’autre que la calibration doit absorber. Moins d’étages analogiques signifie généralement un problème de calibration plus serré et plus prévisible. Mais je ne prétendrai pas que c’est gratuit. Passer au numérique tôt implique généralement plus de coût par canal, parfois plus de surface de carte, et cela n’élimine pas le besoin de calibration, cela ne fait que resserrer ce que vous calibrez, parce que l’élément de détection lui-même, le collage de la jauge de contrainte dans ce cas-ci, reste un objet physique analogique avec sa propre variabilité qu’aucun positionnement du convertisseur ne corrige. J’ai vu des équipes traiter le « numérique tôt » comme une solution miracle et sauter quand même la caractérisation en laboratoire, et c’est la mauvaise leçon à en tirer.

Si vous construisez quelque chose avec une variabilité par unité intégrée dans l’élément de détection, la voie pratique est la suivante : caractérisez un échantillon réel en laboratoire avant de figer le procédé de production, décidez quelle tolérance est réellement acceptable pour votre application plutôt que de vous rabattre par défaut sur le chiffre sigma qui sonne le plus impressionnant, et concevez le poste de calibration et le stockage firmware pour ces coefficients précis avant de vous retrouver face à une ligne qui ne peut pas expédier de produit parce que personne n’a prévu où vivraient les données de calibration.

Ce qui surprend systématiquement les clients, et c’est la chose à laquelle je reviens à chaque projet de ce genre, c’est à quel point la vraie décision se prend tôt. Ce n’est pas la conception du poste de calibration, et ce n’est pas les calculs de compensation du firmware. C’est l’architecture de détection sur laquelle vous vous engagez dans les toutes premières semaines : quel élément de détection, quelle chaîne analogique, quelle proportion de la chaîne de signal reste analogique avant d’atteindre un convertisseur. Ce choix détermine l’ampleur de la variabilité par unité que vous allez combattre pendant toute la vie du produit, et il fixe le coût de votre poste de calibration, le temps de test par unité, et la part du débit de votre ligne de production que cette seule étape va consommer. Un mauvais choix tôt, et aucun firmware astucieux ni aucun poste de calibration bien mené ne vous en rachètera complètement plus tard.