Changer de plateforme de données de test ne devrait pas obliger à repartir de zéro sur l'historique du parc. Les courbes de tendance, les courbes de dégradation par numéro de série et les indices de capabilité ne valent que ce que vaut l'historique qui les porte. Ce guide montre comment reprendre des résultats hérités via l'API runs en conservant intactes leurs dates de test d'origine.
Le mécanisme clé : le champ started_at d'un run est l'horodatage utilisé par les analyses, et l'API accepte les dates passées. La date de téléversement est stockée séparément, donc un run testé en 2024 et importé aujourd'hui se place en 2024 sur tous les graphiques.
Prérequis
- Une clé API (Paramètres, clés API)
- La procédure créée dans TofuPilot, et son identifiant de procédure
- Des résultats hérités exportés dans un format analysable (CSV, dump de base de données, fichiers de rapport)
Étape 1 : Mapper les champs hérités
Le mapping minimal viable :
| Champ hérité | Champ de l'API runs |
|---|---|
| Date/heure de test | started_at, ended_at (ISO 8601) |
| Verdict global | outcome (PASS, FAIL, ERROR) |
| Numéro de série de l'unité | serial_number |
| Numéro de pièce | part_number |
| Étapes de test | phases[] avec nom, verdict, horodatages |
| Valeurs mesurées et limites | measurements[] par phase, avec validateurs |
Gardez des noms de phase et de mesure identiques à ce que le banc en production enregistrera par la suite. Les analyses regroupent par nom, donc Contact Drop A2 dans l'import et contact_drop_a2 venant du nouveau banc se retrouveraient dans deux séries différentes.
Étape 2 : Créer les runs avec les horodatages d'origine
import_legacy.py27 lines
from tofupilot import TofuPilotclient = TofuPilot(api_key="...")for row in legacy_rows: client.runs.create( procedure_id="550e8400-e29b-41d4-a716-446655440000", serial_number=row.serial, part_number=row.part_number, outcome=row.verdict, # "PASS" / "FAIL" started_at=row.tested_at, # date d'origine, ISO 8601 ended_at=row.finished_at, phases=[{ "name": "Contact Voltage Drop", "outcome": row.phase_verdict, "started_at": row.tested_at, "ended_at": row.finished_at, "measurements": [{ "name": "Contact Drop A2", "outcome": row.a2_verdict, "measured_value": row.a2_mv, "units": "mV", "validators": [{"operator": "<=", "expected_value": 100, "outcome": row.a2_verdict}], }], }], )Les unités sont créées automatiquement à partir des numéros de série, donc un numéro de série ayant cinq passages historiques se retrouve avec un historique de cinq runs, sans configuration d'unité séparée.
Étape 3 : Vérifier dans les analyses
Réglez la plage de dates dans les analyses de runs ou le contrôle des mesures pour couvrir la période importée, et vérifiez trois choses :
- Le nombre de runs par mois correspond au système hérité
- L'historique par numéro de série est complet : prenez une unité dont vous connaissez les passages répétés et confirmez que chaque passage y figure
- Les limites sont bien passées : les mesures affichent leurs validateurs, donc le Cpk et les taux de réussite se calculent sur les bonnes limites
Étape 4 : Basculer le banc en production
Une fois l'historique vérifié, pointez le banc en production vers la même procédure. Les nouveaux runs prolongent la même série : le premier run réel sur un numéro de série importé prolonge sa tendance existante au lieu d'en démarrer une nouvelle, ce qui est tout l'intérêt d'importer avec de vrais horodatages.
Deux détails à connaître :
- Les runs importés enregistrent l'utilisateur de la clé API comme créateur, et la date de téléversement comme
created_at. Les deux sont visibles sur la page de détail du run ; ni l'un ni l'autre n'affecte les analyses, qui utilisentstarted_at. - L'attribution à une station nécessite un téléversement avec une clé de station. Pour des données historiques cela importe rarement, mais enregistrez le site ou le banc d'origine comme mesure ou comme métadonnée de run si vous devez filtrer dessus plus tard.
