Un poste de test est documenté quand n'importe qui dans l'équipe peut le reconstruire sur un nouveau PC et changer une limite sans appeler la personne qui l'a construit. C'est tout le test, et la plupart des postes y échouent. Ce guide donne la checklist de passation, un modèle de README, et la raison pour laquelle une organisation de poste en fichiers texte fait l'essentiel du travail à votre place.
L'objectif
Deux questions décident si un poste a été transmis. Un collègue peut-il le reconstruire sur le PC de rechange à partir de ce qu'il y a dans le dépôt ? Peut-il changer une limite, la livrer, et prouver ensuite quelles unités ont tourné avec l'ancienne version et lesquelles avec la nouvelle ?
Tout le reste est un plus. Une photo du câblage aide. Un rapport de validation de 40 pages aide moins que les deux réponses ci-dessus, parce que personne ne l'ouvre à 2 h du matin quand le montage est en panne.
Le facteur bus est le score à l'échelle de l'usine. Ce guide explique comment le faire monter pour un poste, avant ou après le départ de la personne qui l'a construit.
La checklist de passation
Descendez le tableau. « Où ça vit » est un seul endroit, pas « le partage réseau et aussi le portable de Marc ».
| Élément | Où ça vit | Terminé quand |
|---|---|---|
| Séquence des phases et leur ordre | procedure.yaml, sous main: | Un collègue lit la liste et sait dire ce que fait le poste sans ouvrir un fichier .py |
| Limites et unités par mesure | procedure.yaml, sous validators: | Chaque limite porte un commentaire qui nomme sa source (section de spec, tableau de datasheet, ou l'ingénieur et la date) |
| Liste des instruments, adresses VISA, firmware | Valeurs par défaut dans plugs/*.py, reprises dans README.md | *IDN? depuis chaque plug correspond à la ligne du README |
| Câblage | docs/wiring.pdf et une photo du banc dans docs/, référencées depuis le README | Le PC de rechange peut être câblé à partir de la seule image |
| Montage | Numéro de plan, révision, plan des pointes pogo dans docs/ | Le montage sur le banc porte la même révision que le README |
| Configuration du PC de poste | README.md, « Comment lancer » | Une installation Windows fraîche arrive à un run vert à partir du README, sans coup de fil |
| Processus de release | README.md, « Comment livrer », plus les tags Git | Le tag sur le PC de poste correspond à version: dans procedure.yaml |
| Historique des résultats | TofuPilot, par unité et par poste | N'importe qui peut ouvrir un numéro de série et voir chaque run avec la version de procédure qui l'a produit |
| Dates d'étalonnage | README.md, un tableau | Chaque prochaine échéance est dans le futur |
| Modes de défaillance connus | README.md, un tableau | Les trois premières défaillances du Pareto TofuPilot sont listées avec leur cause habituelle |
Modèle de README de poste
Copiez-le dans le dépôt du poste. Remplissez-le d'une traite ; un README à moitié rempli vieillit mal.
README.md58 lines
# Poste FCT 3, PCBA-100Responsable : ingénierie test (l'équipe, pas une personne). Dernière revue : 2026-09-15.## CâblageVoir `docs/wiring.pdf`, révision C. Photo du banc dans `docs/bench.jpg`.| De | Vers | Câble ||---|---|---|| DMM HI / LO | Montage J3 broches 1, 2 | Banane 1 m, rouge / noir || PSU CH1 | Montage J1 | 18 AWG, 0,5 m || PC de poste | Console DUT | USB vers UART, COM3 |## Instruments| Instrument | Adresse VISA | Firmware | Étalonnage avant le ||---|---|---|---|| DMM Keysight 34465A | TCPIP::192.168.1.100::INSTR | A.03.03 | 2027-02-01 || PSU Keysight E36313A | TCPIP::192.168.1.101::INSTR | 1.0.6 | 2027-02-01 || Console DUT | ASRL3::INSTR (COM3, 115200 8N1) | s.o. | s.o. |## MontagePlan FIX-0042 rév. B. Plan des pointes pogo dans `docs/FIX-0042-pinmap.pdf`.Pointes pogo de rechange : tiroir 2, référence P-0910.## LimitesToutes les limites vivent dans `procedure.yaml`. Chacune porte un commentaireavec sa source. Ne changez pas une limite sans changer le commentaire.| Mesure | Limite | Source ||---|---|---|| rail_3v3 | 3,2 à 3,4 V | Spec PCBA-100 rév. 4, section 5.1 || idle_current | <= 45 mA | Datasheet MCU tableau 12, plus 20 % de marge |## Comment lancer curl -fsSL https://www.tofupilot.app/install | sh git clone <repo url> && cd fct-station-3 tofupilot run ./procedure.yaml --uploadLes runs arrivent dans TofuPilot sous la procédure « PCBA-100 FCT », une page par unité.## Comment livrer1. Branche, changement, pull request. Un relecteur de l'ingénierie test.2. Incrémentez `version:` dans `procedure.yaml`.3. Fusionnez, taguez `vX.Y.Z`, tirez le tag sur le PC de poste.4. Lancez trois unités de référence. Comparez leurs runs dans TofuPilot avec le tag précédent.## Modes de défaillance connus| Symptôme | Cause habituelle | Correctif ||---|---|---|| rail_3v3 lit 0,00 V | Pointe pogo 7 usée | Remplacer, référence P-0910 || Timeout du DMM sur la première unité de la journée | DMM en veille | Redémarrer le DMM |Le README est court à dessein. Quatre autres supports portent le reste.
Pourquoi l'organisation du Framework fait l'essentiel
Un poste TofuPilot Framework est un dossier : procedure.yaml, phases/*.py, plugs/*.py. Tout en texte, tout sous Git. Chaque partie porte exactement un type d'information, si bien que le README n'a à couvrir que ce qu'aucune d'elles ne peut porter.
| Support | Ce qu'il contient | Ce que ça remplace |
|---|---|---|
procedure.yaml | La séquence, les champs de l'unité, chaque mesure avec son unité et ses limites | Le tableur de spec de test et la question « quelle étape tourne en premier » |
plugs/*.py | Adresses VISA, chaînes SCPI, timeouts, close() | La liste d'instruments griffonnée sur le montage |
| Git | Qui a changé quelle limite, quand, relu par qui ; git blame sur la ligne | L'onglet de journal des modifications que personne ne met à jour |
| TofuPilot | Chaque run par unité et par poste, avec la version de procédure, FPY, Cpk, Pareto | Le dossier TDMS sur le disque local du poste |
Ce qui reste au README est physique : câblage, montage, étalonnage, les modes de défaillance qu'un opérateur voit. C'est pour cela que le modèle ci-dessus tient sur un écran.
procedure.yaml comme documentation vivante
Traitez la procédure comme la spec. Un relecteur qui ne lit pas le Python peut quand même lire ce fichier, et un changement de limite est un diff d'une ligne avec un commentaire.
procedure.yaml39 lines
# La procédure est la spec. Chaque limite nomme sa source dans un commentaire.name: PCBA-100 FCTversion: 2.3.0unit: serial_number: default_value: "SN-000001" part_number: default_value: "PCBA-100"plugs: - name: dmm python: plugs.dmm:Multimeter # 34465A en 192.168.1.100 - name: psu python: plugs.psu:PowerSupply # E36313A en 192.168.1.101main: - key: power_rails name: Power Rails python: phases.power_rails measurements: - name: rail_3v3 unit: V validators: - operator: ">=" expected_value: 3.2 # spec PCBA-100 rév. 4, section 5.1 - operator: "<=" expected_value: 3.4 # idem - key: idle_current name: Idle Current python: phases.idle_current depends_on: [power_rails] measurements: - name: idle_current unit: mA validators: - operator: "<=" expected_value: 45 # datasheet MCU tableau 12, plus 20 % de margeQuand la qualité demande « pourquoi 45 mA », la réponse est sur la ligne. Quand elle demande « depuis quand », git log -p procedure.yaml répond. Quand elle demande « quelles unités ont été expédiées avec 50 mA », les pages de run dans TofuPilot portent la version de procédure, donc la réponse est un filtre, pas un chantier d'archéologie.
Ce qu'un projet LabVIEW rend difficile ici
Rien de tout cela n'est impossible en LabVIEW. C'est plus de travail, pour trois raisons concrètes.
Les VI sont binaires. Un diff demande l'outil de comparaison de NI et une licence, donc les revues se font en ouvrant les deux versions côte à côte, et git blame sur une limite n'est pas disponible. La plupart des équipes sautent la revue.
Les limites ont tendance à vivre dans les VI, ou dans un fichier Excel à côté de la séquence. Dans les deux cas la spec et le code dérivent, et le commentaire qui nomme la section de datasheet n'a aucun endroit naturel où aller.
Les résultats ont tendance à finir en TDMS ou en CSV sur le disque local du poste. L'historique par unité veut dire trouver le bon fichier sur le bon PC. Quand le PC est remplacé, l'historique ne l'est généralement pas.
Un poste LabVIEW peut quand même satisfaire la checklist. Quelqu'un doit écrire le README à la main, garder le tableau des limites synchronisé à la main, et copier les résultats quelque part de partagé à la main. L'organisation Python rend ces trois choses automatiques, ce qui fait la différence entre une passation qui a lieu et une passation qui reste planifiée.
Une revue de cinq minutes avant chaque release
Faites-la avant de taguer. Cinq minutes, à chaque fois, par le relecteur et pas par l'auteur.
- Ouvrez le diff de la pull request. Chaque limite modifiée a un commentaire modifié sur la même ligne.
version:dansprocedure.yamla augmenté.- Le tableau des instruments du README correspond toujours au
*IDN?de chaque plug. Lancez-les. - Trois unités de référence sont passées sur la branche, et leurs runs dans TofuPilot tombent dans les histogrammes de la version précédente.
- Le nom du tag correspond à
version:. Tirez-le sur le PC de poste, pas une copie du dossier.
Si l'étape 4 échoue, le changement est réel et mérite une conversation avec la qualité avant d'être livré. C'est la revue qui fait son travail.
Commencez par un poste
Choisissez le poste au plus gros volume, ou celui qu'une seule personne sait ouvrir. Reconstruisez-le en Python avec le TofuPilot Framework, puis faites-le tourner en parallèle de la version LabVIEW sur les mêmes unités pendant deux semaines. Écrivez le README dès le premier jour et gardez-le exact ; le guide de prise en main fait de ce README la première tâche du nouvel ingénieur.
# Installer la CLI, lancer une procédure en local, puis la lancer avec upload.curl -fsSL https://www.tofupilot.app/install | shtofupilot run ./procedure.yamltofupilot run ./procedure.yaml --uploadLe guide de migration LabVIEW couvre la reconstruction étape par étape, et la page du Framework décrit l'organisation des fichiers. L'offre Lab est gratuite, et tofupilot run fonctionne sans compte.
