Réduire les coûts de retest

Le retest consomme 10 à 30 % de la capacité des stations de test sur une ligne de production électronique typique. Chaque cycle de retest brûle du temps station, de l'attention opérateur et de l'usure de fixture, le tout sans produire une seule nouvelle unité. Réduire votre taux de retest est l'un des moyens les plus rapides d'augmenter le débit sans acheter d'équipement supplémentaire.

Pourquoi le retest coûte si cher

Le coût direct d'un retest semble faible : relancer le test, peut-être qu'il passe. Mais les coûts cachés s'accumulent vite.

Le débit des stations baisse. Une station avec 15 % de taux de retest perd effectivement 15 % de sa capacité. Pour une station traitant 500 unités par équipe, cela représente 75 créneaux gaspillés sur des unités déjà testées une fois.

La retouche crée un risque qualité. Chaque cycle de retouche (dessouder, remplacer, ressouder) introduit du stress thermique, de l'endommagement de pads et du risque de manipulation. Les unités retouchées échouent à des taux plus élevés en aval.

Les données deviennent bruitées. Quand les opérateurs retestent des unités sans suivre les numéros de série, vos métriques de rendement deviennent peu fiables. Impossible de savoir si le FPY est à 85 % ou 95 % car premières tentatives et retests sont mélangés.

Causes racines d'un retest excessif

Avant de pouvoir corriger le retest, vous devez savoir pourquoi il se produit. Les causes se classent généralement en quatre catégories.

Limites de test lâches ou manquantes

Les tests sans limites appropriées ne peuvent pas distinguer les vrais échecs des passages marginaux. Si un rail de tension est spécifié à 3,3 V +/- 5 %, mais que votre test n'a pas de limites, les opérateurs jugent à l'œil ce qui « a l'air correct ».

Fixtures de test instables

La résistance de contact sur les pogo pins, l'usure des repères d'alignement et les connexions de câbles intermittentes causent des échecs aléatoires. L'unité est bonne. Le fixture ne l'est pas. Les opérateurs le savent, alors ils retestent.

Relances initiées par l'opérateur

Sans critères pass/fail clairs, les opérateurs développent des habitudes : « si ça échoue sur la tension, relance simplement ». Cela masque à la fois les problèmes de fixture et les vrais défauts.

Sensibilité environnementale

La température, l'humidité et les variations d'alimentation peuvent pousser les mesures au-delà des limites. Si votre test donne des résultats différents à 8 h et à 14 h, vous avez un problème d'environnement.

Patterns OpenHTF qui réduisent le retest

Un bon code de test prévient les retests inutiles en détectant les problèmes de fixture tôt et en définissant des limites appropriées.

Valider le fixture avant de tester le DUT

Ajoutez une phase de validation du fixture au début de votre séquence de test. Si le fixture échoue, le run s'arrête avant d'enregistrer un faux échec contre l'unité.

import openhtf as htf
from openhtf.util import units
from tofupilot.openhtf import TofuPilot

@htf.measures(
    htf.Measurement("fixture_contact_resistance")
    .with_units(units.OHM)
    .in_range(maximum=0.5),
    htf.Measurement("fixture_supply_voltage")
    .with_units(units.VOLT)
    .in_range(minimum=11.8, maximum=12.2),
)
def validate_fixture(test):
    # Vérifier le contact des pogo pins et l'alimentation avant le test du DUT
    test.measurements.fixture_contact_resistance = 0.12
    test.measurements.fixture_supply_voltage = 12.01

@htf.measures(
    htf.Measurement("output_voltage")
    .with_units(units.VOLT)
    .in_range(minimum=3.135, maximum=3.465),
    htf.Measurement("ripple_mV")
    .in_range(maximum=50),
)
def test_power_output(test):
    test.measurements.output_voltage = 3.29
    test.measurements.ripple_mV = 18

@htf.measures(
    htf.Measurement("signal_integrity_dB")
    .in_range(minimum=-3.0, maximum=3.0),
)
def test_signal_path(test):
    test.measurements.signal_integrity_dB = 0.4

