Implementierungsdetails des PTPv2-Zeitsynchronisationsprotokolls

Einleitung

Das Konzept des Aufbaus einer „digitalen Unterstation“ in der Elektroindustrie erfordert eine Synchronisation mit einer Genauigkeit von 1 μs. Finanztransaktionen erfordern auch eine Genauigkeit von Mikrosekunden. In diesen Anwendungen reicht die NTP-Zeitgenauigkeit nicht mehr aus.

Das durch den IEEE 1588v2-Standard beschriebene PTPv2-Synchronisationsprotokoll ermöglicht eine Synchronisationsgenauigkeit von mehreren zehn Nanosekunden. Mit PTPv2 können Sie Synchronisationspakete über L2- und L3-Netzwerke senden.

Die Hauptbereiche, in denen PTPv2 verwendet wird, sind:

• Energietechnik;
• Steuer- und Messgeräte;
• militärisch-industrieller Komplex;
• Telekommunikation
• Finanzsektor.

Dieser Beitrag befasst sich mit der Funktionsweise des PTPv2-Synchronisationsprotokolls.

Wir haben mehr Branchenerfahrung und stoßen bei Energieanwendungen häufig auf dieses Protokoll. Dementsprechend werden wir die Überprüfung mit Blick auf Energie durchführen .

Warum ist es notwendig?

Derzeit enthalten STO 34.01-21-004-2019 von PJSC Rosseti und STO 56947007-29.240.10.302-2020 von PJSC FGC UES Anforderungen zum Organisieren eines Prozessbusses mit Zeitsynchronisation über PTPv2.

Dies liegt daran, dass Relaisschutzklemmen und Messgeräte an den Prozessbus angeschlossen sind, die über die sogenannten SV-Streams (Multicast-Streams) über den Prozessbus Momentanwerte von Strom und Spannung übertragen.

Relaisschutzklemmen verwenden diese Werte, um den Verbindungsschutz zu implementieren. Wenn die Genauigkeit der Messungen über die Zeit gering ist, können einige Schutzmaßnahmen falsch funktionieren.

Beispielsweise kann der Schutz der absoluten Selektivität Opfer einer "schwachen" Zeitsynchronisation werden. Oft basiert die Logik solcher Verteidigungen auf einem Vergleich zweier Werte. Wenn die Werte von einem ausreichend großen Wert abweichen, wird der Schutz ausgelöst. Wenn diese Werte mit einer Genauigkeit von 1 ms gemessen werden, können Sie einen großen Unterschied feststellen, wenn die Werte tatsächlich normal sind, wenn Sie sie mit einer Genauigkeit von 1 μs messen.

PTP-Versionen

Das PTP-Protokoll wurde ursprünglich im Jahr 2002 im IEEE 1588-2002-Standard beschrieben und als „Standard für ein Präzisionsuhr-Synchronisationsprotokoll für vernetzte Mess- und Steuerungssysteme“ bezeichnet. Im Jahr 2008 wurde der aktualisierte IEEE 1588-2008-Standard veröffentlicht, der die PTP-Version 2 beschreibt. In dieser Version des Protokolls wurden Genauigkeit und Stabilität verbessert, die Abwärtskompatibilität mit der ersten Version des Protokolls wurde jedoch nicht beibehalten. Außerdem wurde 2019 die Standardversion IEEE 1588-2019 veröffentlicht, die PTP v2.1 beschreibt. Diese Version fügt geringfügige Verbesserungen zu PTPv2 hinzu und ist abwärtskompatibel mit PTPv2.

Mit anderen Worten, wir haben das folgende Bild mit den Versionen:

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

Aber wie immer gibt es Nuancen.

Die Inkompatibilität zwischen PTPv1 und PTPv2 deutet darauf hin, dass ein Gerät mit PTPv1-Unterstützung nicht mit der genauen Uhr synchronisieren kann, die auf PTPv2 ausgeführt wird. Sie verwenden unterschiedliche Nachrichtenformate für die Synchronisation.

