La gestion des données de test (TDM) consiste à collecter, stocker et analyser chaque mesure provenant de vos stations de test de production dans un système structuré unique. Sans elle, les résultats de test finissent éparpillés entre fichiers CSV, bases de données locales et drives partagés, et vous perdez la capacité de tracer les échecs, suivre les rendements ou prouver la conformité.
Le problème des tableurs et des CSV
La plupart des équipes hardware commencent avec des exports CSV ou des tableurs partagés. Cela fonctionne pour quelques unités sur une station. Cela ne passe pas à l'échelle.
Modes de défaillance courants :
- Pas de schéma standard. Chaque station enregistre des colonnes différentes. Fusionner les données nécessite un nettoyage manuel à chaque fois.
- Pas de traçabilité unitaire. Impossible de consulter l'historique complet de test d'un numéro de série unique sans chercher dans plusieurs fichiers.
- Pas de visibilité en temps réel. Le temps qu'on ouvre un tableur, les données sont déjà obsolètes. Les baisses de rendement passent inaperçues pendant des heures ou des jours.
- Pas de piste d'audit. Cellules écrasées, lignes supprimées, fichiers renommés. Les régulateurs et les clients n'accepteront pas cela comme preuve.
À 100 unités par jour sur deux stations, vous générez déjà des milliers de lignes par semaine. À 10 000 unités par jour, les tableurs ne sont pas seulement peu pratiques. Ils deviennent un risque.
À quoi ressemblent des données de test structurées
Un système TDM correctement conçu stocke chaque run de test avec une structure cohérente :
| Champ | Exemple |
|---|---|
| Numéro de série | SN-2026-00421 |
| Référence produit | PCB-RevC-Main |
| Station | Station-3-Final |
| Résultat | PASS / FAIL |
| Mesures | Tension : 3,31 V (limite : 3,0–3,6 V) |
| Horodatage | 2026-03-12T14:32:00Z |
| Opérateur | Ligne 2, Équipe A |
| Pièces jointes | Capture de forme d'onde, fichier de log |
Chaque mesure porte son nom, sa valeur, son unité et ses limites. Chaque run est lié à une unité, une station et un instant précis. C'est cette structure qui rend possibles les calculs de FPY, l'analyse Cpk et les diagrammes de Pareto des défaillances.
Comment TofuPilot capture automatiquement les données de test
Si vous utilisez OpenHTF, TofuPilot se connecte directement à votre script de test. Pas besoin de construire une couche de journalisation ni de gérer des connexions de base de données. Écrivez votre test, ajoutez la sortie TofuPilot, et chaque run est téléversé automatiquement.
import openhtf as htf
from openhtf.util import units
from tofupilot.openhtf import TofuPilot
@htf.measures(
htf.Measurement("output_voltage")
.with_units(units.VOLT)
.in_range(minimum=3.0, maximum=3.6),
htf.Measurement("current_draw")
.with_units(units.AMPERE)
.in_range(minimum=0.1, maximum=0.5),
)
def test_power_rail(test):
test.measurements.output_voltage = 3.31
test.measurements.current_draw = 0.25
def main():
test = htf.Test(test_power_rail)
with TofuPilot(test):
test.execute(test_start=lambda: "SN-2026-00421")
if __name__ == "__main__":
main()Chaque run produit un enregistrement structuré avec le numéro de série, les mesures, les limites, les unités et le résultat pass/fail. TofuPilot stocke le tout et le relie à l'historique complet de l'unité.
Ce que vous obtenez avec des données structurées
Une fois vos données de test acheminées dans TofuPilot, le tableau de bord analytique vous offre une visibilité immédiate sans écrire une seule requête :
- Tendances du rendement au premier passage par station, par produit, par fenêtre temporelle
- Cpk et cartes de contrôle pour toute mesure, afin de détecter les dérives avant qu'elles ne causent des échecs
- Pareto des défaillances montrant quelles phases de test échouent le plus souvent, classées par fréquence
- Historique unitaire pour tout numéro de série, montrant chaque run de test de l'EVT au PVT et à la production
- Histogrammes de mesures montrant la distribution par rapport aux limites
Pas besoin de construire des tableaux de bord ni d'écrire des scripts pour calculer ces métriques. Les données structurées les rendent automatiques.
TDM vs. MES vs. Bases de données custom
Le TDM n'est pas un MES. Un système d'exécution de la fabrication suit les ordres de travail, le routage et l'inventaire. Le TDM se concentre spécifiquement sur les résultats de test, les mesures et les métriques de qualité.
Construire une base de données custom fonctionne jusqu'à ce que vous ayez besoin d'analytique, de contrôle d'accès ou d'intégrations. La plupart des équipes qui commencent avec PostgreSQL et quelques scripts Python passent des mois à maintenir l'infrastructure au lieu d'améliorer leurs tests.
TofuPilot se situe entre ces approches. Il gère le stockage, la structure et l'analytique pour que vos ingénieurs de test puissent se concentrer sur l'écriture de meilleurs tests.