Améliorer le rendement premier passage

Un faible rendement au premier passage coûte plus que la mise au rebut. Cela signifie des cycles de retest, du temps de débogage et des expéditions en retard. Ce guide couvre des stratégies pratiques pour identifier ce qui échoue, pourquoi cela échoue, et comment y remédier en utilisant les données de production de TofuPilot.

Prérequis

• Un compte TofuPilot avec des exécutions de test déjà en cours
• Des scripts de test OpenHTF avec des mesures et des limites définies
• Au moins quelques centaines d'exécutions pour une analyse significative

Étape 1 : Comprendre où vous perdez du rendement

Avant de corriger quoi que ce soit, vous devez savoir ce qui échoue réellement. La plupart des équipes ont une intuition sur leurs pires tests, mais les données racontent généralement une histoire différente.

L'onglet Analytics de TofuPilot affiche votre FPY dans le temps, ventilé par procédure. Commencez par là. Recherchez :

• Les procédures avec un FPY inférieur à 95 % : ce sont vos cibles prioritaires
• Les baisses de FPY qui corrèlent avec une date : généralement un changement de processus, un nouveau lot de composants ou une mise à jour du script de test
• Les stations avec un FPY plus bas que les autres exécutant la même procédure : pointe vers des problèmes de montage ou de calibration

Le diagramme de Pareto dans l'onglet Analytics classe les modes de défaillance par fréquence. C'est là qu'il faut concentrer vos efforts. Corriger les deux ou trois premiers modes de défaillance récupère généralement la majeure partie du rendement perdu.

Étape 2 : Effectuer une analyse des causes racines sur les principales défaillances

Une fois que vous avez identifié vos mesures les moins performantes, explorez les données en détail. Il existe trois catégories courantes de causes racines.

Problèmes de limites de test

Des limites trop serrées provoquent de faux échecs. Des limites trop lâches laissent passer des unités défectueuses. Les deux nuisent au rendement, juste de manière différente.

Les cartes de contrôle de TofuPilot montrent les tendances des mesures avec les limites 3-sigma automatiquement. Utilisez la vue Cpk pour identifier les mesures avec une faible capabilité de processus. Un Cpk inférieur à 1,0 signifie que la dispersion de votre processus est plus large que vos limites de spécification, et vous continuerez à faire échouer des unités tant que vous n'améliorerez pas le processus ou les limites.

Problèmes de processus

Si la distribution d'une mesure se décale dans le temps ou entre les stations, c'est un problème de processus, pas de limites. Causes courantes :

• Variation de lot de composants (surtout les passifs et les connecteurs)
• Usure ou contamination du montage
• Changements environnementaux (température, humidité dans la zone de test)
• Étapes dépendantes de l'opérateur avec exécution incohérente

Problèmes de script de test

Parfois le test lui-même est le problème. Des mesures instables, un temps de stabilisation manquant ou une configuration incorrecte de l'instrument peuvent tous se manifester comme une perte de rendement. Recherchez les mesures avec des distributions bimodales ou une variance élevée qui ne corrèle pas avec le DUT.

Étape 3 : Affiner vos limites de mesure

De bonnes limites proviennent d'une combinaison de la fiche technique du composant, de vos marges de conception et des données de production réelles. Voici le workflow.

Commencer par les limites de la fiche technique

Vos limites initiales doivent refléter l'intention de conception. Relevez les valeurs minimales et maximales dans les fiches techniques pertinentes et vos spécifications de conception.

import openhtf as htf
from openhtf.util import units

@htf.measures(
    htf.Measurement("vdd_3v3")
        .with_units(units.VOLT)
        .in_range(minimum=3.135, maximum=3.465)  # 3,3 V +/- 5 % selon la fiche technique du régulateur
        .doc("Rail principal 3,3 V, mesuré à C12"),
    htf.Measurement("vdd_1v8")
        .with_units(units.VOLT)
        .in_range(minimum=1.746, maximum=1.854)  # 1,8 V +/- 3 % selon la fiche technique du LDO
        .doc("Rail cœur 1,8 V, mesuré à C45"),
)
def measure_power_rails(test):
    # Les lectures d'instruments vont ici
    test.measurements.vdd_3v3 = read_voltage("3V3_TP")
    test.measurements.vdd_1v8 = read_voltage("1V8_TP")

Resserrer avec les données de production

Après avoir collecté quelques centaines d'unités, vérifiez la distribution réelle dans les cartes de contrôle de TofuPilot. Si vos mesures se regroupent étroitement autour du nominal avec un Cpk > 1,67, vous avez de la marge pour resserrer. Des limites plus serrées détectent les unités marginales avant qu'elles ne deviennent des retours terrain.