Sie können jedoch weiterhin Geräte mit PTPv1 und Geräte mit PTPv2 im selben Netzwerk kombinieren. Zu diesem Zweck können Sie bei einigen Herstellern die Protokollversion an den Ports der Grenzuhr auswählen. Das heißt, die Grenzuhr kann über PTPv2 synchronisiert werden und gleichzeitig andere mit PTPv1 und PTPv2 verbundene Uhren synchronisieren.

PTP-Geräte. Was sind und wie unterscheiden sie sich?

Der IEEE 1588v2-Standard beschreibt verschiedene Arten von Geräten. Alle von ihnen sind in der Tabelle angegeben.

Geräte kommunizieren über LAN über PTP miteinander.

PTP-Geräte werden als Uhren bezeichnet. Alle Uhren nehmen die genaue Zeit von der Großmeisteruhr.

Es gibt 5 Arten von Uhren:

Großmeisteruhr	Die Hauptquelle für genaue Zeit. Oft mit einer Schnittstelle zum Anschließen von GPS ausgestattet.
Gewöhnliche Uhr	Ein Single-Port-Gerät, das ein Master (Master Clock) oder ein Slave (Master Clock) sein kann.
Führende Stunden (Meister)	Sie sind die Quelle der genauen Zeit, zu der andere Uhren synchronisiert werden.
Sklavenuhr (Sklave)	Das Endgerät, das von der Hauptuhr synchronisiert wird
Grenzuhr	Ein Gerät mit mehreren Ports, das ein Master oder ein Slave sein kann. Das heißt, diese Uhr kann von einer höheren Hauptuhr und einer niedrigeren Nebenuhr synchronisieren.
End-to-end Transparent Clock ( , End-to-End)	, , . PTP . PTP-. .
Peer-to-Peer Transparent Clock ( , Peer-to-Peer)	Ein Gerät mit mehreren Ports, das weder eine Hauptuhr noch ein Slave ist. Es überträgt PTP-Daten zwischen zwei Stunden. Bei der Datenübertragung korrigiert die transparente Uhr alle PTP-Nachrichten Sync und Follow_Up (mehr dazu weiter unten). Die Korrektur wird erreicht, indem das Feld der Einstellung des übertragenen Verzögerungspakets auf dem sendenden Gerät und der Verzögerung auf dem Datenkanal addiert wird.
Verwaltungsknoten	Ein Gerät, das andere Uhren konfiguriert und diagnostiziert

Die Master- und Slave-Uhren werden mithilfe von Zeitstempeln in PTP-Nachrichten synchronisiert. Es gibt zwei Arten von Nachrichten im PTP-Protokoll:

• Ereignismeldungen sind synchronisierte Nachrichten, bei denen zum Zeitpunkt des Sendens und zum Empfang einer Nachricht ein Zeitstempel generiert wird.
• General Messages – ,

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

Als nächstes werden wir alle Arten von Nachrichten genauer betrachten.

Die Hauptprobleme der Synchronisation

Bei der Übertragung eines Synchronisationspakets über ein lokales Netzwerk wird es auf dem Switch und im Datenübertragungskanal verzögert. Jeder Schalter ergibt eine Verzögerung von ca. 10 μs, was für PTPv2 nicht akzeptabel ist. Immerhin müssen wir am Endgerät eine Genauigkeit von 1 μs erreichen. (Dies ist der

Fall, wenn es um Energie geht. Andere Anwendungen erfordern möglicherweise eine höhere Genauigkeit.) IEEE 1588v2 beschreibt mehrere Betriebsalgorithmen, mit denen Sie die Zeitverzögerung aufzeichnen und anpassen können.

Betriebsalgorithmus
Während des normalen Betriebs arbeitet das Protokoll in zwei Phasen.

• Phase 1 - Aufbau der Hierarchie „Leading Clock - Slave Clock“.
• Phase 2 - Taktsynchronisation mit dem End-to-End-Mechanismus oder Peer-to-Peer.

Phase 1 - Aufbau einer Master-Slave-Hierarchie

