Tel que défini dans IEEE 802.3, Ethernet est non déterministe et donc impropre à être utilisé pour des applications industrielles. Pourtant, voilà plus de trois ans que tout le monde s’affaire, pour trouver la solution qui permettrait de faire d’Ethernet un standard industriel digne de ce nom.
Tel que défini dans IEEE 802.3, Ethernet est non déterministe et donc impropre à être utilisé pour des applications industrielles. Et encore moins pour des applications temps réel ! N’insistons pas, Ethernet pour l’industrie, ce n’est pas sérieux.
Voilà donc d’emblée ce que l’on aurait pu se dire, balayant d’un revers de main l’idée qu’Ethernet pourrait un jour devenir le nouveau standard de la communication pour l’industrie. Et pourtant, voilà maintenant plus de trois ans que tout le monde s’affaire, retourne le problème en tous sens pour tenter de trouver la solution qui permettrait de faire d’Ethernet un standard industriel digne de ce nom.
Pourquoi ? Parce qu’Ethernet permet d’atteindre des vitesses de transmission élevées, parce qu’il permet aussi de réduire drastiquement les coûts de développements et de la communication en général. Mais ce n’est pas tout. Ethernet est également synonyme d’ouverture vers les réseaux d’entreprises et vers le monde au travers d’Internet. Enfin, Ethernet est une technologie qui doit permettre l’interopérabilité des systèmes, quelles que soient la nature et l’origine des éléments hardware et software employés.
On jurerait avoir déjà entendu ce refrain tant il est vrai qu’il ressemble à s’y méprendre à celui qu’entonnaient il y a quelques temps déjà les défenseurs des bus de terrain. Et, preuve que l’histoire se répète, on assiste aujourd’hui à une véritable course technologique, similaire à celle menée il y a une quinzaine d’années, dans laquelle sont engagés de nombreux organismes de standardisation tels que l’ODVA, l’EPSG ou encore Profibus International.
Dans l’état actuel des développements, les industriels disposent de solutions baptisées Ethernet/IP, ProfinetV3, Ethernet Powerlink ou encore EtherCat. Il s’agit de technologies dérivées d’Ethernet-TCP/IP, spécialement adaptées aux contraintes spécifiques des applications de terrain, allant de la communication inter-équipements au contrôle distribué, en passant par le contrôle de mouvements, etc.
Mais malgré tous les efforts fournis pour rendre ces solutions déterministes, seuls quelques rares bus de terrain ainsi que certaines solutions propriétaires étaient jusqu’alors capables d’atteindre des temps de cycles inférieurs à la milliseconde, avec des valeurs de jitters de l’ordre de la microseconde.
Dans le cas d’Ethernet, il existe un degré de variation sur les temps de transmission qui ne permet pas d’atteindre tel quel un niveau de déterminisme satisfaisant pour des applications temps réel dur. Des retards sont introduits principalement par les piles de communication, mais également en raison de la présence de switches, ou encore à cause du protocole de contrôle d’accès au support CSMA/CD, qui engendre des délais aléatoires dans la transmission des messages en cas de collision.
Figure DelayJitter.bmp : « Des délais sont introduits par les piles de communication, ainsi que sur le média en raison de la présence de Hub, de Switches ou de Routeurs. »
Synchroniser les équipements favorise le déterminisme
Une solution permettant d’augmenter le déterminisme consiste à mettre en place une horloge au niveau de chaque équipement connecté au réseau, et d’implémenter un mécanisme de synchronisation précis. En soi cela n’apporte pas de déterminisme, mais le déroulement des actions peut ainsi être fortement décorrélé des aléas de transmission et de propagation des données sur le réseau. Autrement dit, cela permet de dissocier l’exécution de la communication. Par exemple, chaque équipement peut de son propre chef déclencher une action à une date précise, au lieu d’attendre que le contrôleur maître ne lui en fasse la demande, avec tous les risques que cela comporte de perte de message ou d’acheminement trop lent. Ce type de pratique peut s’avérer extrêmement intéressant notamment dans le cas de systèmes coopératifs, par exemple lorsque plusieurs entités doivent démarrer leur action au même instant. Un exemple typique est celui de plusieurs robots travaillant simultanément.
Par ailleurs, avec un tel système de synchronisation, les données acquises sont horodatées à la source, ce qui simplifie grandement la tâche, et par la même occasion la programmation du contrôleur. Le rôle de celui-ci se limite alors à un simple rôle de management de données : acceptation, stockage, analyse. L’ordre temporel de stockage des données étant directement représenté par l’étiquette temporelle portée par la trame, le contrôleur n’a plus à se soucier des détails du processus d’échantillonnage au niveau des capteurs.
Les solutions existantes
Dans les systèmes où l’on trouve de l’intelligence distribuée, le partage d’une notion de temps commune revêt une importance capitale. Tout d’abord pour la coordination des instants de mesures, mais également pour la mesure d’intervalles de temps et de quantités dérivées (délais de transmission, jitters), ou encore pour l’exécution d’actions coordonnées. La notion de temps du système permet également de déterminer l’ordre d’apparition des évènements grâce à un horodatage des données. On est ainsi à même de passer en revue le déroulement exact des évènements, par exemple afin de déterminer la ou les causes éventuelles d’une panne et remettre le système en état rapidement.
On trouve plusieurs moyens d’implémenter la notion de temps dans un système d’intelligence répartie. Les actions peuvent être déclenchées par la réception de messages : c’est ce que l’on nomme le « message-based timing ». C’est notamment le principe utilisé dans le cas des systèmes Profinet et DeviceNet.
Mais le déroulement des actions peut aussi être rythmé de façon cyclique : c’est le « cyclic-timing ». Le temps de cycle est en général déterminé par la période du système de communication employé. Ce type de mécanisme est le plus souvent mis en œuvre dans les applications de contrôle de mouvement, avec les systèmes de communication Sercos ou Powerlink.
La dernière solution, la plus flexible, consiste quant à elle à implémenter une horloge synchronisée dans chacun des nœuds du système : c’est ce que l’on appelle le système « time-based ». Le mécanisme de synchronisation « time-based » le plus répandu à ce jour est le SNTP (Simple Network Time Protocol), utilisé notamment pour la synchronisation sur Internet. Mais celui-ci ne permet d’atteindre qu’une précision de l’ordre de quelques millisecondes, ce qui est insuffisant dans le cadre d’applications industrielles telles que le contrôle de mouvement ou autres, qui peuvent nécessiter une précision de synchronisme inférieure à la microseconde.
Pour répondre aux demandes les plus exigeantes une autre solution a donc été développée : il s’agit du PTP (Precision Time Protocol), autrement baptisé IEEE 1588. Originellement développé par Agilent sur la base des travaux de John Eidson, le PTP a été adopté par la commission de standardisation (dont le président est John Eidson lui-même) en novembre 2002.
Ce standard de synchronisation, applicable à tous les systèmes de communication par réseau local supportant le mode de transmission multicast, permet d’atteindre une précision de synchronisme inférieure à la microseconde et suscite aujourd’hui un intérêt croissant de la part de nombreux offreurs de solutions de communication industrielle basées sur Ethernet. C’est notamment le cas de Profinet, EtherCat, CIPSync et Ethernet Powerlink, qui ont récemment annoncé l’adoption du protocole PTP pour la synchronisation de leurs équipements.
Tableau TabComparatif.jpeg : « Comparatifs des principales caractéristiques de SNTP et PTP »
Principes de base du PTP
Le standard décrit dans IEEE 1588, baptisé aussi PTP pour Precision Time Protocol, défini un protocole pour la synchronisation des horloges des systèmes de mesure et de contrôle répartis. Applicable à tous les systèmes de communication par réseau local supportant le mode de transmission multicast, la mise en œuvre du PTP est particulièrement intéressante dans le cas d’Ethernet, sans toutefois s’y limiter.
Le principe de base du PTP est le suivant : l’une des horloges du système, désignée comme étant l’horloge la plus fiable et précise, sert de référence pour la synchronisation de toutes les autres : cette horloge porte le nom de Grandmaster Clock. La détermination de cette horloge de référence est réalisée de manière automatique grâce à un algorithme baptisé « Best Master Clock (BMC) algorithm », qui classe les horloges du système en fonction de critères définis dans la norme (stabilité, résolution, précision, etc.). Ce classement est effectué suivant la nature de la source temporelle. La classe de niveau le plus élevé est celle des horloges atomiques.
A l’intérieur de chaque sous-réseau, l’algorithme BMC détermine quelle est l’horloge la plus précise et la désigne comme référence pour la synchronisation du sous-réseau. Toutes les horloges IEEE 1588 sont synchronisées par rapport aux horloges maîtres, qui sont elles-mêmes synchronisées par rapport à la Grandmaster Clock. Puisque cette dernière fait office de référence pour la totalité du système, elle constitue également la référence à l’intérieur du sous-réseau qui la contient.
La synchronisation est réalisée par le biais d’échanges de messages entre les horloges esclaves et l’horloge maître d’un sous-réseau. Le processus se décompose en deux phases distinctes.
La première phase, qui a pour but de corriger le décalage temporel existant entre les esclaves et le maître, est la phase de mesure de l’offset. Le maître transmet de façon cyclique (par défaut l’opération est réalisée toutes les deux secondes) un message unique de synchronisation à l’ensemble des esclaves.
Ce message contient une estimation de l’instant d’émission. Lors de l’envoi du message, le maître mesure avec précision l’instant exact auquel le message quitte la station. De l’autre côté, l’esclave mesure l’instant exact de réception. Puis le maître envoie un second message (follow-up message), contenant le résultat de la mesure de l’instant de la première émission. Ce résultat permet à l’esclave de calculer l’offset et d’ajuster son horloge. S’il n’existe pas de délai de transmission entre le maître et l’esclave, ou si celui-ci est négligeable, les deux horloges sont alors synchronisées.
Schéma Ajust.bmp : « La synchronisation est réalisée en deux étapes : le calcul de l’offset et la correction du délai de latence ».
La seconde phase vise à prendre en considération les temps de latence existant entre chaque esclave et le maître. Les esclaves envoient au maître, de manière apériodique et aléatoire, des requêtes, en notant les instants d’émission. De son côté le maître mesure l’instant de réception des requêtes et retourne à l’esclave un message contenant le résultat de cette mesure. L’esclave peut alors calculer le délai de transmission qui le sépare du maître. Cette opération est réalisée moins fréquemment que le processus de mesure de l’offset. Par défaut, l’intervalle de temps séparant deux requêtes de mesure du délai de transmission est une durée aléatoire comprise entre 4 et 60 secondes.
Globalement l’implémentation du protocole ne requiert que peu de ressources réseau, et aucune exigence minimale au niveau de la mémoire ou de la puissance de calcul n’est formulée. Par ailleurs, la configuration et la gestion du protocole sont en grande partie automatiques, et ne nécessitent que peu d’effort d’administration. La version 2002 du standard décrit également des formats de messages destinés au management, exploitables par SNMP (Simple Network Management Protocol).
Schéma Synchro1.bmp : Détail du calcul du délai et de l’offset.
Une précision de synchronisation inférieure à la microseconde
Le PTP permet d’atteindre une précision de synchronisation inférieure à la microseconde. Mais pour atteindre ce niveau d’exactitude, il convient toutefois de prendre en considération un certain nombre de facteurs.
Tout d’abord, pour atteindre une précision maximale, la mesure des instants d’émission et de réception de messages de synchronisation (horodatage) doit être réalisée au plus près du support physique. On élimine ainsi l’influence de la pile de communication et du temps de traitement logiciel.
Dans le cas d’une implémentation avec support hardware, l’horodatage peut être réalisé par le biais d’une unité spéciale (TSU pour Time Stamping Unit), contenue dans une interface indépendante du media (MII pour Media Independant Interface). Celle-ci devra être connectée au couches MAC et Physique, et sera chargée de relever les instants exacts d’émission et de réception des messages de synchronisation PTP. Dans le cas d’une implémentation sans support hardware, l’horodatage peut être réalisé de façon logicielle, idéalement au niveau du point d’entrée de la routine d’interruption (ISR pour Interrupt Service Routine) servant au contrôleur MAC.
Schéma Imp
Ex.bmp : « L’implémentation du PTP peut être réalisée avec ou sans support hardware. Toutefois une solution hardware permet d’atteindre une plus grande précision de synchronisme ».
Quoi qu’il en soit la précision de la synchronisation globale du système dépend fortement de l’architecture du réseau et des technologies employées. Certains éléments tels que hubs, switches ou routeurs peuvent introduire des fluctuations dans les temps de transfert des messages. Typiquement un Hub introduit un délai d’environ 500 nanosecondes, avec une imprécision d’environ 50 nanosecondes. Les switches introduisent quant à eux des latences très variables suivant la technologie employée et l’état d’engorgement du réseau : typiquement, les temps de latence introduits sont de l’ordre de la microseconde, mais ce délai peut dépasser la centaine de microsecondes.
Dans le cas d’un routeur, les délais peuvent être encore plus importants. C’est la raison pour laquelle chaque sous-réseau délimité par un switch ou un routeur doit être isolé des autres pour la synchronisation. Cela signifie que les messages de synchronisation ne doivent jamais sortir d’une portion de réseau donnée.
Pour effectuer la synchronisation entre plusieurs sous-réseaux, les switches et les routeurs utilisent un type d’horloge spécial, baptisé Boundary Clock. Contrairement à une horloge ordinaire, une Boundary Clock peut avoir un nombre illimité de ports. Chacun des ports d’une Boundary Clock est vu comme une horloge ordinaire par les autres horloges du sous-réseau correspondant.
L’un des ports d’une Boundary Clock est en général configuré en tant qu’esclave, et relié à la Grandmaster Clock (typiquement une horloge GPS) par une liaison PTP. Tous les autres ports sont alors configurés en tant que maîtres, et sont chargés de la synchronisation des sous réseaux. Une Boundary Clock comporte au maximum un port configuré en esclave et autant de port maîtres que voulu.
Figure Switch.bmp : Exemple d’implémentation avec switch
Une technologie qui a de l’avenir
A l’heure actuelle, les expérimentations faites du PTP ne sont pas très nombreuses, et un certain nombre de questions demeurent en suspend, notamment concernant le comportement du système dans le cas de longues cascades de Boudary Clocks, qui peuvent entraîner une perte de précision significative. Néanmoins plusieurs propositions ont été faites pour remédier à cette difficulté.
D’autres études sont menées parallèlement au sein des groupes chargés du développement du standard. Ces évolutions concernent essentiellement la spécification du mapping PTP dans le cas d’autres protocoles qu’Ethernet UDP/IP (mapping défini dans la version 2002 de la norme), qui nécessite la précision du format des données, des adresses, des points d’horodatage, etc. Les candidats sont nombreux : Ethernet Powerlink, Ethernet/IP, Profinet, Ethercat, et bien d’autres encore. Les autres axes d’évolutions concernent l’amélioration de la précision et de la stabilité, avec une barre placée au niveau de la nanoseconde !
A titre d’exemple, mais ce n’est pas le seul, la société Hirschmann fait partie des premières à avoir introduit le PTP dans ses produits et à avoir optimisé les algorithmes associés. Pour cela une couche logicielle a été développée ainsi qu’un circuit intégré permettant d’implémenter la méthode avec une grande précision. Les tests effectués par Hirschmann ont démontré qu’une précision inférieure à la centaine de nanosecondes était d’ores et déjà atteignable grâce à l’implémentation hardware. Des tests ont également été menés sans support hardware : dans ce cas l’efficacité de l’horodatage software permet semble-t-il d’atteindre une précision de l’ordre de 5 à 50 microsecondes.
Christian Groeppelin
Dossier réalisé sur la base de documents fournis par Hans Weibel, professeur à l’université des sciences appliquées de Zurich et membre de l’EPSG (Ethernet Powerlink Standardisation Group), ainsi que par Dirk S.Mohl, responsable du développement des produits Ethernet Industriel au sein de la société Hirschmann Electronics.
J39p74
Tel que défini dans IEEE 802.3, Ethernet est non déterministe et donc impropre à être utilisé pour des applications industrielles. Et encore moins pour des applications temps réel ! N’insistons pas, Ethernet pour l’industrie, ce n’est pas sérieux.
Voilà donc d’emblée ce que l’on aurait pu se dire, balayant d’un revers de main l’idée qu’Ethernet pourrait un jour devenir le nouveau standard de la communication pour l’industrie. Et pourtant, voilà maintenant plus de trois ans que tout le monde s’affaire, retourne le problème en tous sens pour tenter de trouver la solution qui permettrait de faire d’Ethernet un standard industriel digne de ce nom.
Pourquoi ? Parce qu’Ethernet permet d’atteindre des vitesses de transmission élevées, parce qu’il permet aussi de réduire drastiquement les coûts de développements et de la communication en général. Mais ce n’est pas tout. Ethernet est également synonyme d’ouverture vers les réseaux d’entreprises et vers le monde au travers d’Internet. Enfin, Ethernet est une technologie qui doit permettre l’interopérabilité des systèmes, quelles que soient la nature et l’origine des éléments hardware et software employés.
On jurerait avoir déjà entendu ce refrain tant il est vrai qu’il ressemble à s’y méprendre à celui qu’entonnaient il y a quelques temps déjà les défenseurs des bus de terrain. Et, preuve que l’histoire se répète, on assiste aujourd’hui à une véritable course technologique, similaire à celle menée il y a une quinzaine d’années, dans laquelle sont engagés de nombreux organismes de standardisation tels que l’ODVA, l’EPSG ou encore Profibus International.
Dans l’état actuel des développements, les industriels disposent de solutions baptisées Ethernet/IP, ProfinetV3, Ethernet Powerlink ou encore EtherCat. Il s’agit de technologies dérivées d’Ethernet-TCP/IP, spécialement adaptées aux contraintes spécifiques des applications de terrain, allant de la communication inter-équipements au contrôle distribué, en passant par le contrôle de mouvements, etc.
Mais malgré tous les efforts fournis pour rendre ces solutions déterministes, seuls quelques rares bus de terrain ainsi que certaines solutions propriétaires étaient jusqu’alors capables d’atteindre des temps de cycles inférieurs à la milliseconde, avec des valeurs de jitters de l’ordre de la microseconde.
Dans le cas d’Ethernet, il existe un degré de variation sur les temps de transmission qui ne permet pas d’atteindre tel quel un niveau de déterminisme satisfaisant pour des applications temps réel dur. Des retards sont introduits principalement par les piles de communication, mais également en raison de la présence de switches, ou encore à cause du protocole de contrôle d’accès au support CSMA/CD, qui engendre des délais aléatoires dans la transmission des messages en cas de collision.
Figure DelayJitter.bmp : « Des délais sont introduits par les piles de communication, ainsi que sur le média en raison de la présence de Hub, de Switches ou de Routeurs. »
Synchroniser les équipements favorise le déterminisme
Une solution permettant d’augmenter le déterminisme consiste à mettre en place une horloge au niveau de chaque équipement connecté au réseau, et d’implémenter un mécanisme de synchronisation précis. En soi cela n’apporte pas de déterminisme, mais le déroulement des actions peut ainsi être fortement décorrélé des aléas de transmission et de propagation des données sur le réseau. Autrement dit, cela permet de dissocier l’exécution de la communication. Par exemple, chaque équipement peut de son propre chef déclencher une action à une date précise, au lieu d’attendre que le contrôleur maître ne lui en fasse la demande, avec tous les risques que cela comporte de perte de message ou d’acheminement trop lent. Ce type de pratique peut s’avérer extrêmement intéressant notamment dans le cas de systèmes coopératifs, par exemple lorsque plusieurs entités doivent démarrer leur action au même instant. Un exemple typique est celui de plusieurs robots travaillant simultanément.
Par ailleurs, avec un tel système de synchronisation, les données acquises sont horodatées à la source, ce qui simplifie grandement la tâche, et par la même occasion la programmation du contrôleur. Le rôle de celui-ci se limite alors à un simple rôle de management de données : acceptation, stockage, analyse. L’ordre temporel de stockage des données étant directement représenté par l’étiquette temporelle portée par la trame, le contrôleur n’a plus à se soucier des détails du processus d’échantillonnage au niveau des capteurs.
Les solutions existantes
Dans les systèmes où l’on trouve de l’intelligence distribuée, le partage d’une notion de temps commune revêt une importance capitale. Tout d’abord pour la coordination des instants de mesures, mais également pour la mesure d’intervalles de temps et de quantités dérivées (délais de transmission, jitters), ou encore pour l’exécution d’actions coordonnées. La notion de temps du système permet également de déterminer l’ordre d’apparition des évènements grâce à un horodatage des données. On est ainsi à même de passer en revue le déroulement exact des évènements, par exemple afin de déterminer la ou les causes éventuelles d’une panne et remettre le système en état rapidement.
On trouve plusieurs moyens d’implémenter la notion de temps dans un système d’intelligence répartie. Les actions peuvent être déclenchées par la réception de messages : c’est ce que l’on nomme le « message-based timing ». C’est notamment le principe utilisé dans le cas des systèmes Profinet et DeviceNet.
Mais le déroulement des actions peut aussi être rythmé de façon cyclique : c’est le « cyclic-timing ». Le temps de cycle est en général déterminé par la période du système de communication employé. Ce type de mécanisme est le plus souvent mis en œuvre dans les applications de contrôle de mouvement, avec les systèmes de communication Sercos ou Powerlink.
La dernière solution, la plus flexible, consiste quant à elle à implémenter une horloge synchronisée dans chacun des nœuds du système : c’est ce que l’on appelle le système « time-based ». Le mécanisme de synchronisation « time-based » le plus répandu à ce jour est le SNTP (Simple Network Time Protocol), utilisé notamment pour la synchronisation sur Internet. Mais celui-ci ne permet d’atteindre qu’une précision de l’ordre de quelques millisecondes, ce qui est insuffisant dans le cadre d’applications industrielles telles que le contrôle de mouvement ou autres, qui peuvent nécessiter une précision de synchronisme inférieure à la microseconde.
Pour répondre aux demandes les plus exigeantes une autre solution a donc été développée : il s’agit du PTP (Precision Time Protocol), autrement baptisé IEEE 1588. Originellement développé par Agilent sur la base des travaux de John Eidson, le PTP a été adopté par la commission de standardisation (dont le président est John Eidson lui-même) en novembre 2002.
Ce standard de synchronisation, applicable à tous les systèmes de communication par réseau local supportant le mode de transmission multicast, permet d’atteindre une précision de synchronisme inférieure à la microseconde et suscite aujourd’hui un intérêt croissant de la part de nombreux offreurs de solutions de communication industrielle basées sur Ethernet. C’est notamment le cas de Profinet, EtherCat, CIPSync et Ethernet Powerlink, qui ont récemment annoncé l’adoption du protocole PTP pour la synchronisation de leurs équipements.
Tableau TabComparatif.jpeg : « Comparatifs des principales caractéristiques de SNTP et PTP »
Principes de base du PTP
Le standard décrit dans IEEE 1588, baptisé aussi PTP pour Precision Time Protocol, défini un protocole pour la synchronisation des horloges des systèmes de mesure et de contrôle répartis. Applicable à tous les systèmes de communication par réseau local supportant le mode de transmission multicast, la mise en œuvre du PTP est particulièrement intéressante dans le cas d’Ethernet, sans toutefois s’y limiter.
Le principe de base du PTP est le suivant : l’une des horloges du système, désignée comme étant l’horloge la plus fiable et précise, sert de référence pour la synchronisation de toutes les autres : cette horloge porte le nom de Grandmaster Clock. La détermination de cette horloge de référence est réalisée de manière automatique grâce à un algorithme baptisé « Best Master Clock (BMC) algorithm », qui classe les horloges du système en fonction de critères définis dans la norme (stabilité, résolution, précision, etc.). Ce classement est effectué suivant la nature de la source temporelle. La classe de niveau le plus élevé est celle des horloges atomiques.
A l’intérieur de chaque sous-réseau, l’algorithme BMC détermine quelle est l’horloge la plus précise et la désigne comme référence pour la synchronisation du sous-réseau. Toutes les horloges IEEE 1588 sont synchronisées par rapport aux horloges maîtres, qui sont elles-mêmes synchronisées par rapport à la Grandmaster Clock. Puisque cette dernière fait office de référence pour la totalité du système, elle constitue également la référence à l’intérieur du sous-réseau qui la contient.
La synchronisation est réalisée par le biais d’échanges de messages entre les horloges esclaves et l’horloge maître d’un sous-réseau. Le processus se décompose en deux phases distinctes.
La première phase, qui a pour but de corriger le décalage temporel existant entre les esclaves et le maître, est la phase de mesure de l’offset. Le maître transmet de façon cyclique (par défaut l’opération est réalisée toutes les deux secondes) un message unique de synchronisation à l’ensemble des esclaves.
Ce message contient une estimation de l’instant d’émission. Lors de l’envoi du message, le maître mesure avec précision l’instant exact auquel le message quitte la station. De l’autre côté, l’esclave mesure l’instant exact de réception. Puis le maître envoie un second message (follow-up message), contenant le résultat de la mesure de l’instant de la première émission. Ce résultat permet à l’esclave de calculer l’offset et d’ajuster son horloge. S’il n’existe pas de délai de transmission entre le maître et l’esclave, ou si celui-ci est négligeable, les deux horloges sont alors synchronisées.
Schéma Ajust.bmp : « La synchronisation est réalisée en deux étapes : le calcul de l’offset et la correction du délai de latence ».
La seconde phase vise à prendre en considération les temps de latence existant entre chaque esclave et le maître. Les esclaves envoient au maître, de manière apériodique et aléatoire, des requêtes, en notant les instants d’émission. De son côté le maître mesure l’instant de réception des requêtes et retourne à l’esclave un message contenant le résultat de cette mesure. L’esclave peut alors calculer le délai de transmission qui le sépare du maître. Cette opération est réalisée moins fréquemment que le processus de mesure de l’offset. Par défaut, l’intervalle de temps séparant deux requêtes de mesure du délai de transmission est une durée aléatoire comprise entre 4 et 60 secondes.
Globalement l’implémentation du protocole ne requiert que peu de ressources réseau, et aucune exigence minimale au niveau de la mémoire ou de la puissance de calcul n’est formulée. Par ailleurs, la configuration et la gestion du protocole sont en grande partie automatiques, et ne nécessitent que peu d’effort d’administration. La version 2002 du standard décrit également des formats de messages destinés au management, exploitables par SNMP (Simple Network Management Protocol).
Schéma Synchro1.bmp : Détail du calcul du délai et de l’offset.
Une précision de synchronisation inférieure à la microseconde
Le PTP permet d’atteindre une précision de synchronisation inférieure à la microseconde. Mais pour atteindre ce niveau d’exactitude, il convient toutefois de prendre en considération un certain nombre de facteurs.
Tout d’abord, pour atteindre une précision maximale, la mesure des instants d’émission et de réception de messages de synchronisation (horodatage) doit être réalisée au plus près du support physique. On élimine ainsi l’influence de la pile de communication et du temps de traitement logiciel.
Dans le cas d’une implémentation avec support hardware, l’horodatage peut être réalisé par le biais d’une unité spéciale (TSU pour Time Stamping Unit), contenue dans une interface indépendante du media (MII pour Media Independant Interface). Celle-ci devra être connectée au couches MAC et Physique, et sera chargée de relever les instants exacts d’émission et de réception des messages de synchronisation PTP. Dans le cas d’une implémentation sans support hardware, l’horodatage peut être réalisé de façon logicielle, idéalement au niveau du point d’entrée de la routine d’interruption (ISR pour Interrupt Service Routine) servant au contrôleur MAC.
Schéma Imp
Ex.bmp : « L’implémentation du PTP peut être réalisée avec ou sans support hardware. Toutefois une solution hardware permet d’atteindre une plus grande précision de synchronisme ».
Quoi qu’il en soit la précision de la synchronisation globale du système dépend fortement de l’architecture du réseau et des technologies employées. Certains éléments tels que hubs, switches ou routeurs peuvent introduire des fluctuations dans les temps de transfert des messages. Typiquement un Hub introduit un délai d’environ 500 nanosecondes, avec une imprécision d’environ 50 nanosecondes. Les switches introduisent quant à eux des latences très variables suivant la technologie employée et l’état d’engorgement du réseau : typiquement, les temps de latence introduits sont de l’ordre de la microseconde, mais ce délai peut dépasser la centaine de microsecondes.
Dans le cas d’un routeur, les délais peuvent être encore plus importants. C’est la raison pour laquelle chaque sous-réseau délimité par un switch ou un routeur doit être isolé des autres pour la synchronisation. Cela signifie que les messages de synchronisation ne doivent jamais sortir d’une portion de réseau donnée.
Pour effectuer la synchronisation entre plusieurs sous-réseaux, les switches et les routeurs utilisent un type d’horloge spécial, baptisé Boundary Clock. Contrairement à une horloge ordinaire, une Boundary Clock peut avoir un nombre illimité de ports. Chacun des ports d’une Boundary Clock est vu comme une horloge ordinaire par les autres horloges du sous-réseau correspondant.
L’un des ports d’une Boundary Clock est en général configuré en tant qu’esclave, et relié à la Grandmaster Clock (typiquement une horloge GPS) par une liaison PTP. Tous les autres ports sont alors configurés en tant que maîtres, et sont chargés de la synchronisation des sous réseaux. Une Boundary Clock comporte au maximum un port configuré en esclave et autant de port maîtres que voulu.
Figure Switch.bmp : Exemple d’implémentation avec switch
Une technologie qui a de l’avenir
A l’heure actuelle, les expérimentations faites du PTP ne sont pas très nombreuses, et un certain nombre de questions demeurent en suspend, notamment concernant le comportement du système dans le cas de longues cascades de Boudary Clocks, qui peuvent entraîner une perte de précision significative. Néanmoins plusieurs propositions ont été faites pour remédier à cette difficulté.
D’autres études sont menées parallèlement au sein des groupes chargés du développement du standard. Ces évolutions concernent essentiellement la spécification du mapping PTP dans le cas d’autres protocoles qu’Ethernet UDP/IP (mapping défini dans la version 2002 de la norme), qui nécessite la précision du format des données, des adresses, des points d’horodatage, etc. Les candidats sont nombreux : Ethernet Powerlink, Ethernet/IP, Profinet, Ethercat, et bien d’autres encore. Les autres axes d’évolutions concernent l’amélioration de la précision et de la stabilité, avec une barre placée au niveau de la nanoseconde !
A titre d’exemple, mais ce n’est pas le seul, la société Hirschmann fait partie des premières à avoir introduit le PTP dans ses produits et à avoir optimisé les algorithmes associés. Pour cela une couche logicielle a été développée ainsi qu’un circuit intégré permettant d’implémenter la méthode avec une grande précision. Les tests effectués par Hirschmann ont démontré qu’une précision inférieure à la centaine de nanosecondes était d’ores et déjà atteignable grâce à l’implémentation hardware. Des tests ont également été menés sans support hardware : dans ce cas l’efficacité de l’horodatage software permet semble-t-il d’atteindre une précision de l’ordre de 5 à 50 microsecondes.
Christian Groeppelin
Dossier réalisé sur la base de documents fournis par Hans Weibel, professeur à l’université des sciences appliquées de Zurich et membre de l’EPSG (Ethernet Powerlink Standardisation Group), ainsi que par Dirk S.Mohl, responsable du développement des produits Ethernet Industriel au sein de la société Hirschmann Electronics.
