Einführung
Das Konzept zum Aufbau einer „Digital Substation“ in der Elektrizitätswirtschaft erfordert eine Synchronisation mit einer Genauigkeit von 1 μs. Auch bei Finanztransaktionen ist eine Genauigkeit im Mikrosekundenbereich erforderlich. Bei diesen Anwendungen reicht die NTP-Zeitgenauigkeit nicht mehr aus.
Das im IEEE 2v1588-Standard beschriebene PTPv2-Synchronisationsprotokoll ermöglicht eine Synchronisationsgenauigkeit von mehreren zehn Nanosekunden. Mit PTPv2 können Sie Synchronisierungspakete über L2- und L3-Netzwerke senden.
Die Hauptbereiche, in denen PTPv2 verwendet wird, sind:
- Energie;
- Kontroll- und Messgeräte;
- militärisch-industrieller Komplex;
- Telekommunikation;
- Finanzsektor.
In diesem Beitrag wird erläutert, wie das PTPv2-Synchronisierungsprotokoll funktioniert.
Wir haben mehr Erfahrung in der Industrie und sehen dieses Protokoll häufig in Energieanwendungen. Dementsprechend werden wir die Überprüfung mit Vorsicht 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 für die Organisation eines Prozessbusses mit Zeitsynchronisation über PTPv2.
Dies liegt daran, dass an den Prozessbus Relaisschutzklemmen und Messgeräte angeschlossen sind, die mittels sogenannter SV-Streams (Multicast-Streams) aktuelle Strom- und Spannungswerte über den Prozessbus übertragen.
Relaisschutzklemmen nutzen diese Werte zur Implementierung des Feldschutzes. Wenn die Genauigkeit der Zeitmessungen gering ist, können einige Schutzmaßnahmen fehlerhaft funktionieren.
Beispielsweise können Abwehrmechanismen der absoluten Selektivität einer „schwachen“ Zeitsynchronisation zum Opfer fallen. Oftmals basiert die Logik solcher Abwehrmaßnahmen auf einem Vergleich zweier Größen. Weichen die Werte um einen ausreichend großen Wert voneinander ab, dann wird der Schutz ausgelöst. Wenn diese Werte mit einer Zeitgenauigkeit von 1 ms gemessen werden, dann kann man einen großen Unterschied erhalten, wobei die Werte eigentlich normal sind, wenn man sie mit einer Genauigkeit von 1 μs misst.
PTP-Versionen
Das PTP-Protokoll wurde ursprünglich im Jahr 2002 im IEEE 1588-2002-Standard beschrieben und hieß „Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems“. Im Jahr 2008 wurde der aktualisierte Standard IEEE 1588-2008 veröffentlicht, der PTP Version 2 beschreibt. Diese Version des Protokolls verbesserte die Genauigkeit und Stabilität, behielt jedoch keine Abwärtskompatibilität mit der ersten Version des Protokolls bei. Außerdem wurde 2019 eine Version des Standards IEEE 1588-2019 veröffentlicht, die PTP v2.1 beschreibt. Diese Version fügt kleinere Verbesserungen zu PTPv2 hinzu und ist abwärtskompatibel mit PTPv2.
Mit anderen Worten, wir haben das folgende Bild mit Versionen:
PTPv1
(IEEE 1588-2002)
PTPv2
(IEEE 1588-2008)
PTPv2.1
(IEEE 1588-2019)
PTPv1 (IEEE 1588-2002)
-
Unvereinbar
Unvereinbar
PTPv2 (IEEE 1588-2008)
Unvereinbar
-
kompatibel
PTPv2.1 (IEEE 1588-2019)
Unvereinbar
kompatibel
-
Aber wie immer gibt es Nuancen.
Die Inkompatibilität zwischen PTPv1 und PTPv2 bedeutet, dass ein PTPv1-fähiges Gerät nicht mit einer genauen Uhr synchronisiert werden kann, die auf PTPv2 läuft. Zur Synchronisierung nutzen sie unterschiedliche Nachrichtenformate.
Es ist jedoch weiterhin möglich, Geräte mit PTPv1 und Geräte mit PTPv2 im selben Netzwerk zu kombinieren. Um dies zu erreichen, ermöglichen einige Hersteller die Auswahl der Protokollversion an den Edge-Clock-Ports. Das heißt, eine Boundary Clock kann sich über PTPv2 synchronisieren und dennoch andere mit ihr verbundene Uhren über PTPv1 und PTPv2 synchronisieren.
PTP-Geräte. Was sind sie und wie unterscheiden sie sich?
Der IEEE 1588v2-Standard beschreibt mehrere Gerätetypen. Alle sind in der Tabelle aufgeführt.
Die Geräte kommunizieren über ein LAN mittels PTP miteinander.
PTP-Geräte werden Uhren genannt. Alle Uhren geben die genaue Zeit der Großmeisteruhr an.
Es gibt 5 Arten von Uhren:
Großmeisteruhr
Die wichtigste Quelle für genaue Zeit. Oft mit einer Schnittstelle zum Anschluss von GPS ausgestattet.
Gewöhnliche Uhr
Ein Gerät mit einem Port, das ein Master (Master-Uhr) oder ein Slave (Slave-Uhr) sein kann.
Hauptuhr (Master)
Sie sind die Quelle der genauen Zeit, mit der andere Uhren synchronisiert werden
Nebenuhr
Endgerät, das von der Hauptuhr synchronisiert wird
Grenzuhr
Ein Gerät mit mehreren Ports, das Master oder Slave sein kann.
Das heißt, diese Uhren können sich von der übergeordneten Master-Uhr synchronisieren und die untergeordneten Slave-Uhren synchronisieren.
Durchgehend transparente Uhr
Ein Gerät mit mehreren Ports, das weder eine Hauptuhr noch ein Slave ist. Es überträgt PTP-Daten zwischen zwei Uhren.
Bei der Datenübertragung korrigiert die transparente Uhr alle PTP-Nachrichten.
Die Korrektur erfolgt durch Addition der Verzögerungszeit auf diesem Gerät zum Korrekturfeld im Header der übertragenen Nachricht.
Transparente Peer-to-Peer-Uhr
Ein Gerät mit mehreren Ports, das weder eine Hauptuhr noch ein Slave ist.
Es überträgt PTP-Daten zwischen zwei Uhren.
Bei der Datenübertragung korrigiert die transparente Uhr alle PTP-Nachrichten Sync und Follow_Up (mehr dazu weiter unten).
Die Korrektur wird erreicht, indem zum Korrekturfeld des übertragenen Pakets die Verzögerung auf dem Sendegerät und die Verzögerung auf dem Datenübertragungskanal hinzugefügt werden.
Verwaltungsknoten
Ein Gerät, das andere Uhren konfiguriert und diagnostiziert
Master- und Slave-Uhren werden mithilfe von Zeitstempeln in PTP-Nachrichten synchronisiert. Im PTP-Protokoll gibt es zwei Arten von Nachrichten:
- Ereignisnachrichten sind synchronisierte Nachrichten, bei denen zum Zeitpunkt des Sendens und Empfangens der Nachricht ein Zeitstempel generiert wird.
- Allgemeine Nachrichten – Für diese Nachrichten sind keine Zeitstempel erforderlich, sie können jedoch Zeitstempel für verwandte Nachrichten enthalten
Ereignismeldungen
Allgemeine Nachrichten
Synchronisierung
Verzögerung_Anforderung
Pdelay_Req
Pdelay_Resp
Bekannt geben
Nachverfolgen
Verzögerung_Resp
Pdelay_Resp_Follow_Up
Management
Signaling
Alle Arten von Nachrichten werden im Folgenden ausführlicher besprochen.
Grundlegende Synchronisationsprobleme
Wenn ein Synchronisationspaket über ein lokales Netzwerk übertragen wird, wird es am Switch und in der Datenverbindung verzögert. Jeder Wechsel erzeugt eine Verzögerung von etwa 10 Mikrosekunden, was für PTPv2 nicht akzeptabel ist. Schließlich müssen wir auf dem finalen Gerät eine Genauigkeit von 1 μs erreichen. (Dies ist der Fall, wenn es um Energie geht. Andere Anwendungen erfordern möglicherweise eine größere Genauigkeit.)
IEEE 1588v2 beschreibt mehrere Betriebsalgorithmen, mit denen Sie die Zeitverzögerung erfassen und korrigieren können.
Algorithmus der Arbeit
Im Normalbetrieb arbeitet das Protokoll in zwei Phasen.
- Phase 1 – Etablierung der „Master Clock – Slave Clock“-Hierarchie.
- Phase 2 – Taktsynchronisierung mithilfe eines End-to-End- oder Peer-to-Peer-Mechanismus.
Phase 1 – Aufbau der Master-Slave-Hierarchie
Jeder Port einer regulären oder Edge-Uhr hat eine bestimmte Anzahl von Zuständen (Slave-Uhr und Master-Uhr). Der Standard beschreibt den Übergangsalgorithmus zwischen diesen Zuständen. In der Programmierung wird ein solcher Algorithmus als endliche Zustandsmaschine oder Zustandsmaschine bezeichnet (mehr Details im Wiki).
Diese Zustandsmaschine verwendet den Best Master Clock Algorithm (BMCA), um den Master einzustellen, wenn zwei Uhren verbunden werden.
Dieser Algorithmus ermöglicht es der Uhr, die Aufgaben der Grandmaster-Uhr zu übernehmen, wenn die vorgeschaltete Grandmaster-Uhr das GPS-Signal verliert, offline geht usw.
Zustandsübergänge gemäß BMCA sind im folgenden Diagramm zusammengefasst:
Informationen über die Uhr am anderen Ende des „Kabels“ werden in einer speziellen Nachricht (Announce-Nachricht) gesendet. Sobald diese Informationen empfangen wurden, wird der Algorithmus der Zustandsmaschine ausgeführt und ein Vergleich durchgeführt, um festzustellen, welcher Takt besser ist. Der Port der besten Uhr wird zur Hauptuhr.
Eine einfache Hierarchie ist im Diagramm unten dargestellt. Die Pfade 1, 2, 3, 4, 5 können eine transparente Uhr enthalten, sind jedoch nicht an der Einrichtung der Master-Clock-Slave-Clock-Hierarchie beteiligt.
Phase 2 – Synchronisieren Sie reguläre und Edge-Takte
Unmittelbar nach der Etablierung der „Master Clock – Slave Clock“-Hierarchie beginnt die Synchronisationsphase von regulären und Boundary Clocks.
Zur Synchronisierung sendet die Hauptuhr eine Nachricht mit einem Zeitstempel an die Nebenuhren.
Die Hauptuhr kann sein:
- einstufig;
- zweistufig.
Einstufige Uhren senden zur Synchronisierung eine Sync-Nachricht.
Eine zweistufige Uhr verwendet zwei Nachrichten zur Synchronisierung – Sync und Follow_Up.
Für die Synchronisationsphase können zwei Mechanismen verwendet werden:
- Anforderungs-Antwort-Mechanismus verzögern.
- Mechanismus zur Messung der Peer-Verzögerung.
Schauen wir uns diese Mechanismen zunächst im einfachsten Fall an – wenn keine transparenten Uhren verwendet werden.
Anforderungs-Antwort-Mechanismus verzögern
Der Mechanismus umfasst zwei Schritte:
- Messung der Verzögerung bei der Übertragung einer Nachricht zwischen der Master-Uhr und der Slave-Uhr. Wird mithilfe eines Verzögerungs-Anfrage-Antwort-Mechanismus durchgeführt.
- Es wird eine Korrektur der genauen Zeitverschiebung durchgeführt.
Latenzmessung
t1 – Zeitpunkt des Sendens der Sync-Nachricht durch die Hauptuhr; t2 – Zeitpunkt des Empfangs der Sync-Nachricht durch die Nebenuhr; t3 – Zeitpunkt des Sendens der Verzögerungsanforderung (Delay_Req) durch die Nebenuhr; t4 – Delay_Req-Empfangszeit durch die Hauptuhr.
Wenn die Nebenuhr die Zeiten 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 berechnet – t-sm.
Wenn zwischen diesen beiden Werten eine gewisse Asymmetrie auftritt, liegt ein Fehler bei der Korrektur der Abweichung der genauen Zeit vor. Der Fehler wird dadurch verursacht, dass die berechnete Verzögerung der Durchschnitt der t-ms- und t-sm-Verzögerungen ist. Wenn die Verzögerungen nicht gleich sind, können wir die Zeit nicht genau anpassen.
Korrektur der Zeitverschiebung
Sobald die Verzögerung zwischen der Hauptuhr und der Nebenuhr bekannt ist, führt die Nebenuhr eine Zeitkorrektur durch.
Nebenuhren verwenden die Sync-Nachricht und eine optionale Follow_Up-Nachricht, um den genauen Zeitversatz bei der Übertragung eines Pakets vom Master an die Nebenuhren zu berechnen. Die Verschiebung wird nach folgender Formel berechnet:
Mechanismus zur Messung der Peer-Verzögerung
Dieser Mechanismus verwendet auch zwei Schritte zur Synchronisierung:
- Die Geräte messen die Zeitverzögerung zu allen Nachbarn über alle Ports. Dazu nutzen sie einen Peer-Verzögerungsmechanismus.
- Korrektur der genauen Zeitverschiebung.
Messung der Latenz zwischen Geräten, die den Peer-to-Peer-Modus unterstützen
Die Latenz zwischen Ports, die den Peer-to-Peer-Mechanismus unterstützen, 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 Sync-Nachricht oder optionale Follow_Up-Nachricht, die das Gerät durchläuft.
Die Gesamtverzögerung entspricht der Summe der Verzögerung während der Übertragung über dieses Gerät, der durchschnittlichen Verzögerung während der Übertragung über den Datenkanal und der bereits in dieser Nachricht enthaltenen Verzögerung, die auf Upstream-Geräten aktiviert ist.
Mit den Nachrichten Pdelay_Req, Pdelay_Resp und optional Pdelay_Resp_Follow_Up können Sie die Verzögerung vom Master zum Slave und vom Slave zum Master (zirkulär) abrufen.
Jede Asymmetrie zwischen diesen beiden Werten führt zu einem Zeitversatzkorrekturfehler.
Anpassen der genauen Zeitverschiebung
Nebenuhren verwenden eine Sync-Nachricht und eine optionale Follow_Up-Nachricht, um den genauen Zeitversatz bei der Übertragung eines Pakets vom Master an die Nebenuhren zu berechnen. Die Verschiebung wird nach folgender Formel berechnet:
Vorteile Anpassung des Peer-to-Peer-Mechanismus – die Zeitverzögerung jeder Sync- oder Follow_Up-Nachricht wird berechnet, während sie im Netzwerk übertragen wird. Daher hat eine Änderung des Übertragungsweges keinen Einfluss auf die Genauigkeit der Einstellung.
Bei Verwendung dieses Mechanismus erfordert die Zeitsynchronisierung keine Berechnung der Zeitverzögerung entlang des vom Synchronisierungspaket durchlaufenen Pfads, wie dies beim Basisaustausch der Fall ist. Diese. Delay_Req- und Delay_Resp-Nachrichten werden nicht gesendet. Bei dieser Methode wird die Verzögerung zwischen Master- und Slave-Uhr einfach im Anpassungsfeld jeder Sync- oder Follow_Up-Nachricht summiert.
Ein weiterer Vorteil besteht darin, dass die Hauptuhr von der Verarbeitung von Delay_Req-Nachrichten entlastet wird.
Betriebsarten transparenter Uhren
Demnach handelte es sich um einfache Beispiele. Nehmen wir nun an, dass Schalter auf dem Synchronisierungspfad erscheinen.
Wenn Sie Switches ohne PTPv2-Unterstützung verwenden, verzögert sich das Synchronisierungspaket auf dem Switch um ca. 10 µs.
Switches, die PTPv2 unterstützen, werden in der IEEE 1588v2-Terminologie als transparente Uhren bezeichnet. Transparente Uhren werden nicht von der Hauptuhr synchronisiert und nehmen nicht an der Hierarchie „Hauptuhr – Nebenuhr“ teil, aber bei der Übertragung von Synchronisationsnachrichten merken sie sich, wie lange die Nachricht von ihnen verzögert wurde. Dadurch können Sie die Zeitverzögerung anpassen.
Transparente Uhren können in zwei Modi betrieben werden:
- Ende zu Ende.
- Peer-To-Peer.
End-to-End (E2E)
Die transparente E2E-Uhr sendet Sync-Nachrichten und begleitende Follow_Up-Nachrichten auf allen Ports. Sogar diejenigen, die von einigen Protokollen blockiert werden (z. B. RSTP).
Der Switch merkt sich den Zeitstempel, wann ein Sync-Paket (Follow_Up) am Port empfangen und wann es vom Port gesendet wurde. Basierend auf diesen beiden Zeitstempeln wird die Zeit berechnet, die der Switch benötigt, um die Nachricht zu verarbeiten. In der Norm wird diese Zeit als Verweilzeit bezeichnet.
Die Verarbeitungszeit wird zum Feld „correctionField“ der Sync- (einstufiger Takt) oder Follow_Up-Nachricht (zweistufiger Takt) hinzugefügt.
Die transparente E2E-Uhr misst die Verarbeitungszeit für Sync- und Delay_Req-Nachrichten, die den Switch passieren. Es ist jedoch wichtig zu verstehen, dass die Zeitverzögerung zwischen der Master-Uhr und der Slave-Uhr mithilfe des Verzögerungs-Anfrage-Antwort-Mechanismus berechnet wird. Ändert sich die Master-Uhr oder ändert sich der Weg von der Master-Uhr zur Slave-Uhr, wird die Verzögerung erneut gemessen. Dies erhöht die Übergangszeit bei Netzwerkänderungen.
Die transparente P2P-Uhr misst nicht nur die Zeit, die ein Switch benötigt, um eine Nachricht zu verarbeiten, sondern misst auch die Verzögerung auf der Datenverbindung zu seinem nächsten Nachbarn mithilfe eines Nachbarlatenzmechanismus.
Die Latenz wird für jede Verbindung in beide Richtungen gemessen, einschließlich Verbindungen, die durch ein Protokoll (z. B. RSTP) blockiert werden. Dadurch können Sie sofort die neue Verzögerung im Synchronisationspfad berechnen, wenn sich die Grandmaster-Uhr oder die Netzwerktopologie ändert.
Beim Senden von Sync- oder Follow_Up-Nachrichten summieren sich die Nachrichtenverarbeitungszeit durch Switches und die Latenz.
Arten der PTPv2-Unterstützung durch Switches
Switches können PTPv2 unterstützen:
- programmatisch;
- Hardware.
Bei der Implementierung des PTPv2-Protokolls in Software fordert der Switch einen Zeitstempel von der Firmware an. Das Problem besteht darin, dass die Firmware zyklisch arbeitet und Sie warten müssen, bis sie den aktuellen Zyklus beendet, die Anforderung zur Verarbeitung entgegennimmt und nach dem nächsten Zyklus einen Zeitstempel ausgibt. Auch dies wird einige Zeit in Anspruch nehmen und es kommt zu einer Verzögerung, wenn auch nicht so stark wie ohne Softwareunterstützung für PTPv2.
Nur die Hardwareunterstützung für PTPv2 ermöglicht es Ihnen, die erforderliche Genauigkeit aufrechtzuerhalten. In diesem Fall wird der Zeitstempel von einem speziellen ASIC ausgegeben, der auf dem Port installiert ist.
Nachrichtenformat
Alle PTP-Nachrichten bestehen aus den folgenden Feldern:
- Header – 34 Bytes.
- Textkörper – Größe hängt von der Art der Nachricht ab.
- Suffix ist optional.
Kopfzeile
Das Header-Feld ist für alle PTP-Nachrichten gleich. Seine Größe beträgt 34 Byte.
Header-Feldformat:
Nachrichtentyp – enthält den Typ der übertragenen Nachricht, zum Beispiel Sync, Delay_Req, PDelay_Req usw.
Nachrichtenlänge – enthält die volle Größe der PTP-Nachricht, einschließlich Header, Text und Suffix (jedoch ohne Füllbytes).
domainNumber – bestimmt, zu welcher PTP-Domäne die Nachricht gehört.
Домен – Hierbei handelt es sich um mehrere unterschiedliche Uhren, die in einer logischen Gruppe zusammengefasst und von einer Hauptuhr synchronisiert werden, jedoch nicht unbedingt mit Uhren synchronisiert werden, die zu einer anderen Domäne gehören.
Fahnen – Dieses Feld enthält verschiedene Flags zur Identifizierung des Status der Nachricht.
KorrekturFeld – enthält die Verzögerungszeit in Nanosekunden. Die Verzögerungszeit umfasst die Verzögerung bei der Übertragung durch die transparente Uhr sowie die Verzögerung bei der Übertragung 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.
Sequenz-ID – enthält eine Identifikationsnummer für einzelne Nachrichten.
controlField – Artefaktfeld =) Es bleibt aus der ersten Version des Standards und enthält Informationen über den Typ dieser Nachricht. Im Wesentlichen dasselbe wie messageType, jedoch mit weniger Optionen.
logMessageInterval – Dieses Feld wird durch den Nachrichtentyp bestimmt.
Body
Wie oben erläutert, gibt es verschiedene Arten von Nachrichten. Diese Typen werden im Folgenden beschrieben:
Ankündigungsnachricht
Die Announce-Nachricht wird verwendet, um anderen Uhren innerhalb derselben Domäne ihre Parameter mitzuteilen. Mit dieser Nachricht können Sie eine Master-Clock-Slave-Clock-Hierarchie einrichten.
Nachrichtensynchronisierung
Die Sync-Nachricht wird von der Hauptuhr gesendet und enthält die Uhrzeit der Hauptuhr zum Zeitpunkt der Generierung der Sync-Nachricht. Wenn die Hauptuhr zweistufig ist, wird der Zeitstempel in der Sync-Nachricht auf 0 gesetzt und der aktuelle Zeitstempel in der zugehörigen Follow_Up-Nachricht gesendet. Die Sync-Nachricht wird für beide Latenzmessmechanismen verwendet.
Die Übertragung der Nachricht erfolgt mittels Multicast. Optional können Sie Unicast verwenden.
Delay_Req-Nachricht
Das Format der Delay_Req-Nachricht ist identisch mit der Sync-Nachricht. Die Nebenuhr sendet Delay_Req. Es enthält die Zeit, zu der die Delay_Req von der Nebenuhr gesendet wurde. Diese Nachricht wird nur für den Verzögerungs-Anfrage-Antwort-Mechanismus verwendet.
Die Übertragung der Nachricht erfolgt mittels Multicast. Optional können Sie Unicast verwenden.
Follow_Up-Nachricht
Die Follow_Up-Nachricht wird optional von der Hauptuhr gesendet und enthält den Zeitpunkt des Sendens Nachrichten synchronisieren Meister. Nur zweistufige Hauptuhren senden die Follow_Up-Nachricht.
Die Follow_Up-Nachricht wird für beide Latenzmessmechanismen verwendet.
Die Übertragung der Nachricht erfolgt mittels Multicast. Optional können Sie Unicast verwenden.
Delay_Resp-Nachricht
Die Delay_Resp-Nachricht wird von der Hauptuhr gesendet. Es enthält die Zeit, zu der die Delay_Req von der Hauptuhr empfangen wurde. Diese Nachricht wird nur für den Verzögerungs-Anfrage-Antwort-Mechanismus verwendet.
Die Übertragung der Nachricht erfolgt mittels Multicast. Optional können Sie Unicast verwenden.
Pdelay_Req-Nachricht
Die Pdelay_Req-Nachricht wird von einem Gerät gesendet, das eine Verzögerung anfordert. Es enthält den Zeitpunkt, zu dem die Nachricht vom Port dieses Geräts gesendet wurde. Pdelay_Req wird nur für den Nachbarverzögerungsmessmechanismus verwendet.
Pdelay_Resp-Nachricht
Die Pdelay_Resp-Nachricht wird von einem Gerät gesendet, das eine Verzögerungsanforderung erhalten hat. Es enthält die Zeit, zu der die Pdelay_Req-Nachricht von diesem Gerät empfangen wurde. Die Pdelay_Resp-Nachricht wird nur für den Nachbarverzögerungsmessmechanismus verwendet.
Nachricht Pdelay_Resp_Follow_Up
Die Pdelay_Resp_Follow_Up-Nachricht wird optional von dem Gerät gesendet, das die Verzögerungsanforderung erhalten hat. Es enthält die Zeit, zu der die Pdelay_Req-Nachricht von diesem Gerät empfangen wurde. Die Pdelay_Resp_Follow_Up-Nachricht wird nur von zweistufigen Hauptuhren gesendet.
Diese Nachricht kann anstelle eines Zeitstempels auch für die Ausführungszeit 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 Nachbarverzögerungsmessmechanismus verwendet.
Managementnachrichten
PTP-Steuernachrichten sind erforderlich, um Informationen zwischen einer oder mehreren Uhren und dem Steuerknoten zu übertragen.
Transfer nach LV
Eine PTP-Nachricht kann auf zwei Ebenen übertragen werden:
- Netzwerk – als Teil der IP-Daten.
- Kanal – als Teil eines Ethernet-Frames.
PTP-Nachrichtenübertragung über UDP über IP über Ethernet
PTP über UDP über Ethernet
Profile
PTP verfügt über eine ganze Reihe flexibler Parameter, die konfiguriert werden müssen. Zum Beispiel:
- BMCA-Optionen.
- Latenzmessmechanismus.
- Intervalle und Anfangswerte aller konfigurierbaren Parameter usw.
Und obwohl wir zuvor gesagt haben, dass PTPv2-Geräte miteinander kompatibel sind, stimmt das nicht. Um kommunizieren zu können, müssen die Geräte die gleichen Einstellungen haben.
Deshalb gibt es sogenannte PTPv2-Profile. Profile sind Gruppen konfigurierter Einstellungen und definierter Protokolleinschränkungen, damit die Zeitsynchronisierung für eine bestimmte Anwendung implementiert werden kann.
Der IEEE 1588v2-Standard selbst beschreibt nur ein Profil – „Default Profile“. Alle anderen Profile werden von verschiedenen Organisationen und Verbänden erstellt und beschrieben.
Beispielsweise wurde das Power Profile oder PTPv2 Power Profile 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 per Multicast-Broadcast übertragen.
- Der Peer-Verzögerungsmessmechanismus wird als Verzögerungsmessmechanismus verwendet.
Die Standarddomäne ist 0, die empfohlene Domäne ist 93.
Die Designphilosophie von C37.238-2011 bestand darin, die Anzahl optionaler Funktionen zu reduzieren und nur die notwendigen Funktionen für eine zuverlässige Interaktion zwischen Geräten und eine erhöhte Systemstabilität beizubehalten.
Außerdem wird die Häufigkeit der Nachrichtenübermittlung bestimmt:
Tatsächlich steht nur ein Parameter zur Auswahl – die Art der Hauptuhr (einstufig oder zweistufig).
Die Genauigkeit sollte nicht mehr als 1 μs betragen. Mit anderen Worten: Ein Synchronisationspfad kann maximal 15 transparente Uhren oder drei Boundary Clocks enthalten.
Source: habr.com