Les capacités du protocole PTP pourraient révolutionner la gestion de nombreuses exigences de test courantes. Cet article décrit son fonctionnement et les avantages qu'il offre. Le protocole PTP synchronise avec précision les horloges temps réel intégrées à de nombreux composants de systèmes modernes. À l'instar du protocole NTP (Network Timing Protocol), il fonctionne sur Ethernet et TCP/IP. Cependant, sa précision est bien supérieure : une synchronisation à 100 ns, voire meilleure, est facilement atteignable. On pourrait penser que de tels systèmes seraient fragiles et difficiles à configurer, mais il n'en est rien. Comme nous le verrons plus loin, la configuration du système est simple et en grande partie automatique. Mais d'abord, examinons quelques concepts fondamentaux de la norme IEEE 1588.
Le protocole PTP repose sur une architecture maître-esclave. Les horloges esclaves sont synchronisées avec l'horloge maître (généralement celle dont la base de temps est la plus stable et la plus précise). La précision du PTP dépend de sa prise en compte du temps de transmission des messages sur le réseau local lors de l'évaluation de l'écart des horloges esclaves (voir figure 1).
Comme illustré, l'horloge maître envoie un message de synchronisation, « Sync », à l'esclave à intervalles réguliers. L'esclave répond par un message de demande de délai, « Delay_Req ». L'envoi et la réception de ces messages sont horodatés par les horloges. Les quatre enregistrements temporels obtenus servent ensuite à calculer le temps de transmission (le temps pendant lequel le message est effectivement transmis au niveau de la couche physique du réseau). Il est important de noter que le calcul présenté sur la figure 1 repose sur l'hypothèse d'un temps de transmission symétrique (hypothèse parfaitement raisonnable avec Ethernet). Grâce au temps de transmission et aux registres basés sur l'horodatage du message « Sync », le calcul de l'écart des horloges esclaves est simple.
Le matériel est préférable au logiciel.
Bien que cela ne soit pas une exigence stricte, pour des performances optimales, les registres de synchronisation sont gérés matériellement, au niveau de la couche physique du réseau. Pourquoi ? La clé d'une synchronisation parfaite réside dans des registres de synchronisation stables et reproductibles, présentant une variation minimale. La meilleure façon d'y parvenir est la conception matérielle (voir le schéma fonctionnel de la figure 2).
Avec une architecture Ethernet comportant une puce physique dédiée (implémentation de la couche physique), il est relativement simple de capturer le flux binaire des trames Ethernet. Le matériel de reconnaissance de motifs recherchera ensuite un motif de message Delay_Req entrant ou de message Sync sortant. Il est à noter que la norme IEEE 1588 indique clairement quels registres de synchronisation de transition de bits doivent être capturés.
Dans l'architecture décrite ci-dessus, le registre de synchronisation est capturé comme si la trame Ethernet était effectivement envoyée à la couche physique du réseau. Par conséquent, le registre de synchronisation ne peut pas être transmis avec le même message. Le message Follow-Up (voir figure 1) est utilisé pour communiquer le journal temporel (« heure d'envoi précise ») séparément du message Sync initial.
Dans certains cas, l'utilisation d'un logiciel pour l'enregistrement temporel peut s'avérer suffisante et parfaitement raisonnable. Toutefois, la précision de synchronisation obtenue sera au minimum bien moindre en raison des fluctuations temporelles inhérentes aux logiciels d'empilement de protocoles réseau.
La gigue du réseau est un facteur limitant.
Comme mentionné précédemment, l'algorithme de correction d'horloge repose sur l'hypothèse de temps de transmission symétriques. Par conséquent, les fluctuations des temps de transmission (unidirectionnels) dégradent la précision de la synchronisation. Pour des performances optimales, privilégiez une infrastructure réseau à faible gigue.
Un concentrateur Ethernet présente, de par sa conception, une latence relativement faible et stable. Il s'agit d'un simple répéteur de signal, et les trames Ethernet ne sont ni stockées ni interprétées. Un commutateur Ethernet, quant à lui, présente une latence plus élevée et, surtout, une gigue bien plus importante. Le commutateur analyse les trames entrantes et les met en file d'attente pour leur acheminement vers le port de destination approprié. Un routeur présente un niveau de gigue encore plus élevé, car il inspecte les paquets au niveau de la couche IP, puis les stocke et les transmet à l'aide de mécanismes logiciels.
Si vous souhaitez utiliser un commutateur ou un routeur pour leurs fonctionnalités supplémentaires aux couches réseau 2 et 3, respectivement, vous n'avez pas à tolérer leur gigue plus élevée et la réduction de la précision de synchronisation qui en résulte. Le protocole point à point (PTP) utilise un mécanisme appelé horloge périphérique pour neutraliser l'effet négatif des éléments de réseau présentant une gigue élevée (voir figure 3).
Une horloge périphérique est un commutateur ou un routeur doté de sa propre horloge temps réel intégrée et conforme à la norme IEEE 1588. Hormis les messages de synchronisation PTP tels que Sync et Delay_Req, son fonctionnement est identique à celui d'un commutateur ou d'un routeur classique. Cependant, pour le protocole PTP, l'horloge périphérique termine le chemin de synchronisation derrière chaque port. Le port connecté à l'horloge maître (horloge principale) fait office d'horloge esclave. Par conséquent, l'horloge interne du commutateur ou du routeur se synchronise avec l'horloge maître via ce port. Les autres ports fonctionnent comme horloges maîtres. Ainsi, toutes les horloges esclaves de leur chemin de synchronisation respectif se synchronisent avec l'horloge interne de l'horloge périphérique.
Ce mécanisme d'horloge périphérique améliore considérablement la précision de la synchronisation (au niveau d'un simple concentrateur Ethernet, voire mieux) car les messages de synchronisation IEEE 1588 ne transitent pas par l'élément de réseau (contrairement aux autres paquets IP ou trames Ethernet). De ce fait, une source importante de gigue (stockage et traitement dans l'élément de réseau) est éliminée.
Jusqu'où cela peut-il aller ?
Comme nous l'avons vu, un système conçu pour des performances maximales doit respecter deux règles importantes. Premièrement, il doit utiliser une implémentation matérielle de la norme IEEE 1588 pour les horloges maître et esclave. Deuxièmement, il doit utiliser une infrastructure réseau appropriée : un simple concentrateur Ethernet ou un élément de réseau plus complexe (commutateur ou routeur) avec une horloge périphérique. Si nous respectons ces règles, quelle précision de synchronisation pouvons-nous atteindre ?
Avec les techniques matérielles, la précision est limitée par deux facteurs : la capture d'horloge de l'implémentation physique et la stabilité de l'oscillateur ou de l'horloge locale elle-même. Lors de la mise en œuvre de Fast Ethernet, la gigue de capture d'horloge est généralement faible, inférieure à dix nanosecondes. L'effet de cette gigue peut être réduit efficacement par des méthodes statistiques. La variation de l'oscillateur local dépend fortement de la conception du système et peut facilement minimiser les problèmes de capture d'horloge. Il est à noter que l'intervalle des messages de synchronisation peut être réduit à 1 s, mais pas en dessous. Une conception à haute stabilité devra présenter une variation limitée pour compenser la stabilité de la capture d'horloge (de l'ordre de la nanoseconde). Cela pourrait nécessiter une solution relativement coûteuse basée sur un oscillateur résistant à la chaleur.
Les meilleures conceptions intégreront des méthodes statistiques appropriées afin de réduire l'impact des fluctuations de délai. La norme IEEE 1588 ne spécifie pas l'utilisation d'un algorithme de moyennage ; il s'agit donc d'un autre domaine où les fabricants peuvent apporter une contribution unique à leurs solutions.
Ces systèmes sont-ils difficiles à installer ?
L'un des aspects les plus intéressants de la norme IEEE 1588 est que la configuration du système est en grande partie automatique (sauf si vous préférez contrôler le processus de configuration). Voyons comment cela est possible.
Chaque horloge conserve des données décrivant ses capacités intrinsèques (par exemple, sa stabilité) et sa configuration actuelle (par exemple, une estimation de l'écart en temps réel par rapport à l'horloge maître, ainsi que l'identification de cette dernière). Ces paramètres (et d'autres) décrivent la qualité d'une horloge et sont « publiés » dans chaque message de synchronisation qu'elle envoie.
Lorsqu'une horloge est mise en service, elle devient maître et commence à envoyer des messages de synchronisation (contenant ses spécifications). Les autres horloges reçoivent ces paramètres de qualité et les comparent à leurs propres spécifications (à l'aide de l'algorithme « Meilleure horloge maître »). Si elles détectent une meilleure horloge maître, elles deviennent esclaves.
Quels sont les critères d'une « bonne » horloge ? Un paramètre important est le « niveau de performance de l'horloge ». Cette valeur indique si l'horloge est directement ou indirectement rattachée à une source de temps standard « officielle », telle qu'un récepteur GPS. Les horloges directement reliées à une telle source de temps absolu sont préférables. Un autre paramètre important est la « variance de l'horloge », qui indique sa stabilité intrinsèque.
Comme mentionné précédemment, les paramètres automatiques ou par défaut peuvent être modifiés. La norme IEEE 1588 définit également plusieurs messages de gestion à cet effet. Ceux-ci permettent d'interroger les données de l'horloge, d'ajuster le réglage de l'heure réelle et de modifier son état ou d'autres paramètres de fonctionnement via le réseau local.
Alors, à quoi sert cette technologie ?
L’acquisition de données est une application évidente de la norme IEEE 1588. De nombreuses applications d’acquisition de données nécessitent la distribution de capteurs sur une vaste zone (par exemple, dans des installations industrielles ou pour les communications filaires/sans fil). Mais même dans les applications centralisées, il est nécessaire de synchroniser différents instruments ou unités d’acquisition de données. Dans la quasi-totalité des applications, il est crucial de connaître le moment précis où chaque mesure a été effectuée. La haute précision temporelle offerte par l’IEEE 1588 ouvre de nouvelles perspectives pour le post-traitement et l’analyse, permettant ainsi une meilleure compréhension. Sans l’IEEE 1588, il faudrait synchroniser les instruments à l’aide de récepteurs GPS distincts ou d’un signal de déclenchement centralisé. La première option est coûteuse, et la seconde est complexe en raison du délai de propagation et du bruit de gigue du déclenchement.
Les tests fonctionnels constituent un autre domaine qui bénéficiera grandement de l’IEEE 1588. Il est souvent nécessaire d’appliquer des stimuli selon une séquence prédéfinie et avec une grande précision temporelle. Il est également nécessaire de mesurer ou d'enregistrer la réaction d'un dispositif testé (DUT) à un instant précis. Même les scénarios les plus complexes sont faciles à mettre en œuvre grâce au déclenchement temporel permis par la norme IEEE 1588. Sans cette dernière, il peut être nécessaire de générer un ou plusieurs signaux de déclenchement matériels et de les acheminer vers les différents instruments de manière appropriée. Le déclenchement temporel offre une flexibilité bien supérieure car il n'est pas limité par le câblage physique et ne souffre pas des problèmes de qualité du signal.
Résumé :
La norme IEEE 1588 est une technologie fascinante. Si vous travaillez dans le domaine des applications système, vous devriez absolument l’envisager. Cette technologie et ses fonctionnalités pourraient vous simplifier la vie. La liaison point à point (PTP) permet l’enregistrement temporel à l’échelle du système et le déclenchement temporel précis sans nécessiter de câblage complexe. Elle offre ainsi une flexibilité sans précédent dans ce domaine.
L'auteur,
Stefan Kopp, est titulaire d'un diplôme en informatique de l'Université de formation coopérative de Stuttgart, en Allemagne. Il travaille chez Agilent (anciennement HP) depuis 1989, où il a occupé différents postes, notamment celui de chef de projet pour les solutions de test personnalisées et de commercial. Il est actuellement consultant en automatisation des tests et composants de systèmes de test.
