Introduction
Le concept de construction de la « Station numérique » dans l'énergétique requiert une synchronisation avec une précision de 1 µs. Des transactions financières nécessitent également une précision en microsecondes. Dans ces applications, la précision du temps NTP devient insuffisante.
Le protocole de synchronisation PTPv2, décrit dans la norme IEEE 1588v2, permet d'atteindre une précision de synchronisation de quelques dizaines de nanosecondes. PTPv2 permet d'envoyer des paquets de synchronisation à travers des réseaux L2 et L3.
Les principaux domaines d'application de PTPv2 sont :
- l'énergie;
- l'équipement de mesure et de contrôle;
- le complexe militaro-industriel;
- les télécommunications;
- le secteur financier.
Cet article examine comment fonctionne le protocole de synchronisation PTPv2.
Nous avons plus d'expérience dans l'industrie et nous rencontrons souvent ce protocole dans les applications énergétiques. Par conséquent, nous réaliserons notre aperçu en tenant compte de .
Pourquoi est-il nécessaire ?
Actuellement, selon le STO 34.01-21-004-2019 de PAO « Rosseti » et le STO 56947007-29.240.10.302-2020 de PAO « FSK EES », des exigences sont énoncées pour l'organisation du bus de processus avec assurance de synchronisation temporelle via PTPv2.
Cela est dû au fait que des terminaux de protection différentielle et des dispositifs de mesure sont connectés au bus de processus, qui transmettent les valeurs instantanées de courant et de tension via le bus de processus, à l'aide des soi-disant flux SV (flux multicast).
Les terminaux de protection différentielle utilisent ces valeurs pour réaliser des protections des raccordements. Si la précision des mesures dans le temps est faible, certaines protections peuvent être déclenchées par erreur.
Par exemple, des protections de sélectivité absolue peuvent être affectées par une « faible » synchronisation temporelle. Souvent, la logique de ces protections est basée sur la comparaison de deux valeurs. Si les valeurs diffèrent suffisamment, la protection se déclenche. Si ces valeurs sont mesurées avec une précision de 1 ms, une grande différence peut être observée là où les valeurs sont en réalité normales si elles sont mesurées avec une précision de 1 µs.
Versions PTP
Le protocole PTP a été initialement décrit en 2002 dans la norme IEEE 1588-2002 et portait le titre « Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems ». En 2008, une version mise à jour, l'IEEE 1588-2008, a été publiée, décrivant la version 2 du PTP. Cette version du protocole a amélioré la précision et la stabilité, mais n'a pas conservé la rétrocompatibilité avec la première version. En 2019, la norme IEEE 1588-2019 a été publiée, décrivant PTP v2.1. Cette version apporte de légères améliorations à PTPv2 et est rétrocompatible avec PTPv2.
En d'autres termes, nous avons le schéma suivant avec les versions :
PTPv1
(IEEE 1588-2002)
PTPv2
(IEEE 1588-2008)
PTPv2.1
(IEEE 1588-2019)
PTPv1 (IEEE 1588-2002)
—
Non compatibles
Non compatibles
PTPv2 (IEEE 1588-2008)
Non compatibles
—
Compatibles
PTPv2.1 (IEEE 1588-2019)
Non compatibles
Compatibles
—
Mais, comme toujours, il y a des nuances.
La non-compatibilité entre PTPv1 et PTPv2 implique qu'un appareil prenant en charge PTPv1 ne pourra pas se synchroniser à partir d'horloges précises fonctionnant sur PTPv2. Pour la synchronisation, ils utilisent différents formats de message.
Cependant, il est possible de combiner des dispositifs PTPv1 et PTPv2 sur un même réseau. Pour cela, certains fabricants permettent de sélectionner la version du protocole sur les ports des horloges frontières. Ainsi, les horloges frontières peuvent se synchroniser via PTPv2 tout en synchronisant d'autres horloges connectées par PTPv1 et PTPv2.
Dispositifs PTP. Quels types existent et quelles sont leurs différences?
La norme IEEE 1588v2 décrit plusieurs types de dispositifs. Tous sont présentés dans le tableau.
Les dispositifs interagissent entre eux via un réseau local en utilisant PTP.
Les dispositifs PTP sont appelés horloges. Toutes les horloges prennent l'heure exacte à partir des horloges maîtresses.
Il existe 5 types d'horloges :
Horloge Grandmaster (Horloge Maîtresse)
Source principale d'heure précise. Souvent équipée d'une interface pour la connexion GPS.
Horloge Ordinaire
Appareil avec un port qui peut être maître (horloge maîtresse) ou esclave (horloge esclave).
Horloge Maître
Est la source de l'heure précise, utilisée pour synchroniser d'autres horloges.
Horloge Esclave
Appareil final qui se synchronise à partir des horloges maîtresses.
Horloge de Bord (Horloge Frontière)
Appareil avec plusieurs ports qui peut être maître ou esclave.
Cela signifie que ces horloges peuvent se synchroniser à partir d'horloges maîtresses supérieures et synchroniser des horloges esclaves inférieures.
Horloge transparente de bout en bout
Appareil à plusieurs ports qui n'est ni une horloge maîtresse ni une horloge esclave. Il transmet des données PTP entre deux horloges.
Lors de la transmission des données, les horloges transparentes corrigent tous les messages PTP.
La correction se fait en ajoutant un délai sur cet appareil dans le champ de correction de l'en-tête du message transmis.
Horloge transparente pair-à-pair
Appareil à plusieurs ports qui n'est ni une horloge maîtresse ni une horloge esclave.
Il transmet des données PTP entre deux horloges.
Lors de la transmission des données, les horloges transparentes corrigent tous les messages PTP Sync et Follow_Up.
La correction est obtenue en ajoutant au champ de correction du paquet transmis le retard sur l'appareil émetteur et le retard sur le canal de transmission.
Nœud de gestion
Appareil qui configure et diagnostique d'autres horloges
Les horloges maîtresses et esclaves sont synchronisées à l'aide d'horodatages dans les messages PTP. Il existe deux types de messages dans le protocole PTP :
- Messages d'événement – ce sont des messages synchronisés qui supposent la génération d'un horodatage au moment de l'envoi et de la réception du message
- Messages généraux – ces messages ne nécessitent pas d'horodatages, mais peuvent contenir des horodatages pour les messages connexes
Messages d'événement
Messages généraux
Sync
Delay_Req
Pdelay_Req
Pdelay_Resp
Annonce
Follow_Up
Delay_Resp
Pdelay_Resp_Follow_Up
Gestion
Signalisation
Tous les types de messages seront examinés plus en détail.
Principaux problèmes de synchronisation
Lors de la transmission d'un paquet de synchronisation à travers un réseau local, il est retardé par le commutateur et dans le canal de transmission. Tout commutateur introduira un retard d'environ 10 µs, ce qui est inacceptable pour PTPv2. Nous devons atteindre une précision de 1 µs sur l'appareil final. (Cela s'applique à la sectoriel de l'énergie. D'autres applications peuvent nécessiter une précision encore plus grande.)
La norme IEEE 1588v2 décrit plusieurs algorithmes de fonctionnement qui permettent de mesurer le retard de temps et de le corriger.
Algorithme de fonctionnement
En fonctionnement normal, le protocole fonctionne en deux phases.
- Phase 1 – établir la hiérarchie "Horloge maîtresse – Horloge esclave".
- Phase 2 – synchroniser les horloges à l'aide du mécanisme de bout en bout ou pair-à-pair.
Phase 1 - Installation de la hiérarchie « Maître-Esclave »
Chaque port des horloges normales ou de frontière a un certain nombre d'états (horloges esclaves et horloges maîtresses). La norme décrit l'algorithme de transition entre ces états. En programmation, un tel algorithme est appelé automates finis ou machines d'états (voir Wiki pour plus de détails).
Cet automate fini utilise l'algorithme Best Master Clock Algorithm (BMCA) pour établir le maître lors de la connexion de deux horloges.
Cet algorithme permet aux horloges d'assumer les responsabilités des horloges grand maître lorsque les horloges grand maître supérieures perdent le signal GPS, se déconnectent du réseau, etc.
Les transitions entre états selon le BMCA sont brièvement représentées dans le schéma suivant :
L'information sur les horloges à l'autre extrémité du « fil » est envoyée dans un message spécial (message d'annonce). Lorsque cette information est reçue, l'algorithme de la machine d'états se déclenche et une comparaison est effectuée pour déterminer quelles horloges sont les meilleures. Le port sur les meilleures horloges devient l'horloge maîtresse.
Une hiérarchie simple est présentée dans le schéma ci-dessous. Les chemins 1, 2, 3, 4, 5 peuvent contenir des horloges transparentes (Transparent clock), mais elles ne participent pas à l'établissement de la hiérarchie « Horloges maîtresses - Horloges esclaves ».
Phase 2 - Synchronisation des horloges normales et de frontière
Immédiatement après l'établissement de la hiérarchie « Horloges maîtresses - Horloges esclaves », la phase de synchronisation des horloges normales et de frontière commence.
Pour la synchronisation, les horloges maîtresses envoient aux horloges esclaves un message contenant un horodatage.
Les horloges maîtresses peuvent être :
- monostatiques ;
- bivibrantes.
Les horloges monostatiques envoient un seul message Sync pour la synchronisation.
Les horloges bivibrantes utilisent deux messages - Sync et Follow_Up - pour la synchronisation.
Deux mécanismes peuvent être utilisés pour la phase de synchronisation :
- Le mécanisme de demande-réponse de délai (Delay request-response mechanism).
- Le mécanisme de mesure du délai du nœud voisin (Peer delay measurement mechanism).
Pour commencer, examinons ces mécanismes dans le cas le plus simple - lorsque des horloges transparentes ne sont pas utilisées.
Le mécanisme de demande-réponse de délai (Delay request-response mechanism)
Le mécanisme comprend deux étapes :
- Mesurer le délai de transmission du message entre les horloges maîtresses et esclaves. Cela est réalisé à l'aide du mécanisme de demande-réponse de délai.
- Effectuer une correction de décalage de temps précis.
Mesurer le délai
t1 – Heure d'envoi du message Sync par les horloges maîtres ; t2 – Heure de réception du message Sync par les horloges esclaves ; t3 – Heure d'envoi de la requête de délai (Delay_Req) par les horloges esclaves ; t4 – Heure de réception de Delay_Req par les horloges maîtres.
Lorsque les horloges esclaves connaissent les temps t1, t2, t3 et t4, elles peuvent calculer le délai moyen lors de la transmission du message de synchronisation (tmpd). Il est calculé comme suit :
Lors de la transmission du message Sync et Follow_Up, le délai de temps du maître au esclave est calculé – t-ms.
Lors de la transmission des messages Delay_Req et Delay_Resp, le délai de temps de l'esclave au maître est calculé – t-sm.
S'il existe une asymétrie entre ces deux valeurs, une erreur de correction du temps précis apparaît. L'erreur est due au fait que le délai calculé est une moyenne des délais t-ms et t-sm. Si les délais ne sont pas égaux, nous allons ajuster le temps de manière imprécise.
Correction du décalage de l'heure précise
Une fois que le délai entre les horloges maîtres et les horloges esclaves est connu, les horloges esclaves effectuent la correction de temps.
Les horloges esclaves utilisent le message Sync et le message optionnel Follow_Up pour calculer le décalage de l'heure précise lors de la transmission du paquet des horloges maîtres aux horloges esclaves. Le décalage est calculé selon la formule suivante :
Mécanisme de mesure du délai du nœud voisin (Peer delay measurement mechanism)
Ce mécanisme utilise également deux étapes pour la synchronisation :
- Les dispositifs mesurent le délai de temps vers tous les voisins par l'intermédiaire de tous les ports. Pour cela, ils utilisent le mécanisme de délai entre pairs.
- Correction du décalage de l'heure précise.
Mesure du délai entre les dispositifs prenant en charge le mode Peer-to-Peer
Le délai entre les ports prenant en charge le mécanisme peer-to-peer est mesuré à l'aide des messages suivants :
Lorsque le port 1 connaît les temps t1, t2, t3 et t4, il peut calculer le délai moyen (tmld). Il est calculé selon la formule suivante :
Ensuite, le port utilise cette valeur lors du calcul du champ de correction pour chaque message Sync ou message optionnel Follow_Up qui passe par ce dispositif.
Le délai final sera égal à la somme du délai de transmission à travers ce dispositif, du délai moyen de transmission à travers le canal de données et du délai déjà contenu dans ce message, inclus sur les dispositifs en amont.
Les messages Pdelay_Req, Pdelay_Resp et l'optionnel Pdelay_Resp_Follow_Up permettent d'obtenir le délai du maître au esclave et de l'esclave au maître (circuit complet).
Toute asymétrie entre ces deux valeurs introduira une erreur de correction du décalage temporel précis.
Correction du décalage temporel précis
Les horloges esclaves utilisent le message Sync et le message optionnel Follow_Up pour calculer le décalage temporel précis lors de la transmission d'un paquet des horloges maîtres aux horloges esclaves. Le décalage est calculé selon la formule suivante :
Les avantages du mécanisme de correction peer-to-peer – le délai de chaque message Sync ou Follow_Up est calculé en cours de transmission dans le réseau. Par conséquent, un changement de chemin de transmission n'affectera en rien la précision de la correction.
En utilisant ce mécanisme, la synchronisation temporelle ne nécessite pas de calcul du délai de temps sur le chemin parcouru par le paquet de synchronisation, comme cela se fait dans l'échange de base. C'est-à-dire que les messages Delay_Req et Delay_Resp ne sont pas envoyés. Dans cette méthode, le délai entre les horloges maîtres et esclaves est simplement additionné dans le champ de correction de chaque message Sync ou Follow_Up.
Un autre avantage – les horloges maîtres sont déchargées de la nécessité de traiter les messages Delay_Req.
Modes de fonctionnement des horloges transparentes
Par conséquent, nous avons examiné des exemples simples. Maintenant, supposons que des commutateurs apparaissent sur le chemin de synchronisation.
Si l'on utilise des commutateurs sans prise en charge de PTPv2, le paquet de synchronisation sera retardé d'environ 10 μs sur le commutateur.
Les commutateurs avec prise en charge de PTPv2, dans la terminologie IEEE 1588v2, sont appelés horloges transparentes. Les horloges transparentes ne se synchronisent pas avec les horloges maîtres et ne participent pas à la hiérarchie « Horloges Maîtres – Horloges Esclaves », mais en transmettant des messages de synchronisation, elles se souviennent du temps que le message a été retardé sur elles. Cela permet de corriger le délai temporel.
Les horloges transparentes peuvent fonctionner en deux modes :
- End-to-End.
- Peer-to-Peer.
End-to-End (E2E)
Les horloges transparentes E2E transmettent des messages Sync et des messages pertinents Follow_Up sur tous les ports. Même sur ceux qui sont bloqués par certains protocoles (par exemple, RSTP).
Le commutateur mémorise l'horodatage lorsque le paquet Sync (Follow_Up) a été reçu sur le port et quand il a été envoyé depuis le port. Sur la base de ces deux horodatages, le temps de traitement du message par le commutateur est calculé. Dans la norme, ce temps est appelé temps de résidence.
Le temps de traitement est ajouté au champ correctionField du message Sync (horloge à une étape) ou Follow_Up (horloge à deux étapes).
Les horloges transparentes E2E mesurent le temps de traitement des messages Sync et Delay_Req passant par le commutateur. Il est cependant important de comprendre que le retard entre les horloges maître et esclave est calculé à l'aide d'un mécanisme de demande-réponse de délai. Si les horloges maîtres changent ou si le chemin entre les horloges maîtres et eslaves est modifié, le délai est mesuré à nouveau. Cela augmente le temps d'état transitoire en cas de changements dans le réseau.
Les horloges transparentes P2P, en plus de mesurer le temps de traitement du message par le commutateur, mesurent le retard sur le canal de transmission jusqu'au voisin le plus proche, en utilisant un mécanisme de mesure du retard du nœud voisin.
Le retard est mesuré sur chaque canal dans les deux sens, y compris les canaux bloqués par un protocole quelconque (par exemple, RSTP). Cela permet de recalculer immédiatement le nouveau retard sur le chemin de synchronisation si les horloges grand maître ou la topologie du réseau ont changé.
Le temps de traitement des messages par les commutateurs et le temps de retard s'accumulent lors de la transmission des messages Sync ou Follow_Up.
Types de support PTPv2 par les commutateurs.
Les commutateurs peuvent prendre en charge PTPv2 :
- par logiciel ;
- par matériel.
Avec une mise en œuvre logicielle du protocole PTPv2, le commutateur demande un horodatage au firmware. Le problème est que le firmware fonctionne en boucle, et il faut attendre qu'il termine le cycle en cours, prenne la demande en charge et, à l'issue du cycle suivant, délivre l'horodatage. Cela prendra également du temps, et nous aurons un retard, même s'il n'est pas aussi significatif qu'en l'absence de support logiciel PTPv2.
Seule la prise en charge matérielle de PTPv2 permet de respecter la précision requise. Dans ce cas, la délivrance de l'horodatage est effectuée par un ASIC spécial installé sur le port.
Format du message
Tous les messages PTP se composent des champs suivants :
- En-tête – 34 octets.
- Corps – la taille dépend du type de message.
- Suffixe – optionnel.
En-tête
Le champ d'en-tête est identique pour tous les messages PTP. Sa taille est de 34 octets.
Format du champ d'en-tête :
messageType – contient le type de message transmis, par exemple Sync, Delay_Req, PDelay_Req, etc.
messageLength – contient la taille totale du message PTP, y compris l'en-tête, le corps et le suffixe (mais à l'exclusion des octets de remplissage).
domainNumber – détermine à quel un domaine PTP appartient le message.
Domaine – est un groupe d'horloges différentes rassemblées en un seul groupe logique et synchronisées à partir d'une horloge maîtresse, mais pas nécessairement synchronisées avec des horloges appartenant à un autre domaine.
flags – ce champ contient divers drapeaux pour identifier l'état du message.
correctionField – contient le temps de retard en nanosecondes. Le temps de retard inclut le retard lors de la transmission à travers des horloges transparentes, ainsi que le retard lors de la transmission à travers le canal en mode Peer-to-Peer.
sourcePortIdentity – ce champ contient des informations sur le port à partir duquel ce message a été initialement envoyé.
sequenceID – contient un identifiant pour les messages individuels.
controlField – champ-artéfact =) Il provient de la première version de la norme et contient des informations sur le type de ce message. C'est essentiellement la même chose que messageType, mais avec moins d'options.
logMessageInterval – ce champ est déterminé par le type de message.
Corps
Comme discuté précédemment, il existe plusieurs types de messages. Ces types sont décrits ci-dessous :
Message Announce
Le message Announce est utilisé pour "informer" d'autres horloges à l'intérieur d'un même domaine de leurs paramètres. Ce message permet d'établir une hiérarchie « Horloges maîtresses - Horloges esclaves ».
Message Sync
Le message de synchronisation (Sync) est envoyé par les horloges maîtresses et contient l'heure des horloges maîtresses au moment où le message Sync a été créé. Si les horloges maîtresses sont à deux niveaux, l'horodatage dans le message Sync sera égal à 0, et l'horodatage actuel sera envoyé dans le message associé Follow_Up. Le message Sync est utilisé pour les deux mécanismes de mesure du retard.
Le message est transmis via Multicast. Il est possible d'utiliser Unicast en option.
Message Delay_Req
Le format du message Delay_Req est identique à celui du message Sync. Les horloges esclaves envoient Delay_Req. Il contient l'heure d'envoi de Delay_Req par les horloges esclaves. Ce message est utilisé uniquement pour le mécanisme de demande-réponse de retard.
Le message est transmis via Multicast. Il est possible d'utiliser Unicast en option.
Message de Suivi
Le message de Suivi est envoyé en option par les horloges maîtresses et contient le temps d'envoi. messages de Synchronisation maître. Le message de Suivi n'est envoyé que par les horloges maîtresses à deux niveaux.
Le message de Suivi est utilisé pour les deux mécanismes de mesure du délai.
Le message est transmis via Multicast. Il est possible d'utiliser Unicast en option.
Message de Réponse_Délai
Le message de Réponse_Délai est envoyé par les horloges maîtresses. Il contient le temps de réception de la Demande_Délai par les horloges maîtresses. Ce message est utilisé uniquement pour le mécanisme de demande-réponse de délai.
Le message est transmis via Multicast. Il est possible d'utiliser Unicast en option.
Message de Pdelay_Req
Le message de Pdelay_Req est envoyé par l'appareil qui demande le délai. Il contient le temps d'envoi du message depuis le port de cet appareil. Pdelay_Req est utilisé uniquement pour le mécanisme de mesure de délai du nœud voisin.
Message de Pdelay_Resp
Le message de Pdelay_Resp est envoyé par l'appareil qui a reçu la demande de délai. Il contient le temps de réception du message Pdelay_Req par cet appareil. Les messages de Pdelay_Resp sont utilisés uniquement pour le mécanisme de mesure de délai du nœud voisin.
Message de Pdelay_Resp_Suivi
Le message de Pdelay_Resp_Suivi est envoyé en option par l'appareil qui a reçu la demande de délai. Il contient le temps de réception du message Pdelay_Req par cet appareil. Le message de Pdelay_Resp_Suivi n'est envoyé que par les horloges maîtresses à deux niveaux.
Ce message peut également être utilisé pour le temps d'exécution à la place de l'horodatage. Le temps d'exécution est le temps écoulé entre la réception du Pdelay-Req et l'envoi du Pdelay_Resp.
Pdelay_Resp_Suivi est utilisé uniquement pour le mécanisme de mesure de délai du nœud voisin.
Messages de Gestion
Les messages de gestion PTP sont nécessaires pour transmettre des informations entre une ou plusieurs horloges et le nœud de gestion.
Transmission en LV
Le message PTP peut être transmis à deux niveaux :
- Niveau Réseau – dans le cadre des données IP.
- Niveau Liaison – dans le cadre d'une trame Ethernet.
Transmission du message PTP via UDP à travers IP via Ethernet
PTP via UDP via Ethernet
Profils
PTP dispose de nombreux paramètres « flexibles » qui doivent être configurés. Par exemple :
- Options BMCA.
- Mécanisme de mesure de délai.
- Intervalles et valeurs initiales de tous les paramètres configurables, etc.
Et bien que nous ayons dit précédemment que les appareils PTPv2 sont compatibles entre eux, ce n'est pas tout à fait vrai. Les appareils doivent avoir les mêmes réglages pour interagir.
C'est pourquoi il existe ce que l'on appelle des profils PTPv2. Les profils sont des groupes de paramètres configurés et de certaines contraintes du protocole afin de permettre la synchronisation temporelle pour une application spécifique.
La norme IEEE 1588v2 décrit uniquement un profil – le « Profil par défaut ». Tous les autres profils ont été créés et décrits par diverses organisations et associations.
Par exemple, le profil pour l'énergie électrique ou PTPv2 Power Profile a été créé par le comité Power Systems Relaying Committee et le comité Substation Committee de la société IEEE Power and Energy Society. Le profil lui-même est nommé IEEE C37.238-2011.
Le profil décrit que le PTP peut être transmis :
- Uniquement à travers des réseaux L2 (c'est-à-dire Ethernet, HSR, PRP, pas IP).
- Les messages ne sont transmis que par multicast.
- Le mécanisme de mesure de délai utilisé est le mécanisme de mesure de délai par paire.
Le domaine par défaut est 0, le domaine recommandé est 93.
La philosophie de création de C37.238-2011 repose sur le désir de réduire le nombre de caractéristiques optionnelles et de conserver uniquement les fonctions nécessaires pour une interaction fiable entre les appareils et une augmentation de la stabilité du système.
De plus, une fréquence de transmission des messages est définie :
En réalité, un seul paramètre est disponible pour le choix – le type d'horloge maître (monostable ou biphase).
La précision ne doit pas dépasser 1 µs. En d'autres termes, un chemin de synchronisation peut contenir au maximum 15 horloges transparentes ou trois horloges de frontière.
Source : habr.com