Ajouter des limites marginales pour l'alerte précoce

OpenHTF supporte les limites marginales qui signalent les unités comme « passage marginal » sans les faire échouer directement. Cela vous donne une alerte précoce quand une mesure dérive vers les limites de spécification.

import openhtf as htf
from openhtf.util import units

@htf.measures(
    htf.Measurement("vdd_3v3")
        .with_units(units.VOLT)
        .in_range(
            minimum=3.135, maximum=3.465,
            marginal_minimum=3.168, marginal_maximum=3.432,  # Bande intérieure de 2 %
        )
        .doc("Rail principal 3,3 V avec détection marginale"),
)
def measure_power_rails(test):
    test.measurements.vdd_3v3 = read_voltage("3V3_TP")

Les unités marginales passent mais sont signalées dans TofuPilot. Quand les taux marginaux augmentent, vous savez qu'un décalage de processus est en cours avant qu'il ne commence à provoquer des échecs durs.

Étape 4 : Améliorer la structure des tests pour des résultats fiables

Les tests instables détruisent les chiffres de rendement. Quelques pratiques structurelles font une grande différence.

Séparer les mesures proprement

Chaque mesure doit tester une seule chose. Si une seule phase mesure cinq tensions différentes, un échec sur l'une d'entre elles rend l'identification de la cause racine plus difficile.

import openhtf as htf
from openhtf.util import units
import time

# Bien : une mesure par phase, nommage clair
@htf.measures(
    htf.Measurement("supply_current_idle")
        .with_units(units.AMPERE)
        .in_range(minimum=0.010, maximum=0.025)
        .doc("Courant de repos de la carte à 3,3 V en entrée"),
)
def measure_idle_current(test):
    set_load("idle")
    time.sleep(0.5)  # Le temps de stabilisation compte
    test.measurements.supply_current_idle = read_current("ISENSE")


@htf.measures(
    htf.Measurement("supply_current_active")
        .with_units(units.AMPERE)
        .in_range(minimum=0.080, maximum=0.150)
        .doc("Courant de la carte pendant le traitement actif"),
)
def measure_active_current(test):
    set_load("active")
    time.sleep(1.0)  # Le mode actif nécessite un temps de stabilisation plus long
    test.measurements.supply_current_active = read_current("ISENSE")

Ajouter du temps de stabilisation et des réessais pour les mesures bruitées

Si une mesure est intrinsèquement bruitée (puissance RF, courant pendant les transitions), moyennez plusieurs lectures ou ajoutez un réessai avec un court délai. Ne comptez pas sur la chance.

import openhtf as htf
import time

@htf.measures(
    htf.Measurement("tx_power_dbm")
        .in_range(minimum=18.0, maximum=22.0)
        .doc("Puissance d'émission à 2,4 GHz, moyennée sur 5 lectures"),
)
def measure_tx_power(test):
    readings = []
    for _ in range(5):
        readings.append(read_rf_power("TX_OUT"))
        time.sleep(0.1)
    test.measurements.tx_power_dbm = sum(readings) / len(readings)

Utiliser des noms de mesure descriptifs

Des noms comme m1, test_3 ou voltage rendent impossible l'analyse des causes racines à grande échelle. Utilisez des noms qui décrivent ce qui est mesuré et où.

Étape 5 : Construire un workflow d'amélioration continue

Améliorer le FPY n'est pas un projet ponctuel. C'est une pratique hebdomadaire.

Processus de revue hebdomadaire

1. Vérifier la tendance FPY dans l'onglet Analytics de TofuPilot. Est-elle en amélioration, stable ou en déclin ?
2. Examiner le diagramme de Pareto pour les principaux modes de défaillance. Les défaillances principales ont-elles changé depuis la semaine dernière ?
3. Inspecter les cartes de contrôle pour toute mesure montrant une dérive ou une variance accrue
4. Mettre à jour les limites si les données de production montrent des valeurs de Cpk qui justifient un resserrement ou un élargissement
5. Suivre les taux marginaux comme indicateur avancé de perte de rendement future

Quand agir vs quand surveiller

Résumé

Améliorer le FPY suit un schéma reproductible : identifier les principales défaillances avec l'analyse de Pareto, effectuer l'analyse des causes racines en utilisant les cartes de contrôle et les données Cpk de TofuPilot, affiner les limites en fonction des distributions de production, et surveiller hebdomadairement les régressions. Les équipes qui maintiennent un rendement élevé sont celles qui traitent cela comme une boucle continue, pas comme une correction ponctuelle.