Test Station Setup

Test séquentiel, parallèle ou batch

Comparez les trois stratégies d'exécution de test, identifiez celle qu'impose votre banc, et configurez les slots parallèles et phases partagées.

JJulien Buteau
intermediate9 min de lecture9 septembre 2026

Test séquentiel, parallèle ou batch

Trois stratégies d'exécution couvrent presque tous les postes de test de production : tester une unité à la fois, en tester plusieurs indépendamment, ou en tester plusieurs comme un groupe. Le choix est imposé par votre banc, pas par préférence, et se tromper revient soit à gaspiller du matériel, soit à produire des résultats auxquels vous ne pouvez pas vous fier.

Ce guide définit chaque stratégie, donne la règle de décision et montre comment les configurer. Pour l'abstraction à laquelle ces stratégies appartiennent, voir Qu'est-ce qu'un process model de test.

Les trois stratégies

StratégieUnités en coursDémarrage et fin des unitésBanc typique
Séquentiel1Une à la foisBanc à une position
ParallèleNIndépendamment, chacune à son rythmeN bancs indépendants
BatchNEnsemble, comme un groupeUn banc contenant N unités

La différence entre parallèle et batch est le couplage, pas le nombre. Les deux testent plusieurs unités à la fois. En parallèle, une unité qui finit tôt est déchargée et remplacée immédiatement. En batch, elle attend ses voisines.

Séquentiel

Une unité est chargée, testée du début à la fin, puis déchargée. L'unité suivante commence après.

sequential.txt
Unité 1  [====== 30s ======]Unité 2                     [====== 30s ======]Unité 3                                        [====== 30s ======]

Le séquentiel est la bonne réponse quand le banc ne contient qu'une unité, quand le test nécessite un instrument physiquement impartageable, ou quand un opérateur doit de toute façon manipuler chaque unité. C'est aussi le bon point de départ pour une nouvelle procédure : faire passer une unité de façon fiable avant d'ajouter de la concurrence.

Son coût est le débit. Le temps de test est dominé par l'attente, et avec une seule unité en cours, rien ne se superpose à cette attente.

Parallèle

Plusieurs unités sont testées en même temps, chacune à son rythme. L'unité 2 qui échoue à 5 secondes ne perturbe pas l'unité 1, et sa position est libre pour un remplacement pendant que les autres tournent encore.

parallel.txt
Slot 1  [====== 30s ======][====== 30s ======]Slot 2  [== 5s ==][====== 30s ======]Slot 3  [====== 30s ======][====== 30s ======]

Le parallèle est l'option au plus fort débit et le choix par défaut pour un banc multi-positions. Sur un banc à quatre positions avec un test de 30 secondes, le débit passe d'environ 120 unités par heure à près de 450, borné par ce que les slots partagent réellement.

Deux conditions doivent tenir. Chaque position a besoin de ses propres instruments, ou d'un instrument partagé assez rapide pour que la mise en file d'attente ne domine pas. Et le test ne doit pas dépendre de ses voisines : pas de rampe d'enceinte thermique partagée, pas de mesure supposant que toutes les unités sont dans le même état.

Batch

Plusieurs unités sont chargées ensemble, testées ensemble et déchargées ensemble. Le groupe se déplace comme un tout.

batch.txt
Unité 1  [====== 30s ======]        inactifUnité 2  [== 5s ==]  inactif        (attend le groupe)Unité 3  [========== 45s ==========]         └──────── le batch finit à 45s ────────┘

Le batch existe parce que certains tests sont physiquement partagés. Une enceinte thermique fait monter en température toutes les unités qu'elle contient d'un coup. Un balayage de pré-conformité CEM illumine le plateau entier. Un rack de burn-in alimente une étagère ensemble. Dans ces cas, l'opération partagée est le test, et les unités ne peuvent pas être découplées.

Le batch est aussi correct pour des raisons de traçabilité : quand il faut prouver que des unités ont été testées dans des conditions identiques, les tester ensemble est la preuve.

Le coût est visible sur le schéma. Chaque unité paie le temps de la plus lente, et le banc ne peut pas être rechargé avant la fin du groupe.

Choisir

Descendez cette liste et arrêtez-vous à la première correspondance :

  1. Une seule opération physique couvre-t-elle toutes les unités à la fois (rampe d'enceinte, champ RF partagé, rail d'alimentation commun) ? Utilisez batch. Les unités sont couplées, que vous les modélisiez ainsi ou non.
  2. Faut-il prouver que les unités ont été testées dans des conditions identiques ? Utilisez batch.
  3. Le banc contient-il plus d'une unité, chacune avec ses propres connexions ? Utilisez parallèle.
  4. Sinon, utilisez séquentiel.

Une erreur fréquente est de choisir le batch parce que les unités sont chargées sur un plateau. Charger n'est pas tester. Si le plateau contient huit unités et que chacune a sa propre connexion de test, c'est du parallèle avec un banc en forme de plateau, et le modéliser en batch sacrifie du débit pour rien.

Configurer l'exécution parallèle