Jeder Port einer regulären oder Grenzuhr hat eine bestimmte Anzahl von Zuständen (Slave-Uhr und Master-Uhr). Der Standard beschreibt den Übergangsalgorithmus zwischen diesen Zuständen. Bei der Programmierung wird ein solcher Algorithmus als Zustandsmaschine oder Zustandsmaschine bezeichnet (mehr im Wiki).

Diese Zustandsmaschine verwendet den BMCA (Best Master Clock Algorithm), um den Master einzustellen, wenn zwei Stunden verbunden sind.

Dieser Algorithmus ermöglicht es der Uhr, die Verpflichtungen einer Großmeisteruhr zu übernehmen, wenn eine überlegene Großmeisteruhr ihr GPS-Signal verliert, sich vom Netzwerk trennt usw.

Zustandsübergänge gemäß BMCA sind in der folgenden Abbildung kurz dargestellt:


Informationen über die Uhr am anderen Ende des „Kabels“ werden in einer speziellen Nachricht (Announce-Nachricht) gesendet. Wenn diese Informationen empfangen werden, verarbeitet und vergleicht der Zustandsmaschinenalgorithmus, welcher Takt besser ist. Der Hafen der besten Uhren wird zur führenden Uhr.

Eine einfache Hierarchie ist in der folgenden Abbildung dargestellt. Die Pfade 1, 2, 3, 4, 5 können eine transparente Uhr (transparente Uhr) enthalten, sie sind jedoch nicht an der Erstellung der Hierarchie „Führende Uhr - Slave-Uhr“ beteiligt.



Phase 2 - Synchronisation einer regulären Uhr und einer Grenzuhr

Unmittelbar nach Festlegung der Hierarchie „Leitstunden - Slave-Stunden“ beginnt die Synchronisationsphase einer regulären Uhr und einer Grenzuhr.

Zur Synchronisation sendet die Hauptuhr eine Nachricht mit einem Zeitstempel an die Nebenuhr.

Vorlaufzeiten können sein:

• einstufig;
• zweistufig.

Eine einstufige Uhr für die Synchronisation sendet eine Synchronisationsnachricht.

Eine zweistufige Uhr verwendet zwei Nachrichten für die Synchronisation - Sync und Follow_Up.

Für die Synchronisationsphase können zwei Mechanismen verwendet werden:

• Anforderungs- / Antwortmechanismus verzögern.
• Peer-Delay-Messmechanismus.

Zunächst werden wir diese Mechanismen im einfachsten Fall betrachten - wenn keine transparenten Uhren verwendet werden.

Verzögerungsanforderungs-Antwort-Mechanismus

Der Mechanismus besteht aus zwei Schritten:

1. Messung der Verzögerung beim Senden einer Nachricht zwischen einer Hauptuhr und einem Slave. Es wird unter Verwendung des Verzögerungsanforderungs- / Antwortmechanismus durchgeführt.
2. Korrigiert die Verschiebung der genauen Zeit.

Verzögerungsmessung


t1 - Synchronisieren der Sendezeit der Nachricht durch die führende Uhr; t2 - Empfangszeit der Synchronisierungsnachricht mit der Slave-Uhr; t3 - Sendezeit der Verzögerungsanforderung (Delay_Req) ​​um Slave-Stunden; t4 - Delay_Req Empfangszeit durch die führende Uhr.

Wenn die Slave-Uhr die Zeit t1, t2, t3 und t4 kennt, kann sie die durchschnittliche Verzögerung beim Senden der Synchronisationsnachricht (tmpd) ​​berechnen. Es wird wie folgt berechnet:



Bei der Übertragung einer Sync- und Follow_Up-Nachricht wird die Zeitverzögerung vom Master zum Slave berechnet - t-ms.

Bei der Übertragung von Delay_Req- und Delay_Resp-Nachrichten wird die Zeitverzögerung vom Slave zum Master t-sm berechnet.

Wenn zwischen diesen beiden Werten eine gewisse Asymmetrie auftritt, tritt ein Fehler bei der Korrektur der Abweichung der genauen Zeit auf. Der Fehler wird durch die Tatsache verursacht, dass die berechnete Verzögerung der Durchschnitt der Verzögerungen t-ms und t-sm ist. Wenn die Verzögerungen nicht gleich sind, werden wir die Zeit ungenau anpassen.

