Scaling & Monitoring

Surveillance et performance des stations

Découvrez comment surveiller la santé des stations de test, suivre les métriques de disponibilité et détecter les dégradations de performance avec les.

JJulien Buteau
intermediate8 min de lecture14 mars 2026

Une station de test qui se dégrade silencieusement est pire qu'une station en panne. Des tests lents grignotent le débit. Des rendements en baisse masquent les causes racines. Vous avez besoin de visibilité sur la santé des stations avant que les problèmes n'atteignent votre ligne de production.

Ce guide couvre ce qu'il faut surveiller, comment capturer les métriques de santé de la station dans vos tests OpenHTF, et comment détecter les dérives à l'aide des analyses de TofuPilot.

Que surveiller

Quatre métriques vous disent l'essentiel de ce que vous devez savoir sur une station de test.

Débit de test. Unités par heure, par station. Une baisse signifie que quelque chose a changé : tests plus lents, plus de retests ou retards opérateur.

Tendances du taux de réussite. Le FPY dans le temps, pas seulement le chiffre du jour. Un déclin lent de 97 % à 93 % sur deux semaines passe facilement inaperçu dans les rapports quotidiens.

Durée moyenne de test. Suivez par phase et au total. Si votre phase de calibration est passée de 4 s à 12 s, la connexion de l'instrument se dégrade probablement.

Erreurs de station. Exceptions non capturées, timeouts d'instrument, défauts de fixture. Ceux-ci ne font pas toujours échouer le DUT, mais ils signalent des problèmes.

Capturer les métriques de santé de la station

Vous pouvez enregistrer les données de santé de la station (CPU, mémoire, disque) comme mesures OpenHTF en parallèle de vos tests DUT. Cela vous donne un instantané de l'état de la station pour chaque test.

station_health.py
import openhtf as htf
import psutil

@htf.measures(
    htf.Measurement("cpu_percent").in_range(maximum=90),
    htf.Measurement("memory_percent").in_range(maximum=85),
    htf.Measurement("disk_percent").in_range(maximum=90),
    htf.Measurement("disk_read_mb"),
    htf.Measurement("cpu_temp"),
)
def station_health_check(test):
    """Capturer les métriques de santé de la station avant d'exécuter les tests DUT."""
    test.measurements.cpu_percent = psutil.cpu_percent(interval=1)
    test.measurements.memory_percent = psutil.virtual_memory().percent
    test.measurements.disk_percent = psutil.disk_usage("/").percent
    test.measurements.disk_read_mb = psutil.disk_io_counters().read_bytes / (1024 * 1024)

    # Température CPU (Linux uniquement, retourne une liste vide sur les autres plateformes)
    temps = psutil.sensors_temperatures()
    if temps and "coretemp" in temps:
        test.measurements.cpu_temp = temps["coretemp"][0].current
    else:
        test.measurements.cpu_temp = 0.0

Ajoutez cette phase au début de votre séquence de test. Si le CPU ou la mémoire est saturé, vous le verrez dans TofuPilot avant que cela ne cause des résultats de test instables.

main_test.py
import openhtf as htf
from openhtf.util import units
from tofupilot.openhtf import TofuPilot
from station_health import station_health_check

# Vos phases de test DUT
@htf.measures(htf.Measurement("voltage_3v3").in_range(3.1, 3.5).with_units(units.VOLT))
def test_power_rail(test):
    test.measurements.voltage_3v3 = 3.28

def main():
    test = htf.Test(
        station_health_check,
        test_power_rail,
    )
    with TofuPilot(test):
        test.execute(test_start=lambda: "DUT-001")

if __name__ == "__main__":
    main()

Détecter les dérives de performance dans TofuPilot

TofuPilot suit automatiquement la durée des tests, les taux de réussite et les tendances de mesure par station. Utilisez l'onglet Analytics pour repérer les dérives :

  • Tendance de la durée de test. Filtrez par station et vérifiez si la durée moyenne de test augmente. Une augmentation de 15 % ou plus par rapport à la référence signale une dégradation de la connexion de l'instrument, une usure de la fixture ou une interférence de processus en arrière-plan.
  • FPY par station. Comparez le rendement entre les stations exécutant la même procédure. Une station avec un FPY inférieur de 3 points ou plus à ses voisines nécessite une inspection de la fixture.
  • Histogrammes de mesure. Vérifiez si les mesures de santé de la station (CPU, mémoire, disque) se rapprochent progressivement de leurs limites.
  • Pareto des défaillances. Si une station représente une part disproportionnée des défaillances, examinez la fixture et les connexions de cette station.

Liste de contrôle de surveillance

MétriqueFréquenceSeuilAction
Débit de test (unités/h)HoraireEn dessous de 80 % de l'objectifVérifier les retards opérateur, les timeouts d'instrument
Rendement au premier passagePar équipeEn dessous de 95 % (ou votre objectif)Enquêter sur les phases en tête des défaillances
Durée moyenne de testQuotidienPlus de 15 % au-dessus de la référenceVérifier les connexions d'instrument, l'usure de la fixture
Utilisation CPUPar testAu-dessus de 90 %Fermer les processus en arrière-plan, vérifier les fuites mémoire
Utilisation mémoirePar testAu-dessus de 85 %Redémarrer la station, vérifier les processus de test qui fuient
Utilisation disqueQuotidienAu-dessus de 90 %Nettoyer les journaux, archiver les anciennes données
Erreurs de stationPar testToute exception non capturéeCorriger la cause racine, ajouter la gestion d'erreurs
Taux de timeout d'instrumentQuotidienAu-dessus de 1 %Vérifier les câbles, les connexions GPIB/USB

Plus de guides

Mettez ce guide en pratique