def main():
    test = htf.Test(validate_fixture, test_power_output, test_signal_path)
    with TofuPilot(test):
        test.execute(test_start=lambda: "SN-2026-01105")

if __name__ == "__main__":
    main()

La phase validate_fixture s'exécute en premier. Si la résistance de contact est trop élevée ou la tension d'alimentation hors plage, le test échoue immédiatement. L'échec est attribué au fixture, pas au DUT, et aucun faux échec n'est enregistré contre le numéro de série.

Définir les limites de mesure à partir de la capabilité du processus

Ne devinez pas les limites. Définissez-les à partir de vos données de Cpk. Si votre processus produit une tension de sortie avec une moyenne de 3,30 V et un écart-type de 0,03 V, votre plage à 3 sigma est de 3,21 V à 3,39 V.

Vos limites de test doivent être plus larges que 3 sigma (pour éviter les faux échecs) mais dans les spécifications (pour détecter les vrais défauts). Un bon point de départ est les limites de spécification de la datasheet du composant.

import openhtf as htf
from openhtf.util import units

# Limites dérivées d'une étude Cpk : spécification 3,0-3,6 V, sigma du processus 0,03 V
# Limites de test définies aux bornes de la spécification pour détecter les vrais défauts
@htf.measures(
    htf.Measurement("regulated_output")
    .with_units(units.VOLT)
    .in_range(minimum=3.0, maximum=3.6),
    htf.Measurement("load_regulation_pct")
    .in_range(minimum=-2.0, maximum=2.0),
    htf.Measurement("thermal_shutdown_temp")
    .with_units(units.DEGREE_CELSIUS)
    .in_range(minimum=145, maximum=155),
)
def test_regulator(test):
    test.measurements.regulated_output = 3.31
    test.measurements.load_regulation_pct = 0.8
    test.measurements.thermal_shutdown_temp = 150

Comment TofuPilot suit les taux de retest

TofuPilot relie chaque run de test à un numéro de série, et sait donc quand une unité est testée pour la deuxième, troisième ou dixième fois.

Le tableau de bord vous montre :

• Taux de retest par station. Si une station a 3 fois le taux de retest d'une autre exécutant le même test, la station a besoin de maintenance.
• Historique unitaire. Pour tout numéro de série, consultez chaque tentative de test en séquence. Repérez les patterns comme « échoue une fois, passe au retest immédiat » (problème de fixture) versus « échoue de manière répétée sur la même mesure » (vrai défaut).
• Écart FPY vs. rendement de sortie. Un grand écart entre le FPY et le rendement de sortie signifie que vous comptez fortement sur le retest pour atteindre votre objectif de rendement. Cet écart est votre coût de retest, rendu visible.
• Pareto des défaillances. Consultez quelles phases de test causent le plus d'échecs. Si une phase représente 60 % des retests, corriger cette phase offre le meilleur retour.

Guide pratique de réduction

1. Mesurez votre taux de retest actuel. Consultez le tableau de bord FPY de TofuPilot. L'écart entre FPY et rendement de sortie est votre coût de retest.
2. Identifiez la phase d'échec principale. Utilisez le diagramme de Pareto des défaillances. Concentrez-vous d'abord sur le contributeur le plus important.
3. Classifiez les échecs. Pour la phase principale, vérifiez si les échecs sont liés au fixture (passage au retest immédiat) ou au DUT (échec constant).
4. Corrigez les fixtures d'abord. Les échecs de fixture sont les moins coûteux à corriger. Remplacez les pogo pins usés, resserrez l'alignement et ajoutez des phases de validation du fixture.
5. Révisez les limites de test. Utilisez les histogrammes de mesure et les graphiques de Cpk dans TofuPilot pour vérifier si les limites correspondent à la capabilité du processus. Resserrez les limites trop lâches. Élargissez les limites quand le Cpk montre que le processus ne peut pas les atteindre.
6. Répétez mensuellement. Le taux de retest remonte à mesure que les fixtures s'usent et que les conditions de processus changent. Faites-en une revue récurrente.