Korrektur des Versatzes der genauen Zeit

Nachdem die Verzögerung zwischen der führenden Uhr und der Nebenuhr bekannt ist, führt die Nebenuhr die Zeitkorrektur durch.



Die Slave-Uhr verwendet die Sync-Nachricht und die optionale Follow_Up-Nachricht, um den genauen Zeitversatz beim Übertragen des Pakets von der Master-Uhr zum Slave zu berechnen. Die Verschiebung wird nach folgender Formel berechnet:



Peer-Delay-Messmechanismus

Dieser Mechanismus verwendet auch zwei Schritte zum Synchronisieren:

1. . peer delay mechanism.
2. .

Peer-to-Peer-

Verzögerungsmessung Die Verzögerung zwischen Peer-to-Peer- fähigen Geräten wird anhand der folgenden Meldungen gemessen:



Wenn Port 1 die Zeiten t1, t2, t3 und t4 kennt, kann er die durchschnittliche Verzögerung (tmld) berechnen ) Die Berechnung erfolgt nach folgender Formel:



Der Port verwendet diesen Wert dann bei der Berechnung des Anpassungsfelds für jede Synchronisierungsnachricht oder optionale Follow_Up-Nachricht, die dieses Gerät durchläuft.

Die Gesamtverzögerung ist gleich der Summe der Verzögerung während der Übertragung durch dieses Gerät, der durchschnittlichen Verzögerung während der Übertragung durch den Datenkanal und der bereits in dieser Nachricht enthaltenen Verzögerung, die auf den höheren Geräten enthalten ist.

Mit den Nachrichten Pdelay_Req, Pdelay_Resp und optional Pdelay_Resp_Follow_Up können Sie eine Verzögerung vom Master zum Slave und vom Slave zum Master erhalten (Rundschreiben).

Jede Asymmetrie zwischen diesen beiden Werten führt zu einem genauen Zeitversatzkorrekturfehler.

Korrigieren des Versatzes der genauen Zeit Die



Slave-Uhr verwendet die Sync-Nachricht und die optionale Follow_Up-Nachricht, um den Versatz der genauen Zeit beim Übertragen des Pakets von der führenden Uhr zum Slave zu berechnen. Die Verschiebung wird gemäß der folgenden Formel berechnet:



Vorteile Peer-to-Peer-Anpassung - Die Zeitverzögerung jeder Sync- oder Follow_Up-Nachricht wird berechnet, wenn sie im Netzwerk übertragen wird. Daher hat eine Änderung des Übertragungswegs keinen Einfluss auf die Genauigkeit der Einstellung.

Bei Verwendung dieses Mechanismus erfordert die Zeitsynchronisation nicht die Berechnung der Zeitverzögerung auf dem vom Synchronisationspaket zurückgelegten Pfad, wie dies bei einem Basisaustausch der Fall ist. Jene. Delay_Req- und Delay_Resp-Nachrichten werden nicht gesendet. Bei dieser Methode wird die Verzögerung zwischen der Hauptuhr und den Followern einfach im Anpassungsfeld jeder Sync- oder Follow_Up-Nachricht summiert.

Ein weiterer Vorteil besteht darin, dass die Fahruhr entlastet wird, da Delay_Req-Nachrichten verarbeitet werden müssen.

Funktionsweise transparenter Uhren

Dementsprechend wurden einfache Beispiele untersucht. Angenommen, auf dem Synchronisationspfad werden Schalter angezeigt.

Wenn Sie Switches ohne PTPv2-Unterstützung verwenden, wird das Synchronisationspaket auf dem Switch um ca. 10 μs verzögert.

Switches, die PTPv2 in der IEEE 1588v2-Terminologie unterstützen, werden als transparente Uhren bezeichnet. Die transparente Uhr ist nicht mit der führenden Uhr synchronisiert und nimmt nicht an der Hierarchie „Führende Uhr - Slave-Uhr“ teil. Bei der Übertragung von Synchronisationsnachrichten merken sie sich jedoch, wie stark die Nachricht von ihnen verzögert wurde. Auf diese Weise können Sie die Zeitverzögerung anpassen.

