Détails d'implémentation du protocole de synchronisation temporelle PTPv2

Introduction

Le concept de construction d'une «sous-station numérique» dans l'industrie de l'énergie électrique nécessite une synchronisation avec une précision de 1 μs. Les transactions financières nécessitent également une précision en microsecondes. Dans ces applications, la précision du temps NTP n'est plus suffisante.

Le protocole de synchronisation PTPv2, décrit par la norme IEEE 1588v2, permet une précision de synchronisation de plusieurs dizaines de nanosecondes. PTPv2 vous permet d'envoyer des paquets de synchronisation sur les réseaux L2 et L3.

Les principaux domaines d'utilisation de PTPv2 sont:

• ingénierie électrique;
• équipement de contrôle et de mesure;
• complexe militaro-industriel;
• Telecom
• secteur financier.

Cet article examine le fonctionnement du protocole de synchronisation PTPv2.

Nous avons plus d'expérience dans l'industrie et nous rencontrons souvent ce protocole dans les applications énergétiques. En conséquence, nous ferons l'examen avec un œil sur l'énergie .

Pourquoi est-ce nécessaire?

Actuellement, STO 34.01-21-004-2019 de PJSC Rosseti et STO 56947007-29.240.10.302-2020 de PJSC FGC UES contiennent des exigences pour l'organisation d'un bus de processus avec synchronisation temporelle via PTPv2.

Cela est dû au fait que les bornes de protection des relais et les appareils de mesure sont connectés au bus de processus, qui transmettent des valeurs instantanées de courant et de tension à l'aide des flux dits SV (flux de multidiffusion) via le bus de processus.

Les terminaux de protection de relais utilisent ces valeurs pour implémenter la protection de connexion. Si la précision des mesures dans le temps est faible, certaines protections peuvent fonctionner de manière erronée.

Par exemple, la protection de la sélectivité absolue peut devenir victime d'une synchronisation temporelle «faible». Souvent, la logique de ces défenses est basée sur une comparaison de deux valeurs. Si les valeurs divergent vers une valeur suffisamment grande, la protection est déclenchée. Si ces valeurs sont mesurées avec une précision de 1 ms, vous pouvez obtenir une grande différence là où les valeurs sont réellement normales, si vous les mesurez avec une précision de 1 μs.

Versions PTP

Le protocole PTP a été décrit à l'origine en 2002 dans la norme IEEE 1588-2002 et était appelé «Norme pour un protocole de synchronisation d'horloge de précision pour les systèmes de mesure et de contrôle en réseau». En 2008, la norme IEEE 1588-2008 mise à jour, qui décrit la version 2 du PTP, a été publiée. Dans cette version du protocole, la précision et la stabilité ont été améliorées, mais la compatibilité descendante avec la première version du protocole n'a pas été maintenue. De plus, en 2019, une version de la norme IEEE 1588-2019 a été publiée qui décrit PTP v2.1. Cette version ajoute des améliorations mineures à PTPv2 et est rétrocompatible avec PTPv2.

En d'autres termes, nous avons l'image suivante avec les versions:

	PTPv1 (IEEE 1588-2002)	PTPv2 (IEEE 1588-2008)	PTPv2.1 (IEEE 1588-2019)
PTPv1 (IEEE 1588-2002)	-	Incompatible	Incompatible
PTPv2 (IEEE 1588-2008)		—
PTPv2.1 (IEEE 1588-2019)			—

Mais, comme toujours, il y a des nuances.

L'incompatibilité entre PTPv1 et PTPv2 suggère qu'un appareil prenant en charge PTPv1 ne pourra pas se synchroniser à partir de l'horloge exacte exécutée sur PTPv2. Ils utilisent différents formats de message pour la synchronisation.

Mais vous pouvez toujours combiner des appareils avec PTPv1 et des appareils avec PTPv2 sur le même réseau. Pour ce faire, certains fabricants vous permettent de sélectionner la version du protocole sur les ports de l'horloge frontalière. Autrement dit, l'horloge limite peut être synchronisée via PTPv2 et en même temps synchroniser d'autres horloges qui lui sont connectées à la fois par PTPv1 et PTPv2.

Appareils PTP. Quels sont et comment diffèrent-ils?

La norme IEEE 1588v2 décrit plusieurs types de périphériques. Tous sont donnés dans le tableau.

Les appareils communiquent entre eux via LAN en utilisant PTP.

Les appareils PTP sont appelés horloges. Toutes les montres prennent l'heure exacte de la montre grand maître.

Il existe 5 types de montres:

Horloge grand maître	La principale source de temps précis. Souvent équipé d'une interface de connexion GPS.
Horloge ordinaire	Un périphérique à port unique qui peut être un maître (horloge maître) ou un esclave (horloge maître)
Heures d'ouverture (maître)	Ils sont à l'origine de l'heure exacte à laquelle les autres horloges sont synchronisées.
Horloge esclave (esclave)	Le périphérique final qui se synchronise depuis l'horloge maître
Horloge frontière	Un périphérique avec plusieurs ports, qui peut être un maître ou un esclave. Autrement dit, cette montre peut se synchroniser à partir d'une horloge maître supérieure et synchroniser une horloge esclave inférieure.
End-to-end Transparent Clock ( , End-to-End)	, , . PTP . PTP-. .
Peer-to-Peer Transparent Clock ( , Peer-to-Peer)	Un périphérique avec plusieurs ports qui n'est ni une horloge maître ni un esclave. Il transmet les données PTP entre deux heures. Lors de la transmission de données, l'horloge transparente corrige tous les messages PTP Sync et Follow_Up (plus d'informations à leur sujet sont décrites ci-dessous). La correction est obtenue en ajoutant au champ de l'ajustement du paquet de retard transmis sur le dispositif émetteur et du retard sur le canal de données.
Noeud de gestion	Un appareil qui configure et diagnostique d'autres montres

Les horloges maître et esclave sont synchronisées à l'aide d'horodatages dans les messages PTP. Il existe deux types de messages dans le protocole PTP:

• Les messages d'événement sont des messages synchronisés qui impliquent la génération d'un horodatage au moment où un message est envoyé et au moment où il est reçu.
• General Messages – ,

Event Messages	General Messages
Sync Delay_Req Pdelay_Req Pdelay_Resp	Announce Follow_Up Delay_Resp Pdelay_Resp_Follow_Up Management Signaling

Ensuite, nous examinerons plus en détail tous les types de messages.

Principaux problèmes de synchronisation

Lors de la transmission d'un paquet de synchronisation via un réseau local, il est retardé sur le commutateur et dans le canal de transmission de données. Tout commutateur donnera un retard d'environ 10 μs, ce qui est inacceptable pour PTPv2. Après tout, nous devons obtenir une précision de 1 μs sur le dispositif final. (C'est quand il s'agit d'énergie. D'autres applications peuvent nécessiter plus de précision.)

IEEE 1588v2 décrit plusieurs algorithmes de fonctionnement qui vous permettent d'enregistrer le retard et de le régler.

Algorithme opérationnel
En fonctionnement normal, le protocole fonctionne en deux phases.

• Phase 1 - Etablissement de la hiérarchie "Horloge Principale - Horloge Esclave".
• Phase 2 - synchronisation d'horloge à l'aide du mécanisme de bout en bout ou de pair à pair.

Phase 1 - Configuration de la hiérarchie maître esclave

Chaque port d'une horloge régulière ou limite a un certain nombre d'états (horloge esclave et horloge maître). La norme décrit l'algorithme de transition entre ces états. En programmation, un tel algorithme est appelé une machine d'état ou une machine d'état (plus sur le Wiki).

Cette machine d'état utilise le meilleur algorithme d'horloge maître (BMCA) pour définir le maître lorsque deux heures sont connectées.

Cet algorithme permet à la montre d'assumer les obligations d'une montre grand maître, lorsqu'une montre grand maître supérieure perd son signal GPS, se déconnecte du réseau, etc.

Les transitions d'état conformément à BMCA sont brièvement illustrées dans le diagramme suivant:


Des informations sur l'horloge à l'autre extrémité du «fil» sont envoyées dans un message spécial (message d'annonce). Lorsque ces informations sont reçues, l'algorithme de la machine à états traite et compare quelle horloge est meilleure. Le port des meilleures montres devient la montre leader.

Une hiérarchie simple est présentée dans le diagramme ci-dessous. Les chemins 1, 2, 3, 4, 5 peuvent contenir une horloge transparente (horloge transparente), mais ils ne participent pas à l'établissement de la hiérarchie "Horloge de tête - Horloge esclave".



Phase 2 - Synchronisation d'une horloge normale et d'une horloge limite

Immédiatement après l'établissement de la hiérarchie «Heures de pointe - Heures esclaves», la phase de synchronisation d'une horloge régulière et limite commence.

Pour la synchronisation, l'horloge maître envoie un message contenant un horodatage à l'horloge esclave.

Les heures d'ouverture peuvent être:

• en une seule étape;
• en deux étapes.

Une horloge à une étape pour la synchronisation envoie un message de synchronisation.

Une horloge à deux étages utilise deux messages pour la synchronisation - Sync et Follow_Up.

Deux mécanismes peuvent être utilisés pour la phase de synchronisation:

• Mécanisme de demande-réponse différée.
• Mécanisme de mesure du délai entre pairs.

Pour commencer, nous considérerons ces mécanismes dans le cas le plus simple - lorsque les montres transparentes ne sont pas utilisées.

Mécanisme de demande-réponse différée

Le mécanisme comporte deux étapes:

1. Mesure du retard de transmission d'un message entre une horloge maître et un esclave. Elle est effectuée à l'aide du mécanisme de demande-réponse de retard.
2. Corrige le décalage de l'heure exacte.

Delay Measurement


t1 - Heure d'envoi du message de synchronisation par l'horloge principale; t2 - Temps de réception du message de synchronisation par horloge esclave; t3 - Temps d'envoi de la demande de retard (Delay_Req) ​​par heures esclaves; t4 - Temps de réception Delay_Req par l'horloge de tête.

Lorsque l'horloge esclave connaît l'heure t1, t2, t3 et t4, elle peut calculer le retard moyen de transmission du message de synchronisation (tmpd). Il est calculé comme suit:



Lors de la transmission d'un message Sync and Follow_Up, la temporisation du maître à l'esclave est calculée - t-ms.

Lors de la transmission des messages Delay_Req et Delay_Resp, le retard de l'esclave au maître, t-sm, est calculé.

Si une asymétrie se produit entre ces deux valeurs, une erreur apparaît dans la correction du départ de l'heure exacte. L'erreur est due au fait que le retard calculé est la moyenne des retards t-ms et t-sm. Si les retards ne sont pas égaux, nous ajusterons l'heure de manière inexacte.

Correction du décalage de l'heure exacte Une fois

le délai entre l'horloge de tête et l'horloge esclave connu, l'horloge esclave effectue la correction de l'heure.



L'horloge esclave utilise le message Sync et le message Follow_Up facultatif pour calculer le décalage horaire exact lors de la transmission du paquet de l'horloge maître à l'esclave. Le décalage est calculé à l'aide de la formule suivante:



Mécanisme de mesure du délai entre pairs

Ce mécanisme utilise également deux étapes pour se synchroniser:

1. . peer delay mechanism.
2. .

Mesure du délai

poste à poste Le délai entre les appareils compatibles poste à poste est mesuré à l'aide des messages suivants:



Lorsque le port 1 connaît les heures t1, t2, t3 et t4, il peut calculer le délai moyen (tmld ) Il est calculé à l'aide de la formule suivante:



Ensuite, le port utilise cette valeur pour calculer le champ d'ajustement pour chaque message Sync ou message Follow_Up facultatif qui passe par ce périphérique.

Le retard total sera égal à la somme du retard pendant la transmission via cet appareil, du retard moyen pendant la transmission via le canal de données et du retard déjà contenu dans ce message, inclus sur les appareils supérieurs.

Les messages Pdelay_Req, Pdelay_Resp et Pdelay_Resp_Follow_Up en option vous permettent d'obtenir un retard du maître à l'esclave et de l'esclave au maître (circulaire).

Toute asymétrie entre ces deux valeurs introduira une erreur de correction de décalage temporel précise.

Correction du décalage de l'heure exacte L'



horloge esclave utilise le message Sync et le message Follow_Up facultatif pour calculer le décalage de l'heure exacte lors de la transmission du paquet de l'horloge de tête à l'esclave. Le décalage est calculé selon la formule suivante:



Avantages ajustement poste à poste - le retard de chaque message Sync ou Follow_Up est calculé lors de sa transmission sur le réseau. Par conséquent, une modification du trajet de transmission n'affectera en aucune façon la précision du réglage.

Lors de l'utilisation de ce mécanisme, la synchronisation temporelle ne nécessite pas le calcul de la temporisation sur le chemin parcouru par le paquet de synchronisation, comme cela se fait avec un échange de base. Ceux. Les messages Delay_Req et Delay_Resp ne sont pas envoyés. Dans cette méthode, le retard entre l'horloge maître et les suiveurs est simplement additionné dans le champ de réglage de chaque message Sync ou Follow_Up.

Un autre avantage est que l'horloge de conduite est déchargée de la nécessité de traiter les messages Delay_Req.

Modes de fonctionnement des montres transparentes En

conséquence, des exemples simples ont été examinés. Supposons maintenant que des commutateurs apparaissent sur le chemin de synchronisation.

Si vous utilisez des commutateurs sans prise en charge PTPv2, le paquet de synchronisation sera retardé d'environ 10 μs sur le commutateur.

Les commutateurs prenant en charge PTPv2 dans la terminologie IEEE 1588v2 sont appelés horloges transparentes. L'horloge transparente n'est pas synchronisée à partir de l'horloge de tête et ne participe pas à la hiérarchie "Horloge de tête - Horloge esclave", mais lors de la transmission des messages de synchronisation, ils se souviennent du retard du message par eux. Cela vous permet de régler la temporisation.

Une montre transparente peut fonctionner selon deux modes:

• De bout en bout.
• D'égal à égal.

De bout en bout (E2E) La



montre transparente E2E transmet les messages Sync et les messages Follow_Up qui l'accompagnent à tous les ports. Même ceux qui sont bloqués par des protocoles (par exemple, RSTP).

Le commutateur se souvient de l'horodatage lorsque le paquet de synchronisation (Follow_Up) a été reçu sur le port et lorsqu'il a été envoyé depuis le port. Sur la base de ces deux horodatages, le temps de traitement du commutateur pour le message 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).



La montre transparente E2E mesure le temps de traitement des messages Sync et Delay_Req passant par le commutateur. Mais il est important de comprendre que le retard entre l'horloge de tête et l'horloge esclave est calculé à l'aide du mécanisme de demande-réponse de retard. Si l'horloge maître change ou si le chemin de l'horloge maître à l'esclave change, le retard est à nouveau mesuré. Cela augmente le temps de transition en cas de changement de réseau.



L'horloge P2P transparente, en plus de mesurer le temps de traitement du message par le commutateur, mesure le retard sur le canal de données au voisin le plus proche en utilisant le 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 qui sont bloqués par un protocole (par exemple, RSTP). Cela vous permet de calculer immédiatement un nouveau retard sur le chemin de synchronisation si l'horloge grand maître ou la topologie du réseau a changé.

Le temps de traitement du commutateur et le temps de retard sont accumulés lors de la transmission des messages Sync ou Follow_Up.

Types de prise en charge des commutateurs PTPv2 Les

commutateurs peuvent prendre en charge PTPv2:

• par programme;
• Matériel.

Dans l'implémentation logicielle du protocole PTPv2, le commutateur demande un horodatage au micrologiciel. Le problème est que le micrologiciel fonctionne de façon cyclique, et vous devez attendre qu'il termine le cycle en cours, prendre la demande en traitement et après l'expiration du cycle suivant, il émettra un horodatage. Tout cela prendra également du temps et nous obtiendrons un retard, bien que moins important que sans le support logiciel PTPv2.

Seul le support matériel pour PTPv2 vous permet de maintenir la précision nécessaire. Dans ce cas, l'émission de l'horodatage est effectuée par un ASIC spécial, qui est installé sur le port.

Format des messages

Tous les messages PTP se composent des champs suivants:

• En-tête - 34 octets.
• Corps - la taille dépend du type de message.
• Suffixe - facultatif.

En-tête

Le champ En-tête est le même pour tous les messages PTP. Sa taille est de 34 octets.

Le format du



champ Header: messageType est le type du message transmis, par exemple Sync, Delay_Req, PDelay_Req, etc.

messageLength - contient la taille complète 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 domaine PTP le message appartient.

Un domaine est composé de quelques horloges différentes assemblées en un groupe logique et synchronisées à partir d'une horloge principale, mais pas nécessairement synchronisées avec une horloge appartenant à un autre domaine.

drapeaux - ce champ contient divers drapeaux pour identifier l'état du message.

correctionField- contient le temps de retard en nanosecondes. Le temps de retard comprend le retard de transmission à travers l'horloge transparente, ainsi que le retard de transmission à travers le canal lors de l'utilisation du mode Peer-to-Peer.

sourcePortIdentity - ce champ contient des informations sur le port à partir duquel ce message a été envoyé à l'origine.

sequenceID - contient le numéro d'identification des messages individuels.

controlField - champ d'artefact =) Il reste de la première version de la norme et contient des informations sur le type de ce message. Essentiellement identique à messageType, mais avec moins d'options.

logMessageInterval - ce champ est déterminé par le type de message.

Corps

Comme indiqué ci-dessus, il existe plusieurs types de messages. Ces types sont décrits ci-dessous:

Message d'annonce Le message d'annonce
est utilisé pour «informer» les autres montres du même domaine de leurs paramètres. Ce message vous permet de définir la hiérarchie "Leading Clock - Slave Clock".


Sync
un message Un message de synchronisation (SYNC) est envoyé par l'horloge principale et contient le temps de l'horloge maître au moment où le message de synchronisation a été créé. Si l'horloge principale est à deux étages, l'horodatage du message Sync sera défini sur 0 et l'horodatage actuel sera envoyé dans le message Follow_Up couplé. Le message Sync est utilisé pour les deux mécanismes de mesure de retard.

Le message est transmis à l'aide de la multidiffusion. Vous pouvez éventuellement utiliser Unicast.





Message Delay_Req Le format du message Delay_Req est identique au message Sync. L'horloge esclave envoie Delay_Req. Il contient l'heure à laquelle Delay_Req a été envoyé par l'horloge esclave. Ce message est utilisé uniquement pour le mécanisme de demande-réponse de retard.

Le message est transmis à l'aide de la multidiffusion. Vous pouvez éventuellement utiliser Unicast.



Message Follow_Up Le message Follow_Up

est éventuellement envoyé par l'horloge maître et contient l'heure à laquelle le maître a envoyé le message Sync . Le message Follow_Up est envoyé uniquement par une horloge de conduite à deux étages.

Le message Follow_Up est utilisé pour les deux mécanismes de mesure de retard.

Le message est transmis à l'aide de la multidiffusion. Vous pouvez éventuellement utiliser Unicast.



Message Delay_Resp

Le message Delay_Resp est envoyé par l'horloge maître. Il contient l'heure à laquelle le Delay_Req est reçu par l'horloge maître. Ce message est utilisé uniquement pour le mécanisme de demande-réponse de retard.

Le message est transmis à l'aide de la multidiffusion. Vous pouvez éventuellement utiliser Unicast. Message



Pdelay_Req Un

message Pdelay_Req est envoyé par un périphérique qui demande un délai. Il contient l'heure à laquelle le message a été envoyé depuis le port de cet appareil. Pdelay_Req est utilisé uniquement pour le mécanisme de mesure du retard du nœud voisin.



Message Pdelay_Resp Le message Pdelay_Resp

est envoyé par le périphérique qui a reçu la demande de retard. Il contient l'heure à laquelle le message Pdelay_Req a été reçu par cet appareil. Les messages Pdelay_Resp sont utilisés uniquement pour le mécanisme de mesure de retard du nœud voisin.



Message Pdelay_Resp_Follow_Up Le message Pdelay_Resp_Follow_Up

est éventuellement envoyé par le périphérique qui a reçu la demande de retard. Il contient l'heure à laquelle le message Pdelay_Req a été reçu par cet appareil. Le message Pdelay_Resp_Follow_Up est envoyé uniquement par une horloge maître à deux étages.

Ce message peut également être utilisé pour l'exécution au lieu d'un horodatage. Le temps d'exécution est le temps entre le moment où Pdelay-Req est reçu et l'envoi de Pdelay_Resp.

Pdelay_Resp_Follow_Up sont utilisés uniquement pour le mécanisme de mesure de retard de nœud voisin.



Messages de contrôle (message de gestion)

Les messages de contrôle PTP sont requis pour transférer des informations entre une ou plusieurs horloges et le nœud de contrôle.



Transfert vers LV

Un message PTP peut être transmis à deux niveaux:

• Réseau - dans le cadre des données IP.
• Lien - dans le cadre d'une trame Ethernet.

Envoi d'un message PTP sur UDP sur IP sur Ethernet Les profils



PTP sur UDP sur Ethernet PTP ont de nombreux paramètres «flexibles» qui doivent être configurés. Par exemple:

• Options BMCA.
• Le mécanisme de mesure du retard.
• Intervalles et valeurs initiales de tous les paramètres configurables, etc.

Et malgré le fait que nous avons dit plus tôt que les appareils PTPv2 sont compatibles les uns avec les autres, dans le bon sens, ce n'est pas le cas. Les appareils doivent avoir les mêmes paramètres pour interagir.

Par conséquent, il existe ce qu'on appelle des profils PTPv2. Les profils sont des groupes de paramètres configurés et certaines restrictions de protocole afin que vous puissiez implémenter la synchronisation de l'heure pour une application spécifique.

La norme IEEE 1588v2 elle-même ne décrit qu'un seul profil - le «Profil par défaut». Tous les autres profils sont créés et décrits par diverses organisations et associations.

Par exemple, le Power Profile ou PTPv2 Power Profile a été créé par le Power Systems Relaying Committee et le Substation Committee de l'IEEE Power and Energy Society. Le profil lui-même est appelé IEEE C37.238-2011.

Le profil décrit que le PTP peut être transmis:

• Uniquement via les réseaux L2 (c'est-à-dire Ethernet, HSR, PRP, pas IP).
• Les messages sont transmis uniquement par la liste de diffusion Multicast.
• Le mécanisme de mesure du retard entre pairs est utilisé comme mécanisme de mesure du retard.

Le domaine par défaut est 0, le domaine recommandé est 93.

La philosophie de création de C37.238-2011 était le désir de réduire le nombre de fonctionnalités optionnelles et de ne laisser que les fonctions nécessaires pour une interaction fiable entre les périphériques et augmenter la stabilité du système.

De plus, la fréquence de transmission des messages est déterminée:



en fait, un seul paramètre est disponible pour la sélection - le type de l'horloge de tête (à un ou deux étages).

La précision ne doit pas dépasser 1 μs. En d'autres termes, un maximum de 15 horloges transparentes ou trois heures limites peuvent être contenues dans un chemin de synchronisation.