Analyse des causes racines pour les défaillances de test hardware
Un test échoue. La question n'est jamais simplement « qu'est-ce qui a échoué » mais « pourquoi cela a-t-il échoué, et cela va-t-il se reproduire ? » TofuPilot stocke chaque mesure de chaque exécution, afin que vous puissiez remonter aux sources des défaillances au lieu de deviner.
Le problème de l'analyse des causes racines en hardware
Les bugs logiciels laissent des traces de pile. Les défaillances hardware laissent des mesures. La différence : une trace de pile pointe vers une ligne de code, mais une lecture de tension hors spécification peut signifier une soudure défectueuse, une alimentation qui dérive, un montage de test défaillant, ou un problème de lot de composants.
L'analyse des causes racines en hardware signifie corréler les données de test sur plusieurs dimensions : le temps, la station, le lot de composants, l'opérateur et les conditions environnementales.
Étape 1 : Identifier le pattern de défaillance
Commencez par filtrer les exécutions en échec dans le tableau de bord TofuPilot.
| Filtre | Objectif |
|---|---|
| Procédure | Se concentrer sur le test spécifique |
| Plage de dates | Trouver quand les défaillances ont commencé |
| Station | Vérifier si les défaillances se concentrent sur une station |
| Statut : Échoué | Voir uniquement les exécutions en échec |
Cherchez des regroupements. Si les défaillances se concentrent sur une station, une équipe ou une plage de dates, vous avez déjà restreint la recherche.
Étape 2 : Comparer les exécutions en échec et réussies
TofuPilot permet de comparer des exécutions côte à côte. Sélectionnez une exécution en échec et une exécution réussie de la même procédure, puis comparez leurs mesures.
Exécution réussie (UNIT-3021) : Exécution en échec (UNIT-3045) :
┌─────────────────────────┐ ┌─────────────────────────┐
│ vcc_3v3: 3.30 V ✓ │ │ vcc_3v3: 3.28 V ✓ │
│ vcc_1v8: 1.81 V ✓ │ │ vcc_1v8: 1.76 V ✗ │
│ clk_freq: 24.00 MHz ✓ │ │ clk_freq: 23.95 MHz ✓ │
│ current: 45 mA ✓ │ │ current: 62 mA ✗ │
└─────────────────────────┘ └─────────────────────────┘
Dans cet exemple, le rail 1,8 V est bas et la consommation de courant est élevée. Ces deux symptômes ensemble orientent vers un court-circuit ou un court-circuit partiel sur le rail 1,8 V.
Étape 3 : Vérifier la tendance de la mesure
Une seule comparaison vous montre le « quoi ». La tendance vous montre le « quand ». Ouvrez la chronologie de la mesure pour vcc_1v8 sur toutes les exécutions.
Si la lecture du 1,8 V était stable à 1,81 V pendant des semaines et a commencé à baisser le 3 mars, quelque chose a changé le 3 mars. Vérifiez :
- Un nouveau lot de composants a-t-il été introduit ?
- Le montage de test a-t-il été révisé ?
- L'alimentation de la station a-t-elle été recalibrée ?
Étape 4 : Corréler avec les lots de composants
TofuPilot suit les métadonnées des unités, y compris les informations sur les composants. Si les défaillances se regroupent autour d'unités fabriquées avec un lot de composants spécifique, vous avez trouvé un problème de qualité fournisseur.
from tofupilot import TofuPilotClient
client = TofuPilotClient()
# Récupérer toutes les exécutions en échec pour une procédure spécifique
runs = client.get_runs(
procedure_id="BOARD-FUNCTIONAL",
run_passed=False,
limit=100,
)
# Vérifier si les défaillances sont corrélées aux lots de composants
lot_counts = {}
for run in runs:
lot = run.get("unit_under_test", {}).get("batch", "unknown")
lot_counts[lot] = lot_counts.get(lot, 0) + 1
for lot, count in sorted(lot_counts.items(), key=lambda x: -x[1]):
print(f"Lot {lot} : {count} défaillances")Étape 5 : Isoler la variable
L'analyse des causes racines est un processus d'élimination. TofuPilot vous aide à maintenir les variables constantes tout en changeant une seule à la fois :
| Variable | Comment la contrôler |
|---|---|
| Station | Filtrer par identifiant de station |
| Opérateur | Filtrer par équipe/horaire |
| Lot de composants | Filtrer par lot/batch |
| Montage | Vérifier les métadonnées de la station |
| Environnement | Comparer avec les journaux de température |
Quand vous pouvez reproduire la défaillance en contrôlant une seule variable (par ex., « toutes les défaillances proviennent de la station 3 »), vous avez isolé la cause racine.
Patterns de causes racines courants
Défaillances spécifiques à une station
Les défaillances se concentrent sur une station de test. Généralement causées par :
- Pogo pins ou sondes de test usés
- Connexions de câbles lâches
- Dérive de calibration des instruments de la station
Défaillances spécifiques à un lot
Les défaillances se concentrent sur des unités d'un lot de composants spécifique. Généralement causées par :
- Échappement qualité fournisseur
- Décalage des paramètres du composant
- Mauvaise révision du composant
Défaillances corrélées au temps
Les défaillances commencent à une date spécifique et continuent. Généralement causées par :
- Changement de processus (profil de soudure, version firmware)
- Changement environnemental (humidité, température)
- Usure du montage atteignant un seuil
Défaillances intermittentes
Les défaillances apparaissent aléatoirement entre stations et lots. Généralement causées par :
- Conception marginale (valeurs proches des limites)
- Bruit de mesure du test
- Sensibilité environnementale
De la cause racine à l'action corrective
Une fois la cause racine identifiée, les données de TofuPilot vous aident à vérifier le correctif. Exécutez les mêmes tests après l'action corrective et comparez les distributions de mesures avant et après. Si les lectures du rail 1,8 V reviennent à 1,81 V et que la consommation de courant redevient normale, votre correctif fonctionne.
Suivez l'efficacité de l'action corrective dans le temps. Les vues de tendance de TofuPilot montrent si le correctif tient ou si le problème réapparaît.