Une limite a changé en mars, et la question « quels numéros de série ont tourné avec l'ancienne limite » n'a de réponse que si chaque run enregistre la version exacte du test qui l'a produit. Sur la plupart des postes LabVIEW, ce n'est pas le cas : l'enregistrement a une date, un numéro de série et un résultat, et la version vit dans la mémoire de la personne qui se souvient quel build a été copié quand. Ce guide montre comment estampiller la version sur chaque run d'un poste LabVIEW dès aujourd'hui, et comment un poste Python sous TofuPilot le fait par défaut.
Pourquoi c'est important
La question arrive sous l'une de trois formes, et chacune vient avec une échéance.
| Situation | La question | Ce qu'il vous faut sur chaque run |
|---|---|---|
| Un retour client | Cette unité a-t-elle été testée avec la limite en vigueur, ou avec la précédente ? | La version du test et les valeurs des limites |
| Un audit | Montrez la version du test avec laquelle chaque unité expédiée a été testée | La version du test, par numéro de série, exportable |
| Une limite fausse pendant un mois | Quelles unités ont passé sous la mauvaise valeur ? | La version du test et la valeur mesurée |
La troisième est la plus coûteuse. Quelqu'un tape 3,15 V au lieu de 3,25 V le 10 février et l'erreur est découverte le 12 mars.
Si chaque run porte sa version, la réponse est un filtre : les unités qui ont tourné sur ce build et mesuré entre 3,15 V et 3,25 V, un recontrôle de quelques dizaines d'unités. Sinon, la réponse est chaque unité expédiée dans la fenêtre, plus une semaine de reconstitution à partir des dates de fichiers et des e-mails.
Dans le médical, l'aérospatial et l'automobile, le client s'attend à ce qu'on lui montre par quelle méthode de test chaque unité est passée. L'attente est la même dans toute usine qui a vu un retour s'envenimer. Enregistrer la version ne coûte rien par run et se rembourse la première fois que la question est posée.
Ce que « version du test » doit vouloir dire
La version du test est l'artefact compilé, pas le commit de la source.
Une recompilation du même commit sur une autre machine peut se comporter différemment. Un niveau de patch LabVIEW différent, un pilote différent, un SubVI résolu depuis un autre chemin, un build 32 bits là où le précédent était en 64 bits. Deux exécutables compilés depuis un seul commit sont deux versions, et seul un numéro qui s'incrémente à chaque build les distingue.
La règle est donc : un build, un numéro, estampillé dans l'artefact et copié dans chaque enregistrement qu'il produit. Gardez aussi le commit de la source, mais comme une propriété du build, pas comme son identité. Sur un poste Python, c'est exactement ce qu'est un déploiement, et le SHA du commit est l'un de ses champs.
Sur un poste LabVIEW aujourd'hui
Trois étapes, et aucune ne demande de migration.
Intégrez un numéro de build dans l'exécutable. Remplissez les informations de version dans la spécification de build et laissez-les s'incrémenter à chaque build, et faites écrire par le build le même numéro dans un version.txt à côté de l'exécutable. Au démarrage, le test le lit une fois et le garde dans une globale.
Écrivez-le dans chaque enregistrement. Une propriété test_build sur le fichier TDMS, ou une colonne dans le CSV, écrite à chaque run avec le numéro de série. L'enregistrement se décrit maintenant lui-même sans la date du fichier.
Envoyez-le à TofuPilot avec le run. L'API REST v2 accepte un champ procedure_version sur chaque run, et les VI HTTP Client peuvent envoyer ce JSON avec un en-tête Authorization: Bearer <api key>.
run.json29 lines
{ "outcome": "PASS", "procedure_id": "9f1c6a2e-4b0d-4b8e-9d3a-2f0c5e7a1b44", "procedure_version": "fct-b117", "serial_number": "SN-004512", "part_number": "CTRL-PCBA-A", "started_at": "2026-09-23T08:14:02Z", "ended_at": "2026-09-23T08:15:41Z", "phases": [ { "name": "Power Rails", "outcome": "PASS", "started_at": "2026-09-23T08:14:05Z", "ended_at": "2026-09-23T08:14:20Z", "measurements": [ { "name": "rail_3v3", "outcome": "PASS", "measured_value": 3.31, "units": "V", "validators": [ { "operator": ">=", "expected_value": 3.2, "outcome": "PASS" }, { "operator": "<=", "expected_value": 3.4, "outcome": "PASS" } ] } ] } ]}Deux choses tiennent maintenant sur chaque run dans TofuPilot. procedure_version porte le numéro de build, donc la liste des runs se filtre dessus. Et les validateurs voyagent avec la mesure, donc la limite en vigueur est sur le run lui-même, pas dans un tableur qui dit quelles limites avait le build 117.
Le poste reste sous LabVIEW. La traçabilité commence avant toute migration, et les lignes de ce même poste apparaissent à côté de celles des postes Python sur la même page de procedure.
Sur un poste Python avec TofuPilot
La version fait partie de la source du poste, et l'artefact est créé pour vous.
# La version voyage avec la procedure et est incrémentée dans le même commit que la limite.name: Controller PCBA FCTversion: 2.5.0Un push Git sur le dépôt connecté crée un déploiement, un build immuable de la procedure à ce commit avec un identifiant comme dep_9c04e8. tofupilot deploy --prod depuis un répertoire lié fait la même chose en ligne de commande. Les postes le récupèrent et le font tourner.
# Sur la machine de développement : construit un déploiement de production depuis le répertoire lié.tofupilot deploy --prod# Sur chaque poste : récupère le déploiement épinglé, puis lance avec upload.tofupilot pulltofupilot run ./procedure.yaml --uploadChaque run uploadé depuis un déploiement récupéré porte son deployment_id. « Quelles unités ont tourné avec l'ancienne limite » devient un filtre sur la liste des runs par déploiement, et tofupilot deployments ls --procedure-ids <id> --environments production liste chaque build jamais passé en production, dans l'ordre.
Le retour arrière est un ré-épinglage, pas une recompilation. Le retour arrière instantané ramène chaque poste de production sur un déploiement précédent, et les runs déjà uploadés gardent l'identifiant du déploiement qui les a produits, donc l'enregistrement du mauvais mois reste intact après la correction. Le flux de déploiement et de récupération est dans comment déployer des scripts de test Python sur des postes de production, et le côté dépôt est dans comment versionner des tests matériels avec Git et TofuPilot.
Le DUT a aussi une version. Comment suivre les versions de firmware en production enregistre le firmware de la même façon, pour qu'un run porte à la fois le test qui a jugé l'unité et le code qui tournait dessus.
Un exemple concret
La limite basse du rail 3V3 sur une PCBA contrôleur, sur un trimestre.
| Date | Déploiement | Limite basse de rail_3v3 | Ce que cela signifie pour les unités |
|---|---|---|---|
| 2026-01-06 | dep_41b2c9 | 3,25 V | Référence, 2 100 unités |
| 2026-02-10 | dep_7f3a21 | 3,15 V, une faute de frappe dans la pull request | 1 240 unités ont tourné sur ce build |
| 2026-03-12 | dep_9c04e8 | 3,25 V, corrigée | Correct de nouveau à partir de ce run |
La question du 12 mars est de savoir quelles unités ont passé sous 3,15 V avec une valeur que 3,25 V aurait rejetée. Filtrez la liste des runs sur dep_7f3a21, regardez rail_3v3 sur ces runs, et la réponse est 38 numéros de série sur 1 240.
Ces 38 sont recontrôlées. Les 1 202 autres sont démontrées, par numéro de série, avoir mesuré au-dessus de la limite correcte.
Sans le déploiement sur chaque run, la même question devient « chaque unité expédiée entre le 10 février et le 12 mars », et le recontrôle porte sur 1 240 unités. La différence est le coût d'une colonne.
La vérification de cinq minutes avant chaque mise en production
Cinq questions, posées avec le build en main et avant qu'il n'atteigne un poste.
- La version diffère-t-elle de la précédente ?
version.txtaffiche b117 là où l'atelier a b116, ouprocedure.yamlest passé de 2.4.0 à 2.5.0 dans le même commit que le changement. - Un run sur une unité de référence avec le nouveau build affiche-t-il cette version sur sa page de run dans TofuPilot ?
- Le changement est-il une ligne lisible quelque part, une entrée de CHANGELOG ou une pull request fusionnée, qui nomme la limite et la raison ?
- Le chemin du retour est-il connu ? L'exécutable précédent conservé à côté du nouveau, ou l'identifiant du déploiement précédent noté pour un retour arrière.
- La liste des postes qui vont le recevoir est-elle écrite, avec la version de LabVIEW que chacun fait tourner ? Quelle version de LabVIEW tourne sur chaque poste contient l'inventaire.
La dernière question est celle qui bloque les mises en production sur les postes LabVIEW, parce que le build doit correspondre au moteur d'exécution (RTE) de chacun d'eux. Sur un poste Python, la liste est l'ensemble des postes épinglés à la procedure, et récupérer le déploiement est la mise en production. À quoi ressemble la revue de ce changement, et pourquoi elle est difficile à obtenir sur un VI, est dans revue de code des tests LabVIEW : pourquoi elle échoue, et la raison au niveau des fichiers derrière tout cela est dans pourquoi le contrôle de version LabVIEW est si pénible.
Commencez par un poste
Choisissez le poste dont les limites ont le plus changé l'an dernier, reconstruisez-le en Python avec le TofuPilot Framework avec les mêmes limites, et faites-le tourner à côté de la version LabVIEW sur les mêmes unités pendant deux semaines. Chaque run du côté Python portera son déploiement dès le premier jour.
# Installe le CLI, puis lance le poste en local (sans compte) ou avec upload.curl -fsSL https://www.tofupilot.app/install | shtofupilot run ./procedure.yamltofupilot run ./procedure.yaml --uploadLa reconstruction pas à pas est dans comment migrer de LabVIEW vers Python pour les tests de fabrication avec TofuPilot, et le framework lui-même est sur tofupilot.com/products/framework. L'offre Lab est gratuite, et tofupilot run fonctionne sans compte.
