Comment concevoir un écran opérateur pour les tests en fin de ligne
Un opérateur de test en fin de ligne (EOL) exécute le même test des centaines de fois par équipe. L'écran qu'il voit doit communiquer trois choses instantanément : quoi faire, si c'est réussi, et quoi faire ensuite. Ce guide couvre les principes de conception des écrans opérateur EOL et comment les implémenter avec OpenHTF et TofuPilot.
Principes de conception
1. La règle des 3 secondes
Un opérateur doit comprendre l'état de l'écran en 3 secondes. Cela signifie :
| Élément | Exigence |
|---|---|
| Indicateur réussite/échec | Fond vert ou rouge plein écran, visible à 3 mètres |
| Étape en cours | Texte en grand montrant ce qui se passe |
| Action opérateur | Instruction en gras quand une saisie est nécessaire |
| Tout le reste | Secondaire, plus petit ou masqué |
2. Minimiser les décisions
Chaque décision que l'opérateur prend est une chance d'erreur. Réduisez-les :
| Mauvais | Mieux |
|---|---|
| Saisir le numéro de série | Scanner le code-barres |
| Choisir la variante produit | Détection automatique depuis le préfixe du code-barres |
| Sélectionner la procédure de test | Une station, une procédure |
| Cliquer sur « Démarrer le test » | Démarrage automatique après scan du code-barres |
| Cliquer sur « Imprimer l'étiquette » | Impression automatique en cas de réussite |
3. Sécuriser le flux de travail contre les erreurs
| Risque | Atténuation |
|---|---|
| Mauvais format de numéro de série | Valider le format du code-barres avant le démarrage |
| Tester la même unité deux fois | Avertir si le numéro de série a déjà été testé aujourd'hui |
| Sauter le test | Verrouiller la station d'emballage tant que le test n'est pas réussi |
| Manquer un échec | Alerte sonore en cas d'échec, acquittement requis |
Prérequis
- Python 3.10+
- OpenHTF installé (
pip install openhtf) - SDK Python TofuPilot installé (
pip install tofupilot)
Étape 1 : Concevoir le flux de test
Un test EOL doit suivre cette séquence :
Scanner le code-barres → Démarrage auto → Exécuter les phases → Afficher le résultat → Prêt pour l'unité suivante
Pas de menus, pas de configuration, pas de clics supplémentaires.
import openhtf as htf
from openhtf.util import units
from openhtf import PhaseResult
@htf.measures(
htf.Measurement("supply_current_mA")
.in_range(minimum=90, maximum=110)
.with_units(units.MILLIAMPERE),
)
def phase_power_up(test):
"""Appliquer l'alimentation et vérifier la consommation de courant."""
test.measurements.supply_current_mA = 101.2
@htf.measures(
htf.Measurement("firmware_version").equals("3.1.0"),
)
def phase_firmware(test):
"""Vérifier que la version firmware correspond à la version de production."""
test.measurements.firmware_version = "3.1.0"
@htf.measures(
htf.Measurement("self_test").equals("PASS"),
)
def phase_self_test(test):
"""Exécuter l'autotest intégré du DUT."""
test.measurements.self_test = "PASS"
@htf.measures(
htf.Measurement("output_voltage_V")
.in_range(minimum=11.8, maximum=12.2)
.with_units(units.VOLT),
)
def phase_output_check(test):
"""Mesurer la tension de sortie principale."""
test.measurements.output_voltage_V = 12.03Étape 2 : Échouer rapidement
Placez la défaillance la plus probable en premier. Si la mise sous tension échoue, sautez tout le reste. L'opérateur voit l'échec en moins de 5 secondes au lieu d'attendre le cycle de test complet.
@htf.measures(
htf.Measurement("power_good").equals("PASS"),
)
def phase_power_good(test):
"""Vérification rapide de l'alimentation avant le test complet."""
result = "PASS"
test.measurements.power_good = result
if result != "PASS":
return PhaseResult.STOPÉtape 3 : Connecter et diffuser
L'interface opérateur de TofuPilot gère l'affichage. L'opérateur voit la progression de chaque phase, les mesures avec leurs limites, et un résultat réussite/échec en plein écran.
from tofupilot.openhtf import TofuPilot
test = htf.Test(
phase_power_good,
phase_power_up,
phase_firmware,
phase_self_test,
phase_output_check,
)
with TofuPilot(test):
test.execute(test_start=lambda: input("Scanner le numéro de série : "))Recommandations de disposition d'écran
| Zone | Contenu | Taille |
|---|---|---|
| Barre supérieure | Nom de la station, heure actuelle, unités testées aujourd'hui | Petit |
| Centre | Nom et statut de la phase en cours, ou résultat réussite/échec | Grand (60% de l'écran) |
| Zone d'invite | Instruction opérateur quand une saisie est nécessaire | Moyen, mis en évidence |
| Bas | 5 derniers résultats (réussite/échec par numéro de série) | Petit, défilant |
Code couleur
| État | Couleur | Signification |
|---|---|---|
| Inactif | Gris ou bleu | En attente du scan du code-barres |
| En cours | Bleu | Test en cours |
| Réussite | Vert | L'unité a réussi toutes les phases |
| Échec | Rouge | L'unité a échoué à une ou plusieurs phases |
| Invite | Jaune/ambre | En attente d'une saisie opérateur |
Optimisation du temps de cycle pour l'EOL
Les tests EOL s'exécutent en continu. Chaque seconde de temps de cycle compte.
| Optimisation | Effet |
|---|---|
| Démarrage auto après scan | Économise 2 à 3 secondes par unité |
| Pas d'invites inutiles | Économise 5 à 10 secondes par invite |
| Ordonnancement des phases par échec rapide | Réduit le temps de cycle moyen sur les unités défectueuses de 50%+ |
| Commandes d'instruments en parallèle | Économise 100 à 500 ms par phase |
| Mode kiosque (pas de chrome navigateur) | Empêche la navigation accidentelle |
Ce qu'il faut éviter
| Erreur | Pourquoi |
|---|---|
| Texte réussite/échec trop petit | L'opérateur doit se pencher pour le lire |
| Tableaux de mesures détaillés pendant le test | Distrait de l'étape en cours |
| Fenêtres ou onglets multiples | L'opérateur se perd |
| Écrans de connexion | Les opérateurs partagent les stations entre les équipes |
| Thème sombre sous éclairage d'usine vif | Faible contraste, difficile à lire |
| Animations ou transitions | Ralentissent la perception des changements d'état |