Eine transparente Uhr kann in zwei Modi arbeiten:

• Ende zu Ende.
• Peer-To-Peer.

End-to-End (E2E) Die



transparente E2E-Uhr überträgt Synchronisierungsnachrichten und zugehörige Follow_Up-Nachrichten an alle Ports. Sogar diejenigen, die durch Protokolle blockiert sind (z. B. RSTP).

Der Switch merkt sich den Zeitstempel, zu dem das Synchronisierungspaket (Follow_Up) am Port empfangen und vom Port gesendet wurde. Basierend auf diesen beiden Zeitstempeln wird die Switch-Verarbeitungszeit für die Nachricht berechnet. In der Norm wird diese Zeit als Verweilzeit bezeichnet.

Die Verarbeitungszeit wird dem FeldrectionField der Sync-Nachricht (einstufige Uhr) oder Follow_Up (zweistufige Uhr) hinzugefügt.



Die transparente E2E-Uhr misst die Verarbeitungszeit für Sync- und Delay_Req-Nachrichten, die den Switch durchlaufen. Es ist jedoch wichtig zu verstehen, dass die Zeitverzögerung zwischen der führenden Uhr und der Nebenuhr unter Verwendung des Verzögerungsanforderungs-Antwort-Mechanismus berechnet wird. Wenn sich die Hauptuhr ändert oder sich der Pfad von der Hauptuhr zum Slave ändert, wird die Verzögerung erneut gemessen. Dies erhöht die Übergangszeit bei Netzwerkänderungen.



Der transparente P2P-Takt misst zusätzlich zur Messung der Verarbeitungszeit der Nachricht durch den Switch die Verzögerung auf dem Datenkanal zum nächsten Nachbarn unter Verwendung des Verzögerungsmessmechanismus des benachbarten Knotens.

Die Verzögerung wird auf jedem Kanal in beide Richtungen gemessen, einschließlich der Kanäle, die durch ein Protokoll (z. B. RSTP) blockiert sind. Auf diese Weise können Sie sofort eine neue Verzögerung auf dem Synchronisationspfad berechnen, wenn sich die Großmeisteruhr oder die Netzwerktopologie geändert hat.

Die Switch-Verarbeitungszeit und die Verzögerungszeit werden beim Senden von Sync- oder Follow_Up-Nachrichten akkumuliert.

Arten der Unterstützung für PTPv2-Switches

Switches können PTPv2 unterstützen:

• programmatisch;
• Hardware.

Bei der Softwareimplementierung des PTPv2-Protokolls fordert der Switch einen Zeitstempel von der Firmware an. Das Problem ist, dass die Firmware zyklisch arbeitet und Sie warten müssen, bis der aktuelle Zyklus abgeschlossen ist, die Anforderung verarbeitet wird und nach Ablauf des nächsten Zyklus ein Zeitstempel ausgegeben wird. Dies wird auch einige Zeit dauern und wir werden eine Verzögerung erhalten, wenn auch nicht so bedeutend wie ohne Softwareunterstützung für PTPv2.

Nur die Hardware-Unterstützung für PTPv2 ermöglicht es Ihnen, die erforderliche Genauigkeit aufrechtzuerhalten. In diesem Fall erfolgt die Ausgabe des Zeitstempels durch einen speziellen ASIC, der am Port installiert ist.

Nachrichtenformat

Alle PTP-Nachrichten bestehen aus folgenden Feldern:

