Test Data & Analytics

Analyse de télémétrie matérielle

Apprenez à collecter, stocker et analyser les données de télémétrie de capteurs matériels à l'aide des tableaux de mesures et tableaux de bord TofuPilot.

JJulien Buteau
intermediate10 min de lecture18 novembre 2025

Les données de capteurs issues des tests matériels ne sont utiles que si vous pouvez identifier des tendances sur des milliers d'exécutions. Stocker la télémétrie sous forme de mesures structurées et indexées est ce qui permet de révéler les tendances avant qu'elles ne deviennent des problèmes de production.

La télémétrie matérielle en pratique

Une seule exécution de test matériel peut produire des centaines de relevés de capteurs : courbes de température, traces de tension, spectres de vibration, formes d'onde de pression. Sans système structuré, ces données finissent dans des fichiers CSV sur des disques partagés, impossibles à interroger à grande échelle.

Traitez chaque mesure de capteur comme un objet de première classe. Chaque relevé reçoit un nom, une unité, des limites et une dimension de tableau optionnelle pour les données temporelles ou multi-axes.

Ingestion des données de capteurs

Utilisateurs OpenHTF

Les mesures OpenHTF transitent automatiquement. Les tableaux multidimensionnels (formes d'onde 1D, matrices 2D, tenseurs ND) sont traités sans modification de code.

telemetry_test.py
27 lines
import openhtf as htffrom tofupilot.openhtf import upload@htf.measures(    htf.Measurement("temperature_curve").with_dimensions("time_s"),    htf.Measurement("vibration_spectrum").with_dimensions("freq_hz"),)def sensor_sweep(test):    for t in range(100):        test.measurements.temperature_curve[t] = read_thermocouple()    for f in range(500):        test.measurements.vibration_spectrum[f] = read_accelerometer_fft(f)def main():    test = htf.Test(        sensor_sweep,        procedure_id="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",  # UUID de procédure du dashboard        part_number="DUT-100",    )    test.add_output_callbacks(upload())    test.execute(lambda: "DUT-001")if __name__ == "__main__":    main()

Installez-le avec pip install "tofupilot[openhtf]". Le callback upload() lit TOFUPILOT_API_KEY dans l'environnement.

Utilisateurs du SDK Python

Si vous n'utilisez pas OpenHTF, créez l'exécution directement. Les données dimensionnelles entrent comme mesures sous une phase :

upload_telemetry.py
35 lines
import osfrom datetime import datetime, timedelta, timezoneimport numpy as npfrom tofupilot.v2 import TofuPilotstarted = datetime.now(timezone.utc) - timedelta(seconds=30)ended = datetime.now(timezone.utc)waveform = np.sin(np.linspace(0, 2 * np.pi, 1000))ripple_pk_pk = float(waveform.max() - waveform.min())with TofuPilot(api_key=os.getenv("TOFUPILOT_API_KEY")) as client:    client.runs.create(        procedure_id="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",        serial_number="PSU-2025-0042",        part_number="PSU-100",        outcome="PASS",        started_at=started,        ended_at=ended,        phases=[{            "name": "Output Ripple",            "outcome": "PASS",            "started_at": started,            "ended_at": ended,            "measurements": [{                "name": "Ripple Peak to Peak",                "measured_value": ripple_pk_pk,                "units": "mV",                "validators": [                    {"operator": "<=", "expected_value": 50},                ],            }],        }],    )

Notez ce que fait cet exemple avec la forme d'onde : il envoie le scalaire extrait, pas les mille échantillons bruts. C'est délibéré, et c'est l'habitude la plus utile en télémétrie. Stockez les caractéristiques que vous interrogerez réellement (crête à crête, temps de montée, dépassement) comme mesures avec limites, et gardez la capture complète en pièce jointe sur les échecs ou par échantillonnage. Une plateforme d'enregistrement sert aux résultats ; ce n'est pas un stockage d'acquisition temporelle, et envoyer chaque échantillon de chaque unité dépassera vite son utilité.

Interrogation de la télémétrie à grande échelle

Une fois ingérée, chaque mesure est interrogeable. Filtrez par procédure, numéro de série, plage de dates ou verdict.

RequêteCe qu'elle affiche
Toutes les exécutions d'une procédure sur les 7 derniers joursTendances de la tension d'ondulation sur la production
Exécutions échouées avec temperature_curve hors limitesUnités ayant dépassé les spécifications thermiques
Distribution des mesures pour vibration_spectrumHistogramme des amplitudes de vibration sur l'ensemble du parc

Détecter la dérive de télémétrie

Les distributions de mesures sont suivies dans le temps. Quand un relevé de capteur commence à dériver vers ses limites, vous pouvez le détecter avant que cela ne cause des défaillances.

L'approche pratique consiste à alerter sur la tendance plutôt que sur le seuil. Quand un relevé franchit sa limite, la dérive est généralement présente depuis des semaines. Regardez la moyenne et la dispersion séparément : une moyenne qui bouge avec une dispersion serrée indique un changement d'état, comme un instrument recalibré ou un nouveau lot de composants, tandis qu'une moyenne stable avec une dispersion qui s'élargit indique quelque chose devenu inconstant, comme un montage usé ou la température au fil d'une équipe.

C'est particulièrement vrai pour les capteurs de température, où une dérive progressive de l'étalonnage passe inaperçue jusqu'à ce que des unités échouent sur le terrain.

Là où ça paie

Un test de cyclage thermique sur 8 zones produit 8 mesures temporelles par exécution, une par zone. La version manuelle consiste à télécharger des CSV depuis chaque contrôleur de chambre, les fusionner dans un tableur et vérifier les limites à la main.

Avec les mesures envoyées par exécution, les limites sont évaluées à l'ingestion et l'historique zone par zone est interrogeable sur tout l'enregistrement de production. Le gain n'est pas que l'analyse devienne possible ; c'est qu'elle cesse de dépendre de quelqu'un qui pense à la faire.

Plus de guides

Mettez ce guide en pratique