Un ingénieur test mesure la durée de fermeture d'un relais sur un banc de validation. Il obtient 49 ms, puis 53 ms, puis 61 ms sur la même pièce, et commence à douter du relais. Le plus souvent, le relais n'y est pour rien. L'écart vient de l'endroit où vit le chronomètre : une boucle qui tourne sur un système d'exploitation de bureau.
Ce guide explique d'où vient cette erreur de temps, comment la chiffrer, et comment concevoir une chaîne d'acquisition où le matériel tient le temps, le PC se contentant de programmer et d'afficher.
1. Le problème : le chronométrage logiciel sur un OS de bureau
1.1 Ce que l'ordonnanceur fait à votre boucle
Windows, comme Linux de bureau sans noyau temps réel, est un système généraliste. L'ordonnanceur partage le processeur entre votre application de test, les pilotes, l'antivirus, les mises à jour, l'interface et des dizaines de services. Quand votre code appelle sleep(1) ou lit l'horloge dans une boucle, rien ne garantit un réveil exactement 1 ms plus tard.
Le résultat est la gigue: l'écart entre le temps demandé et le temps obtenu. Par défaut, le timer système Windows avance par pas de 15,6 ms (64 Hz) ; une application peut demander une résolution plus fine, jusqu'à environ 1 ms. Les attentes et réveils logiciels varient donc couramment de 1 à 16 ms selon la résolution du timer, la charge, les réglages d'énergie et les pilotes. C'est une plage typique, pas une borne : des retards plus longs restent possibles. À mesurer sur la plateforme réelle.
1.2 Symptômes typiques sur un banc
- Des durées d'impulsion qui varient d'un essai à l'autre alors que l'objet testé est stable.
- Deux voies lues « en même temps » qui sont en fait échantillonnées à plusieurs millisecondes d'écart.
- Des horodatages groupés sur des pas réguliers au lieu d'être répartis de façon continue.
- Des résultats qui changent quand quelqu'un ouvre un navigateur sur le PC du banc.
1.3 Exemple chiffré : l'effet de la gigue sur une limite de test
Exemple, valeurs illustratives. Un test exige une impulsion de 50 ms ± 2 ms. Le logiciel la mesure en interrogeant une entrée numérique et en lisant l'horloge du PC.
- Gigue de la boucle, pire cas supposé : ±8 ms sur le front de début et ±8 ms sur le front de fin.
- Erreur de mesure pire cas : jusqu'à 16 ms, soit huit fois la tolérance de ±2 ms (quatre fois la fenêtre totale de 4 ms).
Le test ne sait plus distinguer une bonne pièce d'une mauvaise. C'est un problème de moyen de mesure, pas de produit. Une étude de répétabilité du banc le montrerait tout de suite.
2. Principe : c'est le matériel qui chronomètre
La règle que nous appliquons sur nos bancs est simple : le logiciel PC programme et affiche ; le matériel chronomètre.
2.1 Schéma de principe décrit
Imaginez trois blocs, de gauche à droite :
- Base de temps : un oscillateur à quartz sur le matériel d'acquisition (module DAQ, microcontrôleur, FPGA ou cible temps réel).
- Horloge d'échantillonnage et logique de déclenchement : dérivées de la base de temps, elles fixent l'instant exact de chaque échantillon et du début de l'acquisition.
- Mémoire tampon et liaison PC : les échantillons sont stockés avec leur index, puis transférés au PC par blocs (USB, Ethernet, PCIe).
Le PC est à droite. Il configure les blocs 1 et 2, lance la tâche et lit le tampon. La latence de transfert peut varier de plusieurs millisecondes sans conséquence, car l'instant de chaque échantillon est défini par son index, pas par son heure d'arrivée sur le PC.
2.2 Acquisition finie cadencée par le matériel
Pour des événements courts, la méthode la plus propre est une acquisition finie, cadencée par le matériel :
durée = nombre d'échantillons / fréquence d'échantillonnage
Exemple : à 10 kéch/s, 5 000 échantillons couvrent exactement 500 ms, avec 100 µs entre deux échantillons, à la précision de l'horloge du module près. Une impulsion de 50 ms se mesure alors en comptant les échantillons entre deux fronts : résolution 100 µs, indépendante de Windows.
2.3 Choix de la base de temps
| Option | Usage type | Point fort | Point de vigilance |
|---|---|---|---|
| Module DAQ avec horloge matérielle | Mesures analogiques et numériques | Simple, géré par le pilote | Vérifier que la tâche est réellement cadencée par le matériel |
| Timer de microcontrôleur | Mesure d'impulsions, séquencement simple | Peu coûteux, déterministe | Firmware à maintenir, liaison PC |
| FPGA | Fronts rapides, nombreuses voies en parallèle | Déterminisme au cycle d'horloge (quelques dizaines de ns aux horloges FPGA courantes) | Effort de développement |
| Cible temps réel (type cRIO) | Boucles fermées, HIL | Boucle déterministe et FPGA | Coût, chaîne d'outils |
Notre équipe a analysé le chronométrage d'acquisition sur des plateformes NI cRIO et cDAQ, en comparant le cadencement matériel à la gigue côté Windows. La méthode de ce guide vient de ce type de travail.
3. Déclenchement matériel ou logiciel
3.1 Déclenchement logiciel
Le logiciel surveille une valeur et lance l'enregistrement quand une condition est remplie. L'instant de départ hérite de toute la gigue de l'OS. Acceptable pour des tendances lentes, pas pour une mesure de temps.
3.2 Déclenchement matériel
Un front numérique ou un seuil analogique, détecté par le matériel d'acquisition lui-même, démarre l'horloge d'échantillonnage. La latence est courte, fixe et connue par la documentation du matériel. À utiliser chaque fois que l'instant de départ compte. Le pré-déclenchement permet de garder les échantillons pris avant l'événement, utile pour comprendre ce qui a mené à un défaut.
3.3 Synchroniser plusieurs modules
Quand les voies sont réparties sur plusieurs modules ou châssis, partagez une seule horloge et un seul déclenchement (fond de panier commun, ligne de trigger dédiée ou distribution d'horloge). Deux modules sur leurs propres quartz dérivent l'un par rapport à l'autre, comme le montre la section 4.
4. Dérive d'horloge : l'erreur lente
Même une base de temps matérielle n'est pas parfaite. Un quartz est spécifié en ppm (parties par million).
4.1 Calcul
Une heure = 3 600 s.
- ±20 ppm : 3 600 s × 20 × 10⁻⁶ = 0,072 s, soit environ 72 ms par heure.
- ±2 ppm : 3 600 s × 2 × 10⁻⁶ = 0,0072 s, soit environ 7 ms par heure.
Exemple : un essai de cyclage dure 8 heures sur un module à ±20 ppm. L'erreur cumulée peut atteindre environ 0,58 s. Sans importance pour un relevé de température ; gênant si vous corrélez des événements avec un autre enregistreur à la milliseconde.
4.2 Que faire
- Pour les essais longs, synchroniser tous les instruments sur une même horloge, ou périodiquement sur une source de temps de référence.
- Noter quelle horloge a produit chaque horodatage.
- Ne pas mélanger horodatages PC et horodatages matériels dans un même calcul sans convertir l'un dans l'autre.
5. Critères de choix d'une chaîne d'acquisition critique en temps
- Résolution requise : en règle pratique, environ dix fois plus fine que la tolérance à vérifier (le rapport classique 10:1 entre capacité de mesure et tolérance). Un rapport d'incertitude de test (TUR) de 4:1 est souvent accepté quand 10:1 n'est pas réaliste. Le rapport retenu doit être écrit dans la spécification de test.
- Fréquence d'échantillonnage : suffisante pour résoudre le front le plus rapide utile, avec une marge pour le filtrage.
- Source de temps : horloge d'échantillonnage matérielle confirmée dans la configuration du pilote.
- Déclenchement : trigger matériel disponible sur le bon type de signal (front numérique, seuil analogique).
- Précision d'horloge (ppm) : cohérente avec la durée de l'essai et le besoin de corrélation.
- Synchronisation : horloge et trigger partagés si plusieurs modules.
- Taille du tampon : mémoire embarquée suffisante pour absorber les retards de transfert sans perte.
6. Erreurs fréquentes
- « C'est une carte DAQ, donc c'est cadencé matériel. » Beaucoup de pilotes permettent des lectures à la demande, cadencées par le logiciel. Vérifiez le mode de cadencement de la tâche.
- Horodater les échantillons à leur arrivée sur le PC. Vous mesurez la latence USB, pas le signal.
- Utiliser
sleep()pour rythmer une séquence quand le délai compte pour le produit. - Mesurer avec deux modules non synchronisés et soustraire leurs horodatages.
- Ignorer la dérive sur des essais de plusieurs heures.
- Laisser les modes d'économie d'énergie actifs sur le PC du banc, qui peuvent modifier le comportement des timers.
7. Check-list avant de faire confiance à une mesure de temps
- [ ] La résolution et la tolérance requises sont écrites dans la spécification de test.
- [ ] La tâche d'acquisition est cadencée par le matériel (vérifié dans la configuration, pas supposé).
- [ ] Le départ se fait sur un déclenchement matériel quand le temps compte.
- [ ] Toutes les voies comparées partagent la même horloge.
- [ ] La précision d'horloge a été convertie en erreur sur la durée de l'essai.
- [ ] La méthode a été vérifiée avec un signal de référence connu (par ex. une impulsion issue d'un générateur étalonné).
- [ ] Le rapport indique la source de temps et la résolution.
8. Pour aller plus loin
Le chronométrage n'est qu'une partie de la preuve qu'un banc mesure juste. Notre guide Qualifier un banc de test avant la production (FAT/SAT) couvre la vérification complète. Les contraintes temps réel sont aussi au cœur de l' architecture des bancs HIL, et notre guide sur l'automatisation des tests montre comment garder le temps dans le matériel quand le séquenceur tourne sur PC. Pour la place de ces vérifications dans la réception, voir ATP vs QTP et notre Méthodologie ATP.
RAYNOV conçoit des systèmes de validation sur mesure, du cahier des charges à la mise en service, et accompagne aussi les équipes en Validation en tant que service.
Des mesures de temps dont vous doutez ? Parlez à nos ingénieurs.
Références externes : documentation Microsoft sur la résolution du timer Windows, timeBeginPeriod; module time de Python (résolution des horloges et perf_counter).