Dans le TofuPilot Framework, chaque position testée indépendamment est un slot, le test socket qui possède une unité. Déclarer des slots transforme une procédure mono-unité en procédure parallèle :

procedure.yaml
execution:  slots:    - name: USB0    - name: USB1    - name: USB2    - name: USB3

Pour un banc avec de nombreuses positions identiques, donnez plutôt un nombre et laissez générer les clés :

procedure.yaml
execution:  slots: 80

Chaque slot identifie sa propre unité et envoie sa propre exécution. Utilisez {slot} dans les valeurs par défaut de l'unité pour dériver les numéros de série par position :

procedure.yaml
unit:  auto_identify: true  serial_number:    default_value: "BURNIN-{slot}"  part_number:    default_value: "PCB-MAIN-V2"

Les slots échouent indépendamment. Une phase en échec arrête ce slot, exécute son teardown, et laisse les autres tourner. Seul un échec dans une phase de setup ou teardown partagée, ou un plug qui ne s'initialise pas, arrête tout.

Approcher le batch avec des phases partagées

Le Framework modélise le comportement batch par la portée des phases plutôt que par un modèle distinct. Les phases de portée execution s'exécutent une fois pour tous les slots ; celles de portée slot s'exécutent par unité.

procedure.yaml
execution:  slots: 8setup:  - name: Ramp Chamber to 85C    python: phases.ramp_chamber    scope: executionmain:  - name: Measure Leakage    python: phases.measure_leakageteardown:  - name: Return Chamber to Ambient    python: phases.cool_chamber    scope: execution

La montée en température a lieu une fois, chaque unité mesure son propre courant de fuite, et l'enceinte revient à l'ambiante après la fin de tous les slots. C'est la sémantique batch pour les opérations partagées et la sémantique parallèle pour les mesures par unité, ce dont un banc batch a généralement besoin.

Cela relève de la correction, pas seulement de la propreté. Un teardown de portée slot peut s'exécuter pendant que les slots voisins testent encore : tout ce qui touche une ressource partagée — alimentation de rack, enceinte, verrou de banc — doit donc être de portée execution. Refroidir l'enceinte dans un teardown de portée slot saboterait toutes les unités encore sous test.

Phase-first et slot-first

Avec des slots configurés, un dernier réglage contrôle l'entrelacement :

procedure.yaml
execution:  strategy: phase_first  slots: 4

phase_first, la valeur par défaut, exécute la même phase sur tous les slots avant de passer à la suivante. slot_first termine complètement un slot avant de démarrer le suivant.

phase_first convient à un instrument partagé : les quatre mesures de tension se produisent ensemble, donc l'instrument est configuré une fois pour cette mesure. slot_first se rapproche du séquentiel, utile quand vous voulez un résultat complet pour la première unité au plus tôt.

Comparaison de débit

Quatre unités, test de 30 secondes, 5 secondes de chargement et déchargement :

StratégieTemps de cycleUnités/heureMatériel nécessaire
Séquentiel140s~1031 position de banc
Parallèle (4 slots)35s~4114 positions, 4 jeux d'instruments
Batch (4 unités)35s~4114 positions, instruments partagés

Parallèle et batch semblent identiques ici parce que chaque unité prend exactement 30 secondes. Ils divergent avec une variation réelle : le batch paie l'unité la plus lente à chaque cycle, et la repaie à chaque reprise.

Pièges courants

Partager un instrument sans tenir compte de la mise en file d'attente. Quatre slots lisant un seul multimètre ne mesurent pas en parallèle ; les appels sont sérialisés. Si un appel d'instrument partagé prend 2 secondes, quatre slots passent 8 secondes sur cette phase, et votre accélération parallèle disparaît silencieusement. Voir Partager des instruments entre slots parallèles pour l'arithmétique et la correction.

Teardown de portée slot sur du matériel partagé. Couper une alimentation de rack dans un teardown de slot tue les unités encore sous test. Les ressources partagées appartiennent au teardown de portée execution.

Batch utilisé par commodité de chargement. Si les unités sont indépendantes, le batch n'ajoute que de l'attente.

Supposer que le parallèle ne demande aucun changement de code. L'adressage des instruments par slot, la dérivation des numéros de série et la détection de présence sur le banc doivent tous être réellement par slot. Du code qui code en dur une adresse d'instrument fera tourner quatre slots contre la même unité physique.

Points clés

  • Séquentiel, parallèle et batch diffèrent par le nombre d'unités en cours et par leur couplage.
  • Le couplage est décidé par la physique : une enceinte ou un champ partagé impose le batch, des connexions indépendantes permettent le parallèle.
  • Le parallèle donne le plus fort débit ; le batch fait payer à chaque unité le temps de la plus lente.
  • Dans le TofuPilot Framework, le parallèle est execution.slots, et la sémantique batch vient des phases de portée execution.
  • Les ressources partagées doivent être de portée execution, sinon un slot qui termine perturbera ceux qui tournent encore.

Plus de guides

Mettez ce guide en pratique