Les unités qui passent les tests de production mais échouent sur le terrain sont coûteuses. Chaque retour terrain coûte 10 à 100 fois plus que la détection du même défaut sur la ligne. La solution commence par une meilleure couverture de test et une analyse plus fine des données que vous collectez déjà.
Pourquoi les unités passent les tests mais échouent sur le terrain
Trois causes racines expliquent la majorité des retours terrain :
Couverture de test insuffisante. Votre test de production vérifie 80% des fonctionnalités, mais les 20% que vous omettez incluent le mode de défaillance que les clients rencontrent. Si vous ne testez pas le cycle veille/réveil, vous ne détecterez pas le bug firmware qui corrompt l'EEPROM après 1 000 transitions.
Limites de test trop larges. Une unité mesure 4,65V contre une spécification de 4,5V à 5,5V. Elle passe, mais elle dérive vers le bord. Les variations de température sur le terrain la poussent hors plage. Votre test n'a rien détecté car les limites correspondaient à la fiche technique, pas aux conditions réelles.
Conditions environnementales non testées. Les tests de production s'exécutent à 25°C sur un banc. Le produit fonctionne de 0°C à 50°C dans un entrepôt avec des vibrations. Les paramètres qui semblent solides à température ambiante s'effondrent sous contrainte.
Ajouter des tests de marge à vos tests OpenHTF
Le test de marge utilise des limites plus strictes que la spécification du produit. L'idée est simple : si une unité ne peut pas passer avec de la marge, elle a plus de chances d'échouer sur le terrain.
margin_test.py37 lines
import openhtf as htffrom openhtf.util import unitsfrom tofupilot.openhtf import upload@htf.measures( htf.Measurement("output_voltage") .in_range(minimum=4.8, maximum=5.2) .with_units(units.VOLT) .doc("Spéc. 4,5-5,5V. Limites de marge resserrées à 4,8-5,2V."), htf.Measurement("ripple_voltage") .in_range(maximum=20) .with_units(units.MILLIVOLT) .doc("Spéc. autorise 50mV. Limite de marge fixée à 20mV."), htf.Measurement("quiescent_current") .in_range(maximum=0.000008) .with_units(units.AMPERE) .doc("Spéc. autorise 15uA. Limite de marge détecte les unités à fuite."),)def margin_check(test): test.measurements.output_voltage = 5.03 test.measurements.ripple_voltage = 12.4 test.measurements.quiescent_current = 0.0000051def main(): test = htf.Test( margin_check, procedure_id="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", # PCBA Margin Test part_number="PCBA-100", ) test.add_output_callbacks(upload()) test.execute(lambda: "SN-20260312-042")if __name__ == "__main__": main()Utilisez la méthode .doc() pour enregistrer à la fois la limite de spécification et votre limite de marge. Cela rend clair pour quiconque examine les données pourquoi une unité à 4,75V a échoué même si la fiche technique indique que 4,5V est acceptable.
Les limites de marge rejettent des unités qui auraient passé la spécification : attendez-vous à une baisse du rendement au premier passage. C'est le but, mais dimensionnez-la volontairement, car des limites resserrées au-delà de la dispersion de votre process mettent au rebut de bonnes unités à un rythme constant.
Ajouter des phases de stress environnemental
Pour les produits qui fonctionnent sur une plage de températures, ajoutez des phases de stress qui testent aux limites. Vous n'avez pas besoin d'une chambre thermique complète pour chaque unité. Même un bref soak chaud/froid sur une base d'échantillonnage détecte les dérives.
stress_test.py59 lines
import openhtf as htffrom openhtf.util import unitsfrom tofupilot.openhtf import upload@htf.measures( htf.Measurement("voltage_ambient") .in_range(minimum=4.8, maximum=5.2) .with_units(units.VOLT),)def ambient_check(test): # Mesure à température ambiante comme référence test.measurements.voltage_ambient = 5.01@htf.measures( htf.Measurement("voltage_hot") .in_range(minimum=4.7, maximum=5.3) .with_units(units.VOLT), htf.Measurement("voltage_drift_hot") .in_range(maximum=100) .with_units(units.MILLIVOLT) .doc("Delta entre les lectures à 25°C et 50°C"),)def hot_soak_check(test): # Mesure après soak thermique à la limite supérieure de fonctionnement test.measurements.voltage_hot = 5.08 test.measurements.voltage_drift_hot = 70@htf.measures( htf.Measurement("voltage_cold") .in_range(minimum=4.7, maximum=5.3) .with_units(units.VOLT), htf.Measurement("voltage_drift_cold") .in_range(maximum=100) .with_units(units.MILLIVOLT) .doc("Delta entre les lectures à 25°C et 0°C"),)def cold_soak_check(test): # Mesure après soak thermique à la limite inférieure de fonctionnement test.measurements.voltage_cold = 4.92 test.measurements.voltage_drift_cold = 90def main(): test = htf.Test( ambient_check, hot_soak_check, cold_soak_check, procedure_id="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", # PCBA Thermal Stress Test part_number="PCBA-100", ) test.add_output_callbacks(upload()) test.execute(lambda: "SN-20260312-042")if __name__ == "__main__": main()Enregistrer la dérive comme mesure séparée est essentiel. Une unité peut passer les vérifications absolues à chaud et à froid tout en montrant 95mV de dérive, ce qui signale un composant proche de sa limite thermique.
Corréler les défaillances terrain avec les données de production
Quand une unité revient du terrain, recherchez-la par numéro de série. L'historique de l'unité affiche chaque exécution de test, y compris toutes les mesures enregistrées pendant la production.
Voici la procédure :
- Obtenez le numéro de série de l'unité retournée.
- Recherchez par numéro de série pour afficher l'historique complet des tests de l'unité.
- Vérifiez les mesures correspondant au mode de défaillance. Si la défaillance terrain est « perte de puissance intermittente », examinez les mesures de tension et de courant en production.
- Comparez avec les unités fonctionnelles. L'unité retournée était-elle proche de la limite ? Présentait-elle une dérive plus élevée que les unités qui ont survécu ?
Cette comparaison vous indique si vos limites doivent être resserrées ou si votre couverture de test présente des lacunes.
Une mise en garde : les unités retournées sont un échantillon biaisé. Vous voyez celles qui ont échoué, pas celles qui se situaient dans la même zone et ont survécu. Avant de resserrer une limite, vérifiez quelle part de votre population conforme se trouve dans la même bande, sinon vous mettrez au rebut bien plus d'unités que vous n'en sauverez.
Identifier les unités marginales avec l'analytique des mesures
L'analytique des mesures vous montre la distribution de chaque mesure sur l'ensemble des unités. C'est là que vous détectez les problèmes systématiques avant qu'ils ne deviennent des retours terrain.
Les histogrammes de mesures révèlent les distributions bimodales. Si votre mesure de tension montre deux clusters au lieu d'une courbe normale, vous avez probablement un problème d'approvisionnement en composants ou une variation de processus. Les unités du cluster inférieur sont vos candidates au retour terrain.
Les valeurs Cpk vous indiquent à quel point votre processus est centré dans les limites. Un Cpk inférieur à 1,33 signifie que la variation de votre processus est trop large par rapport à vos limites de test. Même si chaque unité passe aujourd'hui, la variation normale poussera certaines unités hors spécification sur le terrain.
Les cartes de contrôle montrent les tendances de mesure dans le temps. Une dérive progressive d'une mesure entre les lots de production signale un changement de processus. Détecter la dérive tôt permet d'investiguer avant que des unités marginales ne soient expédiées.
Resserrer les limites sur la base des données terrain
Une fois que vous avez corrélé les retours terrain avec les mesures de production, mettez à jour vos limites de test. La démarche est simple :
| Situation | Action |
|---|---|
| Unités retournées groupées près de la limite supérieure | Abaisser la limite de marge supérieure |
| Unités retournées montrant une forte dérive thermique | Ajouter ou resserrer la limite de mesure de dérive |
| Mode de défaillance non couvert par aucune mesure | Ajouter une nouvelle phase de test pour ce paramètre |
| Retours corrélés à un lot de production spécifique | Investiguer le changement de processus pendant cette période |
Ne devinez pas les nouvelles limites. Utilisez la distribution des mesures de votre population conforme pour définir des limites qui excluent la queue où les défaillances se concentrent.
Quand vous changez une limite, enregistrez quelle version de procédure a produit chaque résultat. Sinon les résultats d'avant et d'après le changement se fondent silencieusement en une seule distribution et votre historique de rendement cesse d'être comparable.
Ajouter de la couverture pour les modes de défaillance manquants
Les retours terrain révèlent souvent des modes de défaillance que votre test ne couvre pas du tout. Quand cela arrive, ajoutez une nouvelle phase à votre test OpenHTF.
added_coverage.py42 lines
import openhtf as htffrom openhtf.util import unitsfrom tofupilot.openhtf import upload@htf.measures( htf.Measurement("sleep_wake_cycles_passed") .in_range(minimum=100) .doc("Ajouté après des retours terrain montrant une corruption EEPROM après des veilles/réveils répétés."), htf.Measurement("eeprom_checksum_valid") .equals(True),)def sleep_wake_stress(test): # Exécuter 100 cycles veille/réveil et vérifier l'intégrité de l'EEPROM cycles_passed = 100 checksum_ok = True test.measurements.sleep_wake_cycles_passed = cycles_passed test.measurements.eeprom_checksum_valid = checksum_ok@htf.measures( htf.Measurement("output_voltage") .in_range(minimum=4.8, maximum=5.2) .with_units(units.VOLT),)def functional_check(test): test.measurements.output_voltage = 5.02def main(): test = htf.Test( sleep_wake_stress, functional_check, procedure_id="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", # PCBA Functional Test v2 part_number="PCBA-100", ) test.add_output_callbacks(upload()) test.execute(lambda: "SN-20260312-099")if __name__ == "__main__": main()Documentez pourquoi vous avez ajouté la phase avec .doc(). Dans six mois, quelqu'un demandera pourquoi vous exécutez 100 cycles veille/réveil sur chaque unité. La réponse est là, dans les métadonnées de la mesure.
Pesez le temps de cycle que cela coûte. Une phase de stress de 100 cycles sur chaque unité se justifie quand le mode de défaillance est coûteux et fréquent ; sur une ligne à fort volume, mieux vaut parfois un audit par échantillonnage qu'un contrôle sur chaque unité.
Construire une boucle de rétroaction
Réduire les retours terrain n'est pas une correction ponctuelle. C'est une boucle continue :
- Expédiez les unités avec votre couverture de test et vos limites actuelles.
- Suivez les retours par numéro de série.
- Corrélez les données de retour avec les mesures de production.
- Resserrez les limites ou ajoutez des phases de test en fonction de vos découvertes.
- Surveillez le Cpk et le rendement au premier passage pour confirmer que les changements réduisent les retours sans sur-rejeter les bonnes unités.
L'étape 5 est celle que les équipes sautent. Une limite resserrée qui divise par deux les retours terrain tout en mettant au rebut 3% de bonnes unités en plus peut valoir le coup ou non, et vous ne pouvez pas trancher sans suivre les deux chiffres ensemble.
