Chaque re-test consomme du temps de station, de l'attention opérateur et de la marge. La plupart des équipes ne le mesurent pas car le re-test semble faire partie du processus. Ce n'est pas le cas. C'est de la reprise qui se cumule silencieusement.
Ce guide détaille ce que le re-test coûte réellement, d'où il provient, et comment utiliser l'historique des unités intégré à TofuPilot pour le suivre et le réduire.
Ce que le re-test coûte réellement
Un seul re-test ne semble pas cher. Multipliez-le par des milliers d'unités par mois et les chiffres deviennent inconfortables.
| Catégorie de coût | Estimation par re-test | À 10 % de taux de re-test (10k unités/mois) |
|---|---|---|
| Temps de station (durée du test) | 0,50-2,00 $ | 500-2 000 $/mois |
| Manipulation opérateur | 0,30-1,00 $ | 300-1 000 $/mois |
| Analyse de défaillance (si déclenchée) | 5-50 $ | 5 000-50 000 $/mois |
| Retard d'expédition (coût d'opportunité) | Variable | Souvent le coût le plus élevé |
| Capacité station perdue | 1 créneau par re-test | 1 000 créneaux/mois indisponibles |
Le coût direct du re-test est facile à sous-estimer. Le coût indirect (la capacité que vous ne pouvez pas utiliser pour de nouvelles unités) est généralement pire. Une station de test fonctionnant avec un taux de re-test de 10 % perd effectivement 10 % de son débit.
Causes courantes de re-test excessif
Le re-test n'est pas toujours un problème de qualité produit. C'est souvent un problème de système de test.
| Cause racine | Symptôme | Correction |
|---|---|---|
| Infrastructure de test instable | La même unité passe au nouvel essai sans reprise | Stabiliser les montages, resserrer les connexions, ajouter du temps de stabilisation |
| Limites trop serrées | Les unités marginales échouent, passent au re-test | Élargir les limites en utilisant les données Cpk de production |
| Sensibilité environnementale | Les échecs se regroupent au début de l'équipe ou lors de changements de température | Ajouter un conditionnement environnemental ou des bandes de garde |
| Erreur opérateur | Les échecs sont corrélés à des opérateurs spécifiques | Améliorer les montages, réduire les étapes manuelles |
| Défaut intermittent du DUT | L'unité échoue aléatoirement sur plusieurs re-tests | Rechercher la cause racine au niveau de la carte, vérifier les joints de soudure |
| Bugs logiciels de test | Des phases spécifiques échouent de manière incohérente | Revoir les timeout de phase, la communication avec les instruments |
Si votre taux de re-test est supérieur à 5 %, commencez par le système de test avant d'incriminer le produit.
Configurer les tests pour le suivi du re-test
TofuPilot suit les re-tests en associant les exécutions au même numéro de série et à la même procédure. Pour que cela fonctionne, votre script de test doit identifier correctement les unités.
import openhtf as htf
from tofupilot.openhtf import TofuPilot
def main():
test = htf.Test(
check_power_rails,
check_communication,
measure_current_draw,
station_id="FCT-STATION-01",
)
with TofuPilot(test):
test.execute(test_start=lambda: "SN-2024-00421")
if __name__ == "__main__":
main()Deux éléments comptent pour le suivi du re-test :
procedure_ididentifie la procédure de test. Utilisez un nom stable qui ne change pas entre les re-tests.dut_id(retourné partest_start) identifie l'unité physique. Utilisez le vrai numéro de série, pas un ID généré.
Lorsque le même dut_id apparaît plusieurs fois pour le même procedure_id, TofuPilot sait qu'il s'agit d'un re-test.
Suivre les re-tests dans TofuPilot
TofuPilot suit chaque exécution par numéro de série d'unité. Vous n'avez pas besoin de créer des scripts d'analyse ni d'interroger l'API pour calculer les taux de re-test.
Page d'historique de l'unité. Ouvrez la page d'historique de n'importe quelle unité pour voir toutes les tentatives de test, classées chronologiquement. Une unité testée trois fois avant de passer affiche les trois exécutions avec leurs résultats. Cela vous indique immédiatement si une unité a nécessité un re-test et combien de tentatives ont été nécessaires.
Onglet Analytique. Utilisez l'onglet Analytique pour surveiller les tendances de rendement au premier passage (FPY). Le FPY est inversement corrélé au taux de re-test : si votre FPY est de 92 %, environ 8 % des unités ont nécessité au moins un re-test. Suivre le FPY dans le temps montre si votre problème de re-test s'améliore ou s'aggrave.
Filtrage par procédure et station. Vous pouvez filtrer les analyses par procédure et station pour isoler les patterns de re-test. Si une station a un FPY nettement inférieur aux autres exécutant la même procédure, vous avez trouvé un problème d'infrastructure de test, pas un problème produit.
Taux de re-test vs. impact sur les coûts
Voici comment le taux de re-test se traduit en impact réel sur la production à différentes échelles.
| Volume mensuel | Taux de re-test | Re-tests/mois | Coût estimé/mois (à 2 $/re-test) | Capacité station perdue |
|---|---|---|---|---|
| 1 000 | 2 % | 20 | 40 $ | Négligeable |
| 1 000 | 10 % | 100 | 200 $ | ~2 heures |
| 10 000 | 2 % | 200 | 400 $ | ~1 jour |
| 10 000 | 10 % | 1 000 | 2 000 $ | ~5 jours |
| 100 000 | 5 % | 5 000 | 10 000 $ | ~25 jours |
| 100 000 | 10 % | 10 000 | 20 000 $ | ~50 jours |
À haut volume, même une petite amélioration du taux de re-test libère une capacité station significative. Passer de 10 % à 5 % à 100k unités/mois récupère 25 jours de temps de station.
Comment réduire le taux de re-test
Réduire le taux de re-test a presque toujours un meilleur ROI que l'achat de stations supplémentaires.
1. Stabiliser l'environnement de test. La plupart des re-tests en début de maturité proviennent du système de test, pas du produit. Vérifiez la résistance de contact du montage, le préchauffage des instruments, l'intégrité des câbles et les timeout logiciels. Si une unité passe au nouvel essai sans reprise, le problème vient de votre test, pas du DUT.
2. Utiliser le Cpk pour définir les limites. Les limites dérivées des fiches techniques sont souvent plus serrées que nécessaire. Récupérez les distributions de mesures depuis les analyses de TofuPilot, calculez le Cpk et élargissez les limites là où vous avez de la marge. Un Cpk de 1,33 ou plus signifie que le processus est bien dans les spécifications.
3. Ajouter des bandes marginales. Configurez des limites marginales dans votre test pour signaler les unités qui passent mais sont proches de la frontière. Ce sont vos futurs re-tests. Les détecter tôt vous permet d'investiguer avant que la limite ne devienne un problème de rendement.
4. Analyser les causes racines des principales défaillances. Utilisez les analyses de mesure de TofuPilot pour identifier quelles phases échouent le plus souvent. Concentrez-vous sur les 3 premières. L'analyse de Pareto révèle presque toujours qu'un petit nombre de modes de défaillance génère la majorité des re-tests.
5. Suivre le taux de re-test comme un KPI. Faites du FPY (ou de son inverse, le taux de re-test) une métrique hebdomadaire. Consultez-le dans l'onglet Analytique de TofuPilot. Les équipes qui suivent le taux de re-test le réduisent systématiquement. Celles qui ne le font pas, non.