• Header - 34 Bytes.
• Körper - Die Größe hängt von der Art der Nachricht ab.
• Suffix (optional.

Header

Das Feld Header ist für alle PTP-Nachrichten gleich. Seine Größe beträgt 34 ​​Bytes.

Das Format des



Felds Header: messageType ist der Typ der übertragenen Nachricht, z. B. Sync, Delay_Req, PDelay_Req usw.

messageLength - enthält die volle Größe der PTP-Nachricht, einschließlich Header, Body und Suffix (jedoch ohne Füllbytes).

domainNumber - Bestimmt, zu welcher PTP-Domäne die Nachricht gehört.

Eine Domäne besteht aus einigen verschiedenen Uhren, die zu einer logischen Gruppe zusammengefasst und von einer führenden Uhr synchronisiert sind, jedoch nicht unbedingt mit einer Uhr synchronisiert sind, die zu einer anderen Domäne gehört.

Flags - Dieses Feld enthält verschiedene Flags, um den Status der Nachricht zu identifizieren.

Korrekturfeld- enthält die Verzögerungszeit in Nanosekunden. Die Verzögerungszeit umfasst die Übertragungsverzögerung durch den transparenten Takt sowie die Übertragungsverzögerung durch den Kanal bei Verwendung des Peer-to-Peer-Modus.

sourcePortIdentity - Dieses Feld enthält Informationen darüber, von welchem ​​Port diese Nachricht ursprünglich gesendet wurde.

sequenceID - enthält die Identifikationsnummer für einzelne Nachrichten.

controlField - Artefaktfeld =) Es stammt aus der ersten Version des Standards und enthält Informationen zum Typ dieser Nachricht. Im Wesentlichen dasselbe wie messageType, jedoch mit weniger Optionen.

logMessageInterval - Dieses Feld wird durch den Nachrichtentyp bestimmt.

Körper

Wie oben erläutert, gibt es verschiedene Arten von Nachrichten. Diese Typen werden im Folgenden beschrieben:

Ankündigungsnachricht Mit der Ankündigungsnachricht werden
andere Uhren innerhalb derselben Domäne über ihre Einstellungen informiert. Mit dieser Nachricht können Sie die Hierarchie „Leading Clock - Slave Clock“ einstellen.


Synchronisationsnachricht
Eine Synchronisationsnachricht (Sync) wird von der Hauptuhr gesendet und enthält die Uhrzeit der Hauptuhr zum Zeitpunkt der Erstellung der Synchronisierungsnachricht. Wenn die führende Uhr zweistufig ist, wird der Zeitstempel in der Synchronisierungsnachricht auf 0 gesetzt und der aktuelle Zeitstempel in der gepaarten Follow_Up-Nachricht gesendet. Die Synchronisierungsnachricht wird für beide Verzögerungsmessmechanismen verwendet.

Die Nachricht wird mit Multicast übertragen. Sie können optional Unicast verwenden.



Delay_Req-

Nachricht Das Format der Delay_Req- Nachricht ist identisch mit der Sync-Nachricht. Die Slave-Uhr sendet Delay_Req. Es enthält die Zeit, zu der Delay_Req von der Slave-Uhr gesendet wurde. Diese Nachricht wird nur für den Verzögerungsanforderungs-Antwort-Mechanismus verwendet.

Die Nachricht wird mit Multicast übertragen. Sie können optional Unicast verwenden.



Follow_Up-Nachricht Die Follow_Up-

Nachricht wird optional von der Hauptuhr gesendet und enthält die Uhrzeit, zu der der Assistent die Synchronisierungsnachricht gesendet hat . Die Follow_Up-Nachricht wird nur von einer zweistufigen Fahruhr gesendet.

Die Follow_Up-Nachricht wird für beide Verzögerungsmessmechanismen verwendet.

Die Nachricht wird mit Multicast übertragen. Sie können optional Unicast verwenden.



Nachricht Delay_Resp

Die Delay_Resp-Nachricht wird von der Hauptuhr gesendet. Es enthält die Zeit, zu der Delay_Req von der Hauptuhr empfangen wird. Diese Nachricht wird nur für den Verzögerungsanforderungs-Antwort-Mechanismus verwendet.

Die Nachricht wird mit Multicast übertragen. Sie können optional Unicast verwenden.



Pdelay_Req-

Nachricht Eine Pdelay_Req- Nachricht wird von einem Gerät gesendet, das eine Verzögerung anfordert. Es enthält die Zeit, zu der die Nachricht vom Port dieses Geräts gesendet wurde. Pdelay_Req wird nur für den Mechanismus zur Messung der Verzögerung benachbarter Knoten verwendet.



Pdelay_Resp-Nachricht Die Pdelay_Resp-

Nachricht wird von dem Gerät gesendet, das die Verzögerungsanforderung empfangen hat. Es enthält die Zeit, zu der die Pdelay_Req-Nachricht von diesem Gerät empfangen wurde. Pdelay_Resp-Nachrichten werden nur für den Mechanismus zur Messung der Verzögerung benachbarter Knoten verwendet.



Pdelay_Resp_Follow_Up-Nachricht Die Pdelay_Resp_Follow_Up-

Nachricht wird optional von dem Gerät gesendet, das die Verzögerungsanforderung empfangen hat. Es enthält die Zeit, zu der die Pdelay_Req-Nachricht von diesem Gerät empfangen wurde. Die Nachricht Pdelay_Resp_Follow_Up wird nur von einer zweistufigen Hauptuhr gesendet.

Diese Nachricht kann anstelle eines Zeitstempels auch zur Laufzeit verwendet werden. Die Ausführungszeit ist die Zeit vom Empfang von Pdelay-Req bis zum Senden von Pdelay_Resp.

Pdelay_Resp_Follow_Up werden nur für den Mechanismus zur Messung der Verzögerung benachbarter Knoten verwendet. Steuernachrichten



(Verwaltungsnachricht)

PTP-Steuernachrichten sind erforderlich, um Informationen zwischen einer oder mehreren Uhren und dem Steuerknoten zu übertragen.



Transfer zu LV

Eine PTP-Nachricht kann auf zwei Ebenen übertragen werden:

• Netzwerk - als Teil von IP-Daten.
• Link - als Teil eines Ethernet-Frames.

Senden einer PTP-Nachricht über UDP über IP über Ethernet



PTP über UDP über Ethernet PTP-



Profile

verfügen über viele „flexible“ Parameter, die konfiguriert werden müssen. Zum Beispiel:

• BMCA-Optionen.
• Der Verzögerungsmessmechanismus.
• Intervalle und Anfangswerte aller konfigurierbaren Parameter usw.

Und trotz der Tatsache, dass wir zuvor gesagt haben, dass PTPv2-Geräte miteinander kompatibel sind, ist dies in guter Weise nicht der Fall. Geräte müssen dieselben Einstellungen haben, um interagieren zu können.

Daher gibt es sogenannte PTPv2-Profile. Profile sind Gruppen konfigurierter Einstellungen und bestimmter Protokollbeschränkungen, sodass Sie die Zeitsynchronisierung für eine bestimmte Anwendung implementieren können.

Der IEEE 1588v2-Standard selbst beschreibt nur ein Profil - das „Standardprofil“. Alle anderen Profile werden von verschiedenen Organisationen und Verbänden erstellt und beschrieben.

Beispielsweise wurde das Leistungsprofil oder das PTPv2-Leistungsprofil vom Power Systems Relaying Committee und dem Substation Committee der IEEE Power and Energy Society erstellt. Das Profil selbst heißt IEEE C37.238-2011.

Das Profil beschreibt, dass PTP übertragen werden kann:

• Nur über L2-Netzwerke (d. H. Ethernet, HSR, PRP, nicht IP).
• Nachrichten werden nur von der Multicast-Mailingliste übertragen.
• Der Peer-Verzögerungsmessmechanismus wird als Verzögerungsmessmechanismus verwendet.

Die Standarddomäne ist 0, die empfohlene Domäne ist 93.

Die Philosophie beim Erstellen von C37.238-2011 war der Wunsch, die Anzahl der optionalen Funktionen zu reduzieren und nur die erforderlichen Funktionen für eine zuverlässige Interaktion zwischen Geräten zu belassen und die Systemstabilität zu erhöhen.

Außerdem wird die Frequenz der Nachrichtenübertragung bestimmt:



Tatsächlich steht nur ein Parameter zur Auswahl - der Typ des führenden Takts (einstufig oder zweistufig).

Die Genauigkeit sollte nicht mehr als 1 μs betragen. Mit anderen Worten können maximal 15 transparente Uhren oder drei Grenzstunden in einem Synchronisationspfad enthalten sein.