Réduire le No-Fault-Found (NFF) en test

Le No-Fault-Found désigne une unité retournée qui se révèle bonne au banc. Rien ne se reproduit, donc l'unité repart en service, souvent pour échouer de nouveau quelques semaines plus tard. Dans la maintenance de composants, le NFF représente une part importante des retours, et chacun d'eux consomme du temps de banc tout en érodant la confiance dans le test lui-même. Ce guide explique ce qu'est le NFF, pourquoi il survient, et comment repérer le motif qui le sous-tend à partir de vos propres données de test.

Ce que signifie No-Fault-Found

Une unité est déposée d'un équipement, déclarée défectueuse. Au banc, elle passe tous les contrôles. Sans défaillance sur laquelle agir, l'unité retourne en service comme utilisable. C'est un NFF, parfois consigné comme CND (Cannot Duplicate) ou RTOK (Retest OK).

Le NFF n'est pas un problème unique. C'est une étiquette qui en recouvre plusieurs :

• Défauts intermittents. Le défaut est réel mais n'apparaît que dans des conditions que le banc ne reproduit pas (température, vibration, une séquence d'entrée particulière).
• Échappement de test. Les limites du banc sont trop larges, donc une unité marginale passe.
• Dépose injustifiée. Le défaut était ailleurs dans le système, et une bonne unité a été déposée.
• Dérive du montage. Le banc lui-même a changé, donc un vrai défaut se lit comme un succès.

On ne corrige pas ce qu'on ne voit pas. La première étape est de rendre chacun de ces cas visible dans les données, ce qui commence par la façon dont le test est écrit.

Structurer le test pour rendre le NFF visible

Une investigation NFF a besoin de trois choses dans l'enregistrement : la valeur mesurée exacte (pas seulement succès/échec), le numéro de série, et un jeu de limites stable sur lequel établir une tendance. Un test qui ne rapporte que succès ou échec jette l'information dont vous avez besoin.

L'exemple ci-dessous est un test d'acceptation au banc pour une unité retournée, écrit avec le TofuPilot framework. Chaque phase lit une valeur réelle et la valide contre une limite, de sorte qu'une unité qui passe laisse tout de même derrière elle une trace complète de mesures.

name: LRU Bench Acceptance Testversion: 1.0.0description: Functional acceptance test for a returned unit on the repair benchunit:  auto_identify: true  serial_number:    default_value: "LRU000001"  part_number:    default_value: "622-1234-001"plugs:  - name: bench    python: plugs.bench:Benchmain:  - name: Power Supply Check    python: phases.power_check    measurements:      - name: supply_voltage        unit: V        validators:          - operator: ">="            expected_value: 27.5          - operator: "<="            expected_value: 28.5  - name: Signal Integrity    python: phases.signal_check    measurements:      - name: output_delay        unit: us        validators:          - operator: "<="            expected_value: 12.0      - name: signal_snr        unit: dB        validators:          - operator: ">="            expected_value: 40.0

def power_check(measurements, bench):    measurements.supply_voltage = bench.read_supply_voltage()

def signal_check(measurements, bench):    measurements.output_delay = bench.read_output_delay()    measurements.signal_snr = bench.read_snr()

class Bench:    def read_supply_voltage(self) -> float:        return 28.01    def read_output_delay(self) -> float:        return 9.4    def read_snr(self) -> float:        return 44.7

Exécutez-le depuis le répertoire de la procédure :

→ Phase: Power Supply Check→ Phase: Signal Integrity✓ Phase Power Supply Check: PASS→   supply_voltage = 28.01 V [PASS]✓ Phase Signal Integrity: PASS→   output_delay = 9.4 us [PASS]→   signal_snr = 44.7 dB [PASS]✓ Run complete: PASS

Cette unité passe. C'est le cas NFF. Mais parce que le test a enregistré output_delay = 9.4 us face à une limite de 12.0, et pas seulement PASS, la prochaine unité qui lira 11.8 sera visible comme un succès marginal bien avant d'échouer en service. C'est la valeur qui permet d'établir une tendance. Le succès/échec seul ne vous apprend rien.

Suivre le nombre de retests

Le signal NFF le plus fort est une unité testée plus d'une fois. Une même unité qui repasse trois ou quatre fois au banc est soit intermittente, soit poursuivie en rond. Parce que chaque run identifie l'unité par son numéro de série, TofuPilot construit automatiquement un historique par unité. La page d'historique d'unité montre chaque run pour un numéro de série, donc une visiteuse récurrente ressort sans que vous ayez à la suivre à la main.

Triez un numéro de pièce par nombre de retests et les unités intermittentes remontent en tête. Ce sont celles qu'il vaut la peine d'extraire pour un examen approfondi, et celles autour desquelles construire une discussion avec le fournisseur.

Établir la tendance de la mesure, pas du verdict

Une unité qui passe au bord de sa limite est un NFF en devenir. Pour l'attraper, regardez la valeur mesurée dans le temps plutôt que le taux de succès.

Dans TofuPilot, ouvrez la mesure pour le numéro de pièce et lisez la distribution et la dérive :

• Distribution. Si les valeurs qui passent se regroupent près d'une limite au lieu de se centrer dans la plage, la conception ou le procédé fonctionne près du bord. Des unités marginales passent aujourd'hui et échoueront demain.
• Cpk. Un Cpk inférieur à 1,0 signifie que la dispersion ne tient pas de façon fiable dans les limites. Une fraction des unités sortira toujours du cadre, et certaines d'entre elles sont vos retours NFF.
• Dérive. Un déplacement lent de la moyenne indique un vieillissement, un changement de fournisseur, ou un banc qui a bougé. Détecter le déplacement tôt, c'est la différence entre une seule investigation et un lot de retours.

C'est la même base statistique que les équipes de production utilisent pour le rendement, appliquée à une ligne de réparation. La question passe de « cette unité a-t-elle passé » à « cette mesure est-elle saine sur toutes les unités que nous voyons ».

Alerter automatiquement sur le signal

Examiner des graphiques à la main ne passe pas à l'échelle. TofuPilot peut surveiller les données et lever une alerte quand le motif NFF apparaît :

• Dérive de mesure. Se déclenche quand une mesure s'écarte de sa propre ligne de base, qu'il s'agisse d'un déplacement de moyenne ou d'un Cpk en baisse, de sorte qu'une pièce qui dérive est signalée avant de devenir une vague de retours.
• Seuil de retest. Se déclenche quand une unité est testée plus souvent que le rythme normal de la procédure. Le seuil se calibre lui-même par procédure, donc vous êtes alerté sur les unités réellement anormales, pas sur les unités de routine.

Les alertes apprennent le comportement normal de chaque procédure, donc vous les réglez une fois au lieu d'ajuster des limites à la main pour chaque pièce.

À quoi ressemble une ligne saine

Une ligne de réparation dont le NFF est maîtrisé présente quelques traits visibles. Les nombres de retests sont faibles et stables, avec peu d'unités qui reviennent. Les distributions de mesures se centrent à l'intérieur de leurs limites au lieu de s'entasser sur un bord, et le Cpk reste au-dessus de 1,0. Quand une valeur commence bel et bien à dériver, une alerte l'attrape alors qu'il ne s'agit encore que d'une pièce, pas d'un lot.

Rien de tout cela n'exige de nouveau matériel ni l'accès à un logiciel propriétaire tiers. Cela découle de l'enregistrement de la valeur mesurée plutôt que du verdict, du maintien d'un historique par unité, et du suivi de tendance de ce que vous capturez déjà au banc.