La situation est familière. Les préséries se passaient bien. Mêmes composants, mêmes gerbers, même test. Puis la production démarre et une partie des cartes échoue, souvent à une étape précise, sans qu'aucun changement de conception ait eu lieu.
Ce guide est une méthode pour trouver la cause. Il suppose que vous enregistrez les résultats de test. Si vous n'avez que des compteurs pass/fail, passez à la dernière section : c'est le vrai problème et il vaut la peine d'être réglé avant la prochaine fois.
Les requêtes ci-dessous supposent des mesures enregistrées par étape, chaque étape appartenant à un run : run → step → measurement. Adaptez les jointures si votre schéma rattache les mesures directement aux runs.
Commencez par les valeurs mesurées, pas par le taux de réussite
Le taux de réussite indique que des unités ont échoué. Il ne dit pas pourquoi, et il masque le signal le plus utile.
Une mesure qui dérive vers sa limite passera pendant des semaines avant de commencer à échouer. Quand le rendement bouge, la cause est présente depuis longtemps. Si vous tracez les valeurs mesurées plutôt que les verdicts, la dérive est visible avant qu'elle ne coûte quoi que ce soit.
SELECT date_trunc('day', r.started_at) AS day, avg(m.value) AS mean, stddev(m.value) AS sigma, min(m.value) AS min_value, max(m.value) AS max_value, count(*) AS nFROM measurement mJOIN step s ON s.id = m.step_idJOIN run r ON r.id = s.run_idWHERE m.name = 'rail_3v3' AND r.procedure_id = 'FCT-001'GROUP BY dayORDER BY day;Regardez la moyenne et la dispersion séparément. Elles échouent différemment :
- La moyenne bouge, la dispersion reste serrée. Quelque chose a changé d'état. Un nouveau lot de composants, un profil de refusion modifié, un instrument recalibré.
- La moyenne reste, la dispersion s'élargit. Quelque chose est devenu inconstant. Un montage usé, un contact intermittent, la température au fil d'une équipe.
- Les deux bougent. Généralement deux causes. Segmentez les données avant d'aller plus loin.
Segmentez avant de formuler une théorie
Avant de théoriser, découpez les échecs selon toutes les dimensions que vous enregistrez. L'objectif est de trouver une dimension où le taux d'échec n'est pas uniforme.
| Segmenter par | Ce qu'une différence signifie |
|---|---|
| Station de test | Usure du montage, instrument décalibré, mauvais câble sur une station |
| Heure ou équipe | Température, variation secteur, opérateur, effets de mise en chauffe |
| Lot de composants | Variation des pièces entrantes, cause la plus fréquente d'une rupture nette |
| Panneau ou lot de PCB | Problème de process au niveau carte |
| Opérateur | Technique de mise en place, étape sautée |
| Étape de test | Restreint le sous-système physique concerné |
| Version de firmware | Une constante de calibration ou un seuil a changé |
SELECT r.station_id, count(*) AS runs, count(*) FILTER (WHERE NOT r.passed) AS failures, round(100.0 * count(*) FILTER (WHERE NOT r.passed) / count(*), 2) AS fail_pctFROM run rWHERE r.procedure_id = 'FCT-001' AND r.started_at > now() - interval '14 days'GROUP BY r.station_idORDER BY fail_pct DESC;Si une station est à 12 % et les autres à 2 %, vous avez la réponse et ce n'est pas un problème de conception. Cette seule requête résout une part surprenante des enquêtes de rendement.
Confirmez que l'échec est réel
Avant d'enquêter sur un process, éliminez le test lui-même. Un test qui rejette de bonnes cartes est plus fréquent qu'on ne le pense et fait perdre des semaines.
Vérifiez dans cet ordre :
- Retestez une unité en échec sans y toucher. Si elle passe, vous avez un contact intermittent ou une limite marginale, pas un défaut produit.
- Retestez sur une autre station. Si elle passe, la première station est en cause.
- Échangez le composant suspect entre une carte en échec et une carte conforme. Si l'échec suit le composant, c'est un problème de pièce. S'il reste sur la carte, c'est la carte ou le process.
- Mesurez à la main avec un autre instrument. Si la mesure manuelle diverge du montage, le montage ou sa calibration est suspect.
L'étape 3 est le meilleur diagnostic disponible et coûte un cycle de reprise. Elle sépare nettement les problèmes de composants de ceux d'assemblage.
Vérifiez si le problème vient des limites
Si les valeurs mesurées n'ont pas bougé mais que le taux d'échec a augmenté, examinez les limites plutôt que le process.
Les limites sont souvent resserrées après une défaillance terrain, ou recopiées d'une fiche technique sans tenir compte de l'incertitude de mesure. Une limite proche de la dispersion naturelle rejettera de bonnes unités à un rythme constant.
La règle empirique : la dispersion du process doit tenir confortablement dans les limites. Si la distance entre limite et moyenne est inférieure à environ quatre écarts-types, attendez-vous à des rejets par simple variation normale. Ce rapport, c'est la capabilité, Cp et Cpk.
SELECT m.name, avg(m.value) AS mean, stddev(m.value) AS sigma, min(m.lower_limit) AS lsl, min(m.upper_limit) AS usl, least( (min(m.upper_limit) - avg(m.value)) / (3 * stddev(m.value)), (avg(m.value) - min(m.lower_limit)) / (3 * stddev(m.value)) ) AS cpkFROM measurement mJOIN step s ON s.id = m.step_idJOIN run r ON r.id = s.run_idWHERE r.procedure_id = 'FCT-001' AND r.started_at > now() - interval '30 days'GROUP BY m.nameHAVING stddev(m.value) > 0ORDER BY cpk ASC;Triez en ordre croissant et les mesures les plus susceptibles de causer des rejets apparaissent en premier. En dessous de 1,33, cela mérite attention ; en dessous de 1,0, vous rejetez des unités par variation normale.
Deux réserves avant d'agir sur ce chiffre. Cpk suppose une mesure à peu près normale et un process stable sur la fenêtre interrogée : une valeur calculée à travers une dérive n'a pas de sens. Et une mesure unilatérale, avec seulement une limite haute ou basse, rend nulle une moitié du least(). Traitez ce cas séparément plutôt que de lire le résultat comme un score bas.
Quelle étape vous coûte réellement
Quand plusieurs étapes échouent, corrigez celle qui coûte le plus d'unités, pas la plus intéressante.
SELECT s.name AS step, count(*) AS failures, round(100.0 * count(*) / sum(count(*)) OVER (), 1) AS pct_of_failuresFROM step sJOIN run r ON r.id = s.run_idWHERE r.procedure_id = 'FCT-001' AND NOT s.passed AND r.started_at > now() - interval '30 days'GROUP BY s.nameORDER BY failures DESC;Les distributions d'échecs sont généralement très asymétriques. Deux ou trois étapes concentrent l'essentiel des pertes.
Attention aux retests qui masquent le problème
Si votre rendement compte n'importe quel run réussi plutôt que le premier run par unité, les retests masqueront un process qui se dégrade.
Le rendement au premier passage, c'est le premier run par unité :
SELECT date_trunc('day', first_run.started_at) AS day, count(*) FILTER (WHERE first_run.passed) * 100.0 / count(*) AS fpy_percent, count(*) AS unitsFROM ( SELECT DISTINCT ON (unit_id) unit_id, started_at, passed FROM run WHERE procedure_id = 'FCT-001' ORDER BY unit_id, started_at ASC) AS first_runGROUP BY dayORDER BY day DESC;Le DISTINCT ON avec tri ascendant est ce qui donne le premier run et non n'importe lequel. Se tromper là-dessus est le bug de reporting le plus courant des systèmes maison, et il embellit toujours le chiffre.
Un écart qui se creuse entre rendement au premier passage et rendement final est lui-même un signal : le process se dégrade et les retests l'absorbent.
Quand vous n'avez pas les données
Si l'enquête ci-dessus est impossible parce que vous n'avez enregistré que pass/fail, c'est là le constat. Le correctif n'est pas compliqué mais doit intervenir avant le prochain incident :
Stockez la valeur mesurée, pas seulement le verdict. Un booléen dit qu'une unité a échoué. La valeur dit qu'elle dérivait depuis trois semaines.
Enregistrez la station, l'opérateur, la version de firmware. Ce sont les dimensions de segmentation, et elles ne coûtent rien à capturer.
Versionnez la procédure de test. Quand les limites changent, il faut savoir quelle version a produit un résultat.
Conservez numéros de série et liens de sous-ensembles. Quand un échec corrèle avec un lot de composants, il faut tracer quelles unités contiennent quelles pièces.
Alertez sur la tendance, pas sur le seuil. Quand le rendement franchit un seuil, la cause a des semaines.
TofuPilot enregistre tout cela par défaut depuis un script Python et calcule rendement, capabilité, cartes de contrôle et Pareto sans les requêtes ci-dessus. Mais les requêtes sont là parce que la méthode compte plus que l'outil, et elles fonctionnent sur tout schéma stockant la valeur mesurée.