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 à la microseconde. Dans ces applications, la précision temporelle 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 dans lesquels PTPv2 est utilisé sont :
- énergie;
- équipements de contrôle et de mesure;
- complexe militaro-industriel;
- télécommunications;
- secteur financier.
Cet article explique le fonctionnement du protocole de synchronisation PTPv2.
Nous avons plus d'expérience dans l'industrie et voyons souvent ce protocole dans les applications énergétiques. En conséquence, nous ferons l'examen avec prudence .
Pourquoi est-ce nécessaire ?
À l'heure actuelle, 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 de l'heure via PTPv2.
Cela est dû au fait que des bornes de protection de relais et des appareils de mesure sont connectés au bus de processus, qui transmettent des valeurs instantanées de courant et de tension via le bus de processus, en utilisant ce que l'on appelle des flux SV (flux multicast).
Les terminaux de protection de relais utilisent ces valeurs pour mettre en œuvre la protection des baies. Si la précision des mesures du temps est faible, certaines protections peuvent fonctionner de manière erronée.
Par exemple, les défenses de sélectivité absolue peuvent être victimes d’une « faible » synchronisation temporelle. Souvent, la logique de telles défenses repose sur une comparaison de deux quantités. Si les valeurs divergent d'une valeur suffisamment importante, alors la protection se déclenche. Si ces valeurs sont mesurées avec une précision temporelle de 1 ms, vous pouvez alors obtenir une grande différence 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 s'appelait « Standard 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 a été publiée, décrivant la version 2 de PTP. Cette version du protocole a amélioré la précision et la stabilité, mais n'a pas maintenu la compatibilité ascendante avec la première version du protocole. De plus, en 2019, une version de la norme IEEE 1588-2019 a été publiée, décrivant 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)
Incompatible
-
Compatible
PTPv2.1 (IEEE 1588-2019)
Incompatible
Compatible
-
Mais comme toujours, il y a des nuances.
L'incompatibilité entre PTPv1 et PTPv2 signifie qu'un appareil compatible PTPv1 ne pourra pas se synchroniser avec une horloge précise fonctionnant sur PTPv2. Ils utilisent différents formats de messages pour se synchroniser.
Mais il est toujours possible de combiner des appareils avec PTPv1 et des appareils avec PTPv2 sur le même réseau. Pour y parvenir, certains fabricants permettent de sélectionner la version du protocole sur les ports d'horloge Edge. Autrement dit, une horloge limite peut se synchroniser à l'aide de PTPv2 tout en synchronisant les autres horloges qui lui sont connectées à l'aide de PTPv1 et de PTPv2.
Appareils PTP. Que sont-ils et en quoi sont-ils différents ?
La norme IEEE 1588v2 décrit plusieurs types d'appareils. Tous sont présentés dans le tableau.
Les appareils communiquent entre eux via un réseau local via 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 d’heure précise. Souvent équipé d'une interface pour connecter le GPS.
Horloge ordinaire
Un périphérique à port unique qui peut être maître (horloge maître) ou esclave (horloge esclave)
Horloge maître (maître)
Ils sont la source de l'heure exacte à laquelle les autres horloges sont synchronisées
Horloge esclave
Appareil final synchronisé à partir de l'horloge principale
Horloge limite
Un appareil avec plusieurs ports qui peut être maître ou esclave.
Autrement dit, ces horloges peuvent se synchroniser à partir de l'horloge maître supérieure et synchroniser les horloges esclaves inférieures.
Horloge transparente de bout en bout
Un appareil avec plusieurs ports qui n'est ni une horloge maître ni un esclave. Il transmet des données PTP entre deux montres.
Lors de la transmission des données, l'horloge transparente corrige tous les messages PTP.
La correction s'effectue en ajoutant le temps de retard sur cet appareil au champ de correction dans l'en-tête du message transmis.
Horloge transparente peer-to-peer
Un appareil avec plusieurs ports qui n'est ni une horloge maître ni un esclave.
Il transmet des données PTP entre deux montres.
Lors de la transmission des données, l'horloge transparente corrige tous les messages PTP Sync et Follow_Up (plus d'informations ci-dessous).
La correction est obtenue en ajoutant au champ de correction du paquet transmis le délai sur le dispositif émetteur et le délai sur le canal de transmission des données.
Nœud 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 de l'envoi du message et au moment de sa réception.
- Messages généraux : ces messages ne nécessitent pas d'horodatage, mais peuvent contenir des horodatages pour les messages associés.
Messages d'événement
Messages généraux
Sync
Délai_Req
Pdelay_Req
Pdelay_Resp
Annoncer
Suivi
Délai_Resp
Pdelay_Resp_Follow_Up
Gestion
Signalisation
Tous les types de messages seront abordés plus en détail ci-dessous.
Problèmes de synchronisation de base
Lorsqu'un paquet de synchronisation est transmis sur un réseau local, il est retardé au niveau du commutateur et dans la liaison de données. Tout changement produira un retard d'environ 10 microsecondes, ce qui est inacceptable pour PTPv2. Après tout, nous devons atteindre une précision de 1 μs sur l’appareil final. (C'est le cas si nous parlons d'énergie. D'autres applications peuvent nécessiter une plus grande précision.)
IEEE 1588v2 décrit plusieurs algorithmes de fonctionnement qui permettent d'enregistrer le retard et de le corriger.
Algorithme de travail
En fonctionnement normal, le protocole fonctionne en deux phases.
- Phase 1 - établissement de la hiérarchie « Horloge maître – Horloge esclave ».
- Phase 2 - synchronisation d'horloge à l'aide d'un mécanisme de bout en bout ou peer-to-peer.
Phase 1 - Établissement de la hiérarchie maître-esclave
Chaque port d'une horloge régulière ou Edge possède 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é machine à états finis ou machine à états (plus de détails dans Wiki).
Cette machine à états utilise le meilleur algorithme d'horloge maître (BMCA) pour définir le maître lors de la connexion de deux horloges.
Cet algorithme permet à la montre de prendre en charge les responsabilités de la montre grand maître lorsque la montre grand maître en amont perd le signal GPS, se déconnecte, etc.
Les transitions d'état selon le BMCA sont résumées dans le schéma suivant :
Les informations sur la montre à l'autre bout du « fil » sont envoyées dans un message spécial (message d'annonce). Une fois ces informations reçues, l’algorithme de la machine d’état s’exécute et une comparaison est effectuée pour voir quelle horloge est la meilleure. Le port de la meilleure montre devient la montre maîtresse.
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, mais ils ne participent pas à l'établissement de la hiérarchie Master Clock - Slave Clock.
Phase 2 - Synchroniser les horloges régulières et de bord
Immédiatement après avoir établi la hiérarchie « Horloge maître – Horloge esclave », la phase de synchronisation des horloges régulières et limites commence.
Pour se synchroniser, l'horloge maître envoie un message contenant un horodatage aux horloges esclaves.
L'horloge mère peut être :
- en une seule étape;
- en deux étapes.
Les horloges à un étage envoient un message Sync pour se synchroniser.
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 retardé.
- Mécanisme de mesure du retard entre pairs.
Examinons d’abord 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é
Le mécanisme comporte deux étapes :
- Mesure du délai de transmission d'un message entre l'horloge maître et l'horloge esclave. Effectué à l’aide d’un mécanisme de demande-réponse différée.
- Une correction du décalage horaire exact est effectuée.
Mesure de latence
t1 – Heure d'envoi du message Sync par l'horloge mère ; t2 – Heure de réception du message Sync par l'horloge asservie ; t3 – Heure d'envoi de la demande de retard (Delay_Req) par l'horloge esclave ; t4 – Temps de réception Delay_Req par l'horloge mère.
Lorsque l'horloge esclave connaît les instants t1, t2, t3 et t4, elle peut calculer le délai moyen lors de la transmission du message de synchronisation (tmpd). Il est calculé comme suit :
Lors de la transmission d'un message Sync et Follow_Up, le délai du maître à l'esclave est calculé - t-ms.
Lors de la transmission des messages Delay_Req et Delay_Resp, le délai de l'esclave au maître est calculé - t-sm.
Si une asymétrie se produit entre ces deux valeurs, alors une erreur de correction de l'écart de l'heure exacte apparaît. L'erreur est due au fait que le délai calculé est la moyenne des délais t-ms et t-sm. Si les délais ne sont pas égaux, nous n’ajusterons pas l’heure avec précision.
Correction du décalage horaire
Une fois connu le délai entre l'horloge maître et l'horloge esclave, l'horloge esclave effectue une correction temporelle.
Les horloges esclaves utilisent le message Sync et un message Follow_Up facultatif pour calculer le décalage horaire exact lors de la transmission d'un paquet de l'horloge maître aux horloges esclaves. Le décalage est calculé à l'aide de la formule suivante :
Mécanisme de mesure du retard entre pairs
Ce mécanisme utilise également deux étapes pour la synchronisation :
- Les appareils mesurent le délai par rapport à tous les voisins via tous les ports. Pour ce faire, ils utilisent un mécanisme de retard entre pairs.
- Correction du décalage horaire exact.
Mesurer la latence entre les appareils prenant en charge le mode Peer-to-Peer
La latence entre les ports prenant en charge le mécanisme peer-to-peer est mesurée à l'aide des messages suivants :
Lorsque le port 1 connaît les instants t1, t2, t3 et t4, il peut calculer le délai moyen (tmld). Il est calculé selon la formule suivante :
Le port utilise ensuite cette valeur lors du calcul du champ d'ajustement pour chaque message de synchronisation ou message Follow_Up facultatif qui passe par l'appareil.
Le délai total sera égal à la somme du délai de transmission via cet appareil, du délai moyen lors de la transmission via le canal de données et du délai déjà contenu dans ce message, activé sur les appareils en amont.
Les messages Pdelay_Req, Pdelay_Resp et en option Pdelay_Resp_Follow_Up permettent d'obtenir le délai 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.
Ajuster le décalage horaire exact
Les horloges esclaves utilisent un message Sync et un message Follow_Up facultatif pour calculer le décalage horaire exact lors de la transmission d'un paquet de l'horloge maître aux horloges esclaves. Le décalage est calculé à l'aide de la formule suivante :
Avantages ajustement du mécanisme peer-to-peer - le délai de chaque message Sync ou Follow_Up est calculé au fur et à mesure de sa transmission dans le réseau. Par conséquent, changer le chemin de transmission n’affectera en rien la précision du réglage.
Lors de l'utilisation de ce mécanisme, la synchronisation temporelle ne nécessite pas de calculer le délai le long du chemin parcouru par le paquet de synchronisation, comme cela se fait dans l'échange de base. Ceux. Les messages Delay_Req et Delay_Resp ne sont pas envoyés. Dans cette méthode, le délai entre les horloges maître et esclave est simplement additionné dans le champ de réglage de chaque message Sync ou Follow_Up.
Un autre avantage est que l'horloge mère n'a plus besoin de traiter les messages Delay_Req.
Modes de fonctionnement des horloges transparentes
Il s’agissait donc d’exemples simples. 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é sur le commutateur d'environ 10 µs.
Les commutateurs prenant en charge PTPv2 sont appelés horloges transparentes dans la terminologie IEEE 1588v2. Les horloges transparentes ne sont pas synchronisées par rapport à l'horloge maître et ne participent pas à la hiérarchie « Horloge maître - Horloge esclave », mais lors de la transmission des messages de synchronisation, elles se souviennent de la durée pendant laquelle le message a été retardé. Cela vous permet d'ajuster le délai.
Les horloges transparentes peuvent fonctionner selon deux modes :
- De bout en bout.
- D'égal à égal.
De bout en bout (E2E)
L'horloge transparente E2E diffuse des messages Sync et des messages Follow_Up qui l'accompagnent sur tous les ports. Même ceux qui sont bloqués par des protocoles (par exemple, RSTP).
Le commutateur mémorise l'horodatage lorsqu'un 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 nécessaire au commutateur pour traiter le message est calculé. Dans la norme, ce temps est appelé temps de séjour.
Le temps de traitement est ajouté au champ correctionField du message Sync (horloge à un pas) ou Follow_Up (horloge à deux pas).
L'horloge transparente E2E mesure le temps de traitement des messages Sync et Delay_Req transitant par le commutateur. Mais il est important de comprendre que le délai entre l'horloge maître et l'horloge esclave est calculé à l'aide du mécanisme de demande-réponse de délai. Si l'horloge maître change ou si le chemin de l'horloge maître à l'horloge esclave change, le retard est à nouveau mesuré. Cela augmente le temps de transition en cas de changements de réseau.
L'horloge transparente P2P, en plus de mesurer le temps nécessaire à un commutateur pour traiter un message, mesure le retard sur la liaison de données vers son voisin le plus proche à l'aide d'un mécanisme de latence de voisin.
La latence est mesurée sur chaque liaison dans les deux sens, y compris les liaisons bloquées par certains protocoles (tels que RSTP). Cela vous permet de calculer immédiatement le nouveau délai dans le chemin de synchronisation si l'horloge grand maître ou la topologie du réseau change.
Le temps de traitement des messages par les commutateurs et la latence sont accumulés lors de l'envoi de messages Sync ou Follow_Up.
Types de prise en charge de PTPv2 par les commutateurs
Les commutateurs peuvent prendre en charge PTPv2 :
- par programmation ;
- matériel.
Lors de l'implémentation du protocole PTPv2 dans le logiciel, le commutateur demande un horodatage au micrologiciel. Le problème est que le firmware fonctionne de manière cyclique et vous devrez attendre qu'il termine le cycle en cours, prenne la demande de traitement et émette un horodatage après le cycle suivant. Cela prendra également du temps, et nous aurons un retard, mais pas aussi important que sans le support logiciel pour PTPv2.
Seule la prise en charge matérielle de PTPv2 vous permet de maintenir la précision requise. Dans ce cas, l'horodatage est émis par un ASIC spécial 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.
- Le suffixe est facultatif.
En-tête
Le champ d'en-tête est le même pour tous les messages PTP. Sa taille est de 34 octets.
Format du champ d'en-tête :
type de message – contient le type de message en cours de transmission, par exemple Sync, Delay_Req, PDelay_Req, etc.
longueur du message – 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).
numéro de domaine – détermine à quel domaine PTP appartient le message.
Nom de domaine - il s'agit de plusieurs horloges différentes rassemblées dans un groupe logique et synchronisées à partir d'une horloge maître, mais pas nécessairement synchronisées avec des horloges appartenant à un domaine différent.
drapeaux – Ce champ contient divers indicateurs permettant d'identifier l'état du message.
champ de correction – contient le temps de retard en nanosecondes. Le temps de retard inclut le délai de transmission via l'horloge transparente, ainsi que le délai de transmission via le canal lors de l'utilisation du mode Peer-to-Peer.
identitéPortsource – ce champ contient des informations sur le port à partir duquel ce message a été initialement envoyé.
ID de séquence – contient un numéro d'identification pour les messages individuels.
champ de contrôle – champ 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.
Transformation
Comme indiqué ci-dessus, il existe plusieurs types de messages. Ces types sont décrits ci-dessous :
Message d'annonce
Le message Announce est utilisé pour « informer » les autres horloges du même domaine de ses paramètres. Ce message vous permet de configurer une hiérarchie horloge maître - horloge esclave.
Message de synchronisation
Le message Sync est envoyé par l'horloge maître et contient l'heure de l'horloge maître au moment où le message Sync a été généré. Si l'horloge maître est à deux étages, alors l'horodatage du message Sync sera réglé sur 0 et l'horodatage actuel sera envoyé dans le message Follow_Up associé. Le message Sync est utilisé pour les deux mécanismes de mesure de latence.
Le message est transmis via Multicast. En option, vous pouvez 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 le Delay_Req a été envoyé par l'horloge esclave. Ce message est utilisé uniquement pour le mécanisme de demande-réponse de délai.
Le message est transmis via Multicast. En option, vous pouvez utiliser Unicast.
Message de suivi
Le message Follow_Up est éventuellement envoyé par l'horloge mère et contient l'heure d'envoi Synchroniser les messages maître. Seules les horloges mères à deux étages envoient le message Follow_Up.
Le message Follow_Up est utilisé pour les deux mécanismes de mesure de latence.
Le message est transmis via Multicast. En option, vous pouvez utiliser Unicast.
Message Delay_Resp
Le message Delay_Resp est envoyé par l'horloge maître. Il contient l'heure à laquelle le Delay_Req a été reçu par l'horloge maître. Ce message est utilisé uniquement pour le mécanisme de demande-réponse de délai.
Le message est transmis via Multicast. En option, vous pouvez utiliser Unicast.
Message Pdelay_Req
Le message Pdelay_Req est envoyé par un appareil qui demande un délai. Il contient l'heure à laquelle le message a été envoyé depuis le port de cet appareil. Pdelay_Req n'est utilisé que pour le mécanisme de mesure du retard du voisin.
Message Pdelay_Resp
Le message Pdelay_Resp est envoyé par un appareil qui a reçu une demande de délai. Il contient l'heure à laquelle le message Pdelay_Req a été reçu par cet appareil. Le message Pdelay_Resp est utilisé uniquement pour le mécanisme de mesure du délai de voisinage.
Message Pdelay_Resp_Follow_Up
Le message Pdelay_Resp_Follow_Up est éventuellement envoyé par l'appareil qui a reçu la demande de délai. 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 les horloges mères à deux étages.
Ce message peut également être utilisé pour l'heure d'exécution au lieu d'un horodatage. Le temps d'exécution est le temps écoulé entre le moment où Pdelay-Req est reçu et celui où Pdelay_Resp est envoyé.
Pdelay_Resp_Follow_Up sont utilisés uniquement pour le mécanisme de mesure du retard du voisin.
Messages de gestion
Les messages de contrôle PTP sont nécessaires pour transférer des informations entre une ou plusieurs horloges et le nœud de contrôle.
Transfert vers BT
Un message PTP peut être transmis à deux niveaux :
- Réseau – dans le cadre des données IP.
- Canal – dans le cadre d'une trame Ethernet.
Transmission de messages PTP sur UDP sur IP sur Ethernet
PTP sur UDP sur Ethernet
Profils
PTP comporte de nombreux paramètres flexibles qui doivent être configurés. Par exemple:
- Options BMCA.
- Mécanisme de mesure de la latence.
- Intervalles et valeurs initiales de tous les paramètres configurables, etc.
Et malgré le fait que nous ayons dit précédemment que les appareils PTPv2 étaient compatibles entre eux, ce n'est pas vrai. Les appareils doivent avoir les mêmes paramètres pour communiquer.
C'est pourquoi il existe des profils dits PTPv2. Les profils sont des groupes de paramètres configurés et de restrictions de protocole définies afin que la synchronisation de l'heure puisse être implémentée 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 profil d'alimentation, ou profil d'alimentation PTPv2, 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 s'appelle IEEE C37.238-2011.
Le profil décrit que PTP peut être transféré :
- Uniquement via les réseaux L2 (c'est-à-dire Ethernet, HSR, PRP, non-IP).
- Les messages sont transmis uniquement par 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 conception derrière C37.238-2011 était de réduire le nombre de fonctionnalités optionnelles et de conserver uniquement les fonctions nécessaires pour une interaction fiable entre les appareils et une stabilité accrue du système.
De plus, la fréquence de transmission des messages est déterminée :
En fait, un seul paramètre est disponible à la sélection : le type d'horloge mère (mono-étage ou deux étages).
La précision ne doit pas dépasser 1 μs. En d’autres termes, un chemin de synchronisation peut contenir un maximum de 15 horloges transparentes ou trois horloges limites.
Source: habr.com