Réduire les retours terrain

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à. TofuPilot vous donne les outils pour repérer les unités marginales avant leur expédition.

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.

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


@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.0000051


def main():
    test = htf.Test(margin_check)
    with TofuPilot(test, procedure_name="PCBA Margin Test"):
        test.execute(test_start=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.

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.

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


@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 = 90


def main():
    test = htf.Test(ambient_check, hot_soak_check, cold_soak_check)
    with TofuPilot(test, procedure_name="PCBA Thermal Stress Test"):
        test.execute(test_start=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 dans TofuPilot. 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 :

1. Obtenez le numéro de série de l'unité retournée.
2. Recherchez dans TofuPilot pour afficher l'historique complet des tests de l'unité.
3. 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.
4. 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.

Identifier les unités marginales avec l'analytique des mesures

L'analytique des mesures de TofuPilot 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 :

Ne devinez pas les nouvelles limites. Utilisez les données de distribution des mesures de TofuPilot provenant de votre population terrain fonctionnelle pour définir des limites qui excluent la queue où les défaillances se concentrent.

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.

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


@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.02


def main():
    test = htf.Test(sleep_wake_stress, functional_check)
    with TofuPilot(test, procedure_name="PCBA Functional Test v2"):
        test.execute(test_start=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 et visible dans la vue détaillée de l'exécution dans TofuPilot.

Construire une boucle de rétroaction

Réduire les retours terrain n'est pas une correction ponctuelle. C'est une boucle continue :

1. Expédiez les unités avec votre couverture de test et vos limites actuelles.
2. Suivez les retours par numéro de série.
3. Corrélez les données de retour avec les mesures de production dans TofuPilot.
4. Resserrez les limites ou ajoutez des phases de test en fonction de vos découvertes.
5. Surveillez le Cpk et le FPY dans TofuPilot pour confirmer que les changements réduisent les retours sans sur-rejeter les bonnes unités.

Chaque itération rend votre suite de tests plus efficace. L'analytique des mesures et l'historique des unités de TofuPilot vous donnent les données pour que chaque décision soit fondée sur des preuves plutôt que sur des suppositions.