Suivre les données de réparation

Les tests de production détectent les défauts, mais la vraie valeur vient de la boucle fermée : diagnostiquer les défaillances, réparer les unités et les retester. TofuPilot lie chaque retest au numéro de série original pour que vous obteniez un historique complet du parcours de chaque unité dans votre processus de réparation.

La boucle de réparation

Un flux de réparation typique suit ce cycle : une unité échoue à un test, un technicien diagnostique la cause racine, effectue une réparation, et l'unité repasse par les tests. Sans données structurées, cet historique se perd dans des tableurs ou des journaux papier.

TofuPilot résout ce problème en indexant tout sur le numéro de série. Chaque exécution de test sur le même DUT apparaît automatiquement dans son historique d'unité. Aucune configuration spéciale n'est nécessaire. Utilisez simplement le même numéro de série lors du retest.

Structurer votre test initial

Commencez par un test OpenHTF standard qui mesure votre DUT et envoie les résultats à TofuPilot.

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),
    htf.Measurement("current_draw")
    .in_range(minimum=0.095, maximum=0.105)
    .with_units(units.AMPERE),
)
def functional_check(test):
    test.measurements.output_voltage = 5.05
    test.measurements.current_draw = 0.1012


def main():
    test = htf.Test(functional_check)
    with TofuPilot(test):
        test.execute(test_start=lambda: "SN-20260312-001")


if __name__ == "__main__":
    main()

Quand ce test échoue, l'unité entre dans votre file d'attente de réparation.

Enregistrer les actions de réparation comme métadonnées

Après qu'un technicien a diagnostiqué et réparé l'unité, capturez ce contexte dans le retest. Utilisez les métadonnées au niveau de la phase pour enregistrer ce qui a été trouvé et ce qui a été fait.

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


@htf.measures(
    htf.Measurement("repair_code"),
    htf.Measurement("failure_category"),
    htf.Measurement("repair_action"),
)
def record_repair_info(test):
    # Ces valeurs proviennent de la saisie du technicien de réparation
    test.measurements.repair_code = "RC-042"
    test.measurements.failure_category = "solder_bridge"
    test.measurements.repair_action = "reworked_U3_solder_joints"


@htf.measures(
    htf.Measurement("output_voltage")
    .in_range(minimum=4.8, maximum=5.2)
    .with_units(units.VOLT),
    htf.Measurement("current_draw")
    .in_range(minimum=0.095, maximum=0.105)
    .with_units(units.AMPERE),
)
def functional_recheck(test):
    test.measurements.output_voltage = 5.01
    test.measurements.current_draw = 0.1003


def main():
    test = htf.Test(record_repair_info, functional_recheck)
    with TofuPilot(test):
        # Le même numéro de série lie ce retest à la défaillance originale
        test.execute(test_start=lambda: "SN-20260312-001")


if __name__ == "__main__":
    main()

La phase record_repair_info stocke le diagnostic et l'action de réparation aux côtés des mesures du retest. Ces données apparaissent dans la vue détaillée de l'exécution dans TofuPilot, liées à la même unité.

Utiliser des catégories de défaillance cohérentes

Définissez un ensemble standard de catégories de défaillance et de codes de réparation au sein de votre équipe. Un nommage cohérent permet de filtrer et d'agréger les données de réparation ultérieurement.

Catégories de défaillance courantes pour les tests PCBA :

Stockez-les comme mesures de type chaîne de caractères pour qu'elles soient recherchables dans TofuPilot.

Suivre les cycles de réparation multiples

Certaines unités nécessitent plus d'une tentative de réparation. Chaque retest crée une nouvelle exécution sur le même numéro de série. La vue historique de l'unité dans TofuPilot montre la chaîne complète : échec initial, première tentative de réparation, deuxième tentative de réparation et passage final.

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


@htf.measures(
    htf.Measurement("repair_code"),
    htf.Measurement("failure_category"),
    htf.Measurement("repair_action"),
    htf.Measurement("repair_cycle"),
)
def record_repair_info(test):
    test.measurements.repair_code = "RC-043"
    test.measurements.failure_category = "cold_joint"
    test.measurements.repair_action = "reflowed_C12_pads"
    test.measurements.repair_cycle = 2


@htf.measures(
    htf.Measurement("output_voltage")
    .in_range(minimum=4.8, maximum=5.2)
    .with_units(units.VOLT),
    htf.Measurement("current_draw")
    .in_range(minimum=0.095, maximum=0.105)
    .with_units(units.AMPERE),
)
def functional_recheck(test):
    test.measurements.output_voltage = 4.98
    test.measurements.current_draw = 0.0998


def main():
    test = htf.Test(record_repair_info, functional_recheck)
    with TofuPilot(test):
        test.execute(test_start=lambda: "SN-20260312-001")


if __name__ == "__main__":
    main()

Ajouter une mesure repair_cycle facilite le comptage du nombre de tentatives nécessaires pour chaque unité.

Analyser les tendances de réparation dans TofuPilot

Une fois que vos données de réparation sont dans TofuPilot, le tableau de bord vous fournit ce dont vous avez besoin sans écrire de scripts d'analyse.

L'historique de l'unité affiche chaque exécution de test pour un numéro de série par ordre chronologique. Vous pouvez voir exactement quand une unité a échoué, ce qui a été réparé et si le retest a réussi.

Les diagrammes de Pareto des défaillances classent vos catégories de défaillance par fréquence. Si solder_bridge domine, c'est un signal pour investiguer votre profil de refusion ou la conception du pochoir.

Les tendances FPY reflètent l'efficacité de vos réparations dans le temps. Un FPY en hausse après des modifications de processus confirme que la correction fonctionne. Une unité qui échoue constamment au même test après plusieurs réparations peut pointer vers un problème de conception plus profond.

Séparer les procédures de test pour le test initial et le retest

Pour la traçabilité, envisagez d'utiliser des noms de procédure distincts pour les tests initiaux et les retests. TofuPilot regroupe les exécutions par procédure, donc cette séparation rend le reporting plus propre.

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


@htf.measures(
    htf.Measurement("repair_code"),
    htf.Measurement("repair_action"),
)
def record_repair_info(test):
    test.measurements.repair_code = "RC-042"
    test.measurements.repair_action = "reworked_U3_solder_joints"


@htf.measures(
    htf.Measurement("output_voltage")
    .in_range(minimum=4.8, maximum=5.2)
    .with_units(units.VOLT),
)
def functional_recheck(test):
    test.measurements.output_voltage = 5.02


def main():
    test = htf.Test(record_repair_info, functional_recheck)
    with TofuPilot(test, procedure_name="PCBA Functional Test - Retest"):
        test.execute(test_start=lambda: "SN-20260312-001")


if __name__ == "__main__":
    main()

De cette façon, vous pouvez comparer le FPY entre les tests initiaux et les retests indépendamment, tandis que l'historique de l'unité lie toujours tout ensemble sous un seul numéro de série.