Einführung
Das Konzept des Aufbaus einer "Digitalen Umspannstation" in der Elektrotechnik erfordert eine Synchronisation mit einer Genauigkeit von 1 µs. Auch für Finanztransaktionen ist eine Genauigkeit im µs-Bereich erforderlich. In diesen Anwendungen reicht die Genauigkeit der NTP-Zeit nicht mehr aus.
Das Synchronisationsprotokoll PTPv2, das im Standard IEEE 1588v2 beschrieben ist, ermöglicht eine Synchronisationsgenauigkeit von mehreren Dutzend Nanosekunden. PTPv2 kann Synchronisationspakete über L2- und L3-Netzwerke senden.
Die Hauptbereiche, in denen PTPv2 angewendet wird, sind:
- Energieversorgung;
- Mess- und Regeltechnik;
- Verteidigungsindustrie;
- Telekommunikation;
- Finanzsektor.
In diesem Beitrag wird erklärt, wie das Synchronisationsprotokoll PTPv2 funktioniert.
Wir haben mehr Erfahrung in der Industrie und kommen oft mit diesem Protokoll in der Energiewirtschaft in Berührung. Daher werden wir auch die Übersicht .
Warum ist das notwendig?
Aktuell sind in den Standards 34.01-21-004-2019 von PAO "Rosseti" und 56947007-29.240.10.302-2020 von PAO "FSK AES" Anforderungen an die Organisation des Prozessbusses mit der Gewährleistung der Zeit-Synchronisation nach PTPv2 festgelegt.
Dies hängt damit zusammen, dass sich an den Prozessbush die Relais- und Messgeräte anschließen, die über den Prozessbus mithilfe sogenannter SV-Streams (Multicast-Streams) die aktuellen Werte von Strom und Spannung übertragen.
Die Relais-Schutzgeräte nutzen diese Werte zur Implementierung von Schutzmaßnahmen für Anschlüsse. Wenn die Zeitgenauigkeit der Messungen gering ist, können einige Schutzmechanismen fälschlicherweise ausgelöst werden.
Zum Beispiel können Schutzmechanismen mit „schwacher“ Zeit-Synchronisation darunter leiden. Oft basiert die Logik solcher Schutzmaßnahmen auf dem Vergleich zweier Werte. Wenn diese Werte um einen beträchtlichen Betrag abweichen, wird der Schutz aktiviert. Wenn man diese Werte mit einer Zeitgenauigkeit von 1 ms misst, kann es zu großen Differenzen kommen, während die Werte in Wirklichkeit im Normbereich liegen, wenn man sie mit einer Genauigkeit von 1 µs misst.
Versionen von PTP
Das PTP-Protokoll wurde ursprünglich 2002 im Standard IEEE 1588-2002 beschrieben und trug den Titel „Standard für ein Präzisions-Uhrensynchronisationsprotokoll für vernetzte Mess- und Steuerungssysteme“. 2008 wurde der aktualisierte Standard IEEE 1588-2008 veröffentlicht, der PTP Version 2 beschreibt. In dieser Version des Protokolls wurden die Genauigkeit und Stabilität verbessert, die Rückwärtskompatibilität zur ersten Version wurde jedoch nicht gewahrt. Außerdem wurde 2019 eine Version des Standards IEEE 1588-2019 veröffentlicht, die PTP v2.1 beschreibt. Diese Version fügt kleine Verbesserungen zu PTPv2 hinzu und ist rückwärtskompatibel mit PTPv2.
Mit anderen Worten, wir haben folgendes Bild von den Versionen:
PTPv1
(IEEE 1588-2002)
PTPv2
(IEEE 1588-2008)
PTPv2.1
(IEEE 1588-2019)
PTPv1 (IEEE 1588-2002)
—
Inkompatibel
Inkompatibel
PTPv2 (IEEE 1588-2008)
Inkompatibel
—
Kompatibel
PTPv2.1 (IEEE 1588-2019)
Inkompatibel
Kompatibel
—
Aber wie immer gibt es Feinheiten.
Die Inkompatibilität zwischen PTPv1 und PTPv2 bedeutet, dass ein Gerät mit Unterstützung für PTPv1 nicht von präzisen Uhren synchronisiert werden kann, die auf PTPv2 basieren. Für die Synchronisation verwenden sie unterschiedliche Nachrichtenformate.
Es ist möglich, Geräte mit PTPv1 und solche mit PTPv2 im selben Netzwerk zu kombinieren. Einige Hersteller ermöglichen es, die Protokollversion an den Ports der Boundary Clocks auszuwählen. Das bedeutet, dass Boundary Clocks sich nach PTPv2 synchronisieren können und gleichzeitig andere angeschlossene Uhren sowohl nach PTPv1 als auch nach PTPv2 synchronisieren.
PTP-Geräte. Welche gibt es und wie unterscheiden sie sich?
Der Standard IEEE 1588v2 beschreibt mehrere Typen von Geräten. Alle sind in der Tabelle aufgeführt.
Die Geräte kommunizieren über ein LAN und verwenden PTP.
PTP-Geräte werden als Uhren bezeichnet. Alle Uhren beziehen die genaue Zeit von den Grandmaster-Uhren.
Es gibt 5 Arten von Uhren:
Grandmaster Clock (Grandmaster-Uhren)
Die Hauptquelle für präzise Zeit. Oft mit einer Schnittstelle zur GPS-Anbindung ausgestattet.
Ordinary Clock (Ordinary Uhren)
Ein Gerät mit einem einzigen Port, das entweder Master (führende Uhr) oder Slave (folgende Uhr) sein kann.
Master Clock (führende Uhr)
Sie sind die Quelle der genauen Zeit, nach der sich andere Uhren synchronisieren.
Slave Clock (folgende Uhr)
Das Endgerät, das sich von der führenden Uhr synchronisiert.
Boundary Clock (Boundary-Uhren)
Ein Gerät mit mehreren Ports, das als Master oder Slave fungieren kann.
Das bedeutet, dass diese Uhren sich von übergeordneten Master-Uhren synchronisieren und untergeordnete Slave-Uhren synchronisieren können.
End-to-End Transparent Clock (End-to-End transparente Uhr)
Ein Gerät mit mehreren Ports, das weder Master- noch Slave-Uhr ist. Es überträgt PTP-Daten zwischen zwei Uhren.
Bei der Datenübertragung korrigieren die transparenten Uhren alle PTP-Nachrichten.
Die Korrektur erfolgt durch das Hinzufügen der Verzögerungszeit auf diesem Gerät im Korrekturfeld des übertragenden Nachrichtenheaders.
Peer-to-Peer Transparent Clock (Peer-to-Peer transparente Uhr)
Ein Gerät mit mehreren Ports, das weder Master- noch Slave-Uhr ist.
Es überträgt PTP-Daten zwischen zwei Uhren.
Bei der Datenübertragung korrigieren die transparenten Uhren alle PTP-Nachrichten Sync und Follow_Up (darüber wird weiter unten ausführlicher berichtet).
Die Korrektur erfolgt durch das Hinzufügen von Verzögerungen im Korrekturfeld des übertragenden Pakets und der Verzögerung im Übertragungskanal.
Management Node (Verwaltungsknoten)
Ein Gerät, das andere Uhren konfiguriert und diagnostiziert.
Führende und folgende Uhren werden über Zeitstempel in PTP-Nachrichten synchronisiert. Es gibt zwei Arten von Nachrichten im PTP-Protokoll:
- Event-Nachrichten – dies sind synchronisierte Nachrichten, die die Generierung eines Zeitstempels zum Zeitpunkt des Sendens und des Empfangs der Nachricht vorsehen.
- General-Nachrichten – diese Nachrichten erfordern keine Zeitstempel, können aber Zeitstempel für verwandte Nachrichten enthalten.
Event-Nachrichten
General-Nachrichten
Sync
Delay_Req
Pdelay_Req
Pdelay_Resp
Announce
Follow_Up
Delay_Resp
Pdelay_Resp_Follow_Up
Management
Signaling
Alle Nachrichtentypen werden im Folgenden genauer betrachtet.
Hauptprobleme der Synchronisation
Beim Übertragen eines Synchronisationspakets über ein lokales Netzwerk wird es am Switch und im Übertragungskanal verzögert. Jeder Switch verursacht eine Verzögerung von etwa 10 µs, was für PTPv2 nicht akzeptabel ist. Unser Endgerät benötigt eine Genauigkeit von 1 µs. (Das gilt insbesondere für den Energiesektor. Andere Anwendungen können sogar eine höhere Genauigkeit erfordern.)
In IEEE 1588v2 werden mehrere Arbeitsalgorithmen beschrieben, die eine Zeitzahlung erfassen und korrigieren können.
Funktionsweise
Bei normalem Betrieb arbeitet das Protokoll in zwei Phasen.
- Phase 1 – Einrichtung der Hierarchie "Master – Slave".
- Phase 2 – Synchronisierung der Uhren mittels End-to-End- oder Peer-to-Peer-Mechanismus.
Phase 1 – Einrichtung der Hierarchie "Master-Slave".
Jeder Port von normalen oder Grenzuhren hat eine bestimmte Anzahl von Zuständen (Führende Uhren und Folguhr). Der Standard beschreibt den Algorithmus für den Übergang zwischen diesen Zuständen. In der Programmierung wird ein solcher Algorithmus als endlicher Automat oder Zustandsmaschine bezeichnet (weitere Informationen finden Sie in der Wiki).
Dieser endliche Automat verwendet den Best Master Clock Algorithm (BMCA), um beim Verbinden zweier Uhren einen Master einzurichten.
Dieser Algorithmus ermöglicht es den Uhren, die Aufgaben der Großmeisteruhr zu übernehmen, wenn die übergeordneten Großmeisteruhren das GPS-Signal verlieren, vom Netzwerk getrennt werden usw.
Die Zustandsübergänge gemäß BMCA sind kurz in folgendem Diagramm dargestellt:
Die Informationen über die Uhrzeit am anderen Ende des «Kabels» werden in einer speziellen Nachricht (Announce message) übermittelt. Sobald diese Informationen empfangen werden, wird der Zustandsautomaten-Algorithmus aktiv und vergleicht, welche Uhr die bessere ist. Der Anschluss an der besten Uhr wird zur führenden Uhr.
Eine einfache Hierarchie ist im Diagramm unten dargestellt. Die Pfade 1, 2, 3, 4, 5 können transparente Uhren (Transparent clock) enthalten, spielen jedoch keine Rolle bei der Festlegung der Hierarchie "Führende Uhr – Folgene Uhr".
Phase 2 — Synchronisierung von normalen und Grenzuhren
Sofort nach der Festlegung der Hierarchie "Führende Uhr – Folgene Uhr" beginnt die Phase der Synchronisierung von normalen und Grenzuhren.
Zur Synchronisierung senden die führenden Uhren den Folgene Uhren eine Nachricht mit einem Zeitstempel.
Führende Uhren können sein:
- einstufig;
- zweistufig.
Einstufige Uhren senden zur Synchronisierung eine Nachricht Sync.
Zweistufige Uhren verwenden zur Synchronisierung zwei Nachrichten – Sync und Follow_Up.
Für die Synchronisierungsphase können zwei Mechanismen verwendet werden:
- Delay request-response mechanism.
- Peer delay measurement mechanism.
Beginnen wir mit diesen Mechanismen im einfachsten Fall, bei dem keine transparenten Uhren verwendet werden.
Mechanismus der verzögerten Anfrage-Antwort (Delay request-response mechanism)
Der Mechanismus besteht aus zwei Schritten:
- Messung der Verzögerung bei der Übertragung von Nachrichten zwischen den führenden und den nachfolgenden Uhren. Dies erfolgt über den verzögerten Anfrage-Antwort-Mechanismus.
- Eine Korrektur der Zeitverschiebung erfolgt.
Messung der Verzögerung
t1 – Zeitpunkt der Synchronisationsnachricht, die von den führenden Uhren gesendet wird; t2 – Zeitpunkt des Empfangs der Synchronisationsnachricht durch die nachfolgenden Uhren; t3 – Zeitpunkt des Versands der Verzögerungsanfrage (Delay_Req) von den nachfolgenden Uhren; t4 – Zeitpunkt des Empfangs von Delay_Req durch die führenden Uhren.
Wenn die nachfolgenden Uhren die Zeiten t1, t2, t3 und t4 kennen, können sie die durchschnittliche Verzögerung bei der Übertragung der Synchronisationsnachricht (tmpd) berechnen. Sie wird wie folgt berechnet:
Bei der Übertragung der Synchronisationsnachricht und Follow_Up wird die Zeitverzögerung vom Master zum Slave als t-ms berechnet.
Bei der Übertragung der Nachrichten Delay_Req und Delay_Resp wird die Zeitverzögerung vom Slave zum Master als t-sm berechnet.
Wenn zwischen diesen beiden Werten eine Asymmetrie auftritt, entsteht ein Fehler bei der Korrektur der genauen Zeit. Dieser Fehler wird dadurch verursacht, dass die berechnete Verzögerung der Durchschnitt aus den Verzögerungen t-ms und t-sm ist. Wenn die Verzögerungen ungleich sind, werden wir die Zeit ungenau korrelieren.
Korrektur der zeitlichen Verschiebung
Sobald die Verzögerung zwischen der führenden Uhr und den nachfolgenden Uhren bekannt ist, führen die nachfolgenden Uhren die Zeitkorrektur durch.
Die nachfolgenden Uhren nutzen die Sync-Nachricht und die optionale Follow_Up-Nachricht, um die Verschiebung der genauen Zeit während der Übertragung eines Pakets von den führenden Uhren zu den nachfolgenden zu berechnen. Die Verschiebung wird mit folgender Formel berechnet:
Mechanismus zur Messung der Verzögerung benachbarter Knoten
Dieser Mechanismus verwendet ebenfalls zwei Schritte zur Synchronisierung:
- Die Geräte messen die Zeitverzögerung zu allen Nachbarn über alle Ports hinweg. Dazu verwenden sie den Peer-Delay-Mechanismus.
- Korrektur der zeitlichen Verschiebung.
Messung der Verzögerung zwischen Geräten, die den Peer-to-Peer-Modus unterstützen
Die Verzögerung zwischen den Ports, die den Peer-to-Peer-Mechanismus unterstützen, wird durch folgende Nachrichten gemessen:
Wenn dem Port 1 die Zeiten t1, t2, t3 und t4 bekannt sind, kann er die durchschnittliche Verzögerung (tmld) berechnen. Diese wird nach folgender Formel berechnet:
Anschließend verwendet der Port diesen Wert zur Berechnung des Korrekturfeldes für jede Sync-Nachricht oder optionale Follow_Up-Nachricht, die durch das Gerät geleitet wird.
Die Gesamtverzögerung entspricht der Summe der Verzögerung beim Durchlauf durch das jeweilige Gerät, der durchschnittlichen Verzögerung über den Datenkanal und der bereits in der Nachricht enthaltenen Verzögerung, die von übergeordneten Geräten eingefügt wurde.
Die Nachrichten Pdelay_Req, Pdelay_Resp und die optionale Pdelay_Resp_Follow_Up ermöglichen die Ermittlung der Verzögerung vom Master zum Slave und vom Slave zum Master (kumulative Verzögerung).
Jede Asymmetrie zwischen diesen beiden Werten führt zu einem Fehler in der Korrektur des präzisen Zeitversatzes.
Korrektur des präzisen Zeitversatzes
Die Slave-Uhren verwenden die Sync-Nachricht und die optionale Follow_Up-Nachricht zur Berechnung des präzisen Zeitversatzes beim Versand des Pakets von den Master-Uhren zu den Slave-Uhren. Der Zeitversatz wird nach folgender Formel berechnet:
Die Vorteile einer Korrekturmechanismus für Peer-to-Peer – die Verzögerungszeit jeder Sync- oder Follow-Up-Nachricht wird während ihrer Übertragung im Netzwerk berechnet. Daher wird eine Änderung des Übertragungswegs die Genauigkeit der Korrektur nicht beeinflussen.
Bei der Verwendung dieses Mechanismus erfordert die Zeit-Synchronisation keine Berechnung der Verzögerungszeit für den Pfad, den das Synchronisierungspaket durchläuft, wie es beim Basis-Austausch der Fall ist. D.h. die Nachrichten Delay_Req und Delay_Resp werden nicht gesendet. In diesem Verfahren wird die Verzögerung zwischen der führenden und der nachfolgenden Uhr einfach im Korrekturfeld jeder Sync- oder Follow-Up-Nachricht summiert.
Ein weiterer Vorteil besteht darin, dass die führenden Uhren von der Notwendigkeit entlastet werden, die Nachrichten Delay_Req zu verarbeiten.
Betriebsmodi transparenter Uhren
Dies waren einfache Beispiele. Nehmen wir jetzt an, dass während der Synchronisation Switches auftreten.
Wenn Switches ohne Unterstützung für PTPv2 verwendet werden, wird das Synchronisierungspaket etwa 10 µs im Switch verzögert.
PTPv2-fähige Switches werden in der IEEE 1588v2-Terminologie als transparente Uhren (Transparent Clock) bezeichnet. Transparente Uhren synchronisieren sich nicht mit den Master-Uhren und sind nicht Teil der Hierarchie „Master - Slave“, sie speichern jedoch die Verzögerung, die beim Empfang von Synchronisationsnachrichten aufgetreten ist. Dadurch kann die Zeitverzögerung korrigiert werden.
Transparente Uhren können in zwei Modi betrieben werden:
- End-to-End.
- Peer-to-Peer.
End-to-End (E2E)
Transparente E2E-Uhren senden Sync-Nachrichten und zugehörige Follow_Up-Nachrichten an alle Ports, selbst an solche, die durch Protokolle wie z.B. RSTP blockiert sind.
Der Switch speichert den Zeitstempel, zu dem das Sync-Paket (Follow_Up) am Port empfangen und wann es vom Port gesendet wurde. Auf Basis dieser beiden Zeitstempel wird die Verarbeitungszeit des Switches für die Nachricht berechnet. In der Norm wird diese Zeit als Residence Time bezeichnet.
Die Verarbeitungszeit wird in das correctionField der Sync-Nachricht (ein-stufige Uhren) oder Follow_Up (zwei-stufige Uhren) eingefügt.
Die transparenten E2E-Uhren messen die Verarbeitungszeit für Sync- und Delay_Req-Nachrichten, die durch den Switch geleitet werden. Es ist jedoch wichtig zu verstehen, dass die Verzögerung zwischen der Master- und der Slave-Uhr durch ein Anfrage-Antwort-Mechanismus zur Verzögerungsmessung berechnet wird. Wenn die Master-Uhren wechseln oder sich der Weg von den Master- zu den Slave-Uhren ändert, wird die Verzögerung erneut gemessen. Dies erhöht die Übergangszeit im Falle von Netzwerkänderungen.
Neben der Messung der Verarbeitungszeit von Nachrichten durch den Switch messen die transparenten P2P-Uhren die Verzögerung im Übertragungskanal zum nächsten Nachbarn unter Verwendung eines Mechanismus zur Verzögerungsmessung 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. Dadurch kann die neue Verzögerung auf dem Synchronisationspfad sofort berechnet werden, wenn sich die Master-Uhren oder die Topologie des Netzwerks ändern.
Die Verarbeitungszeiten für Nachrichten durch Switches und die Verzögerungszeiten werden bei der Übertragung von Sync- oder Follow_Up-Nachrichten kumuliert.
Unterstützungsarten für PTPv2 durch Switches
Switches können PTPv2 unterstützen:
- softwareseitig;
- hardwareseitig.
Bei der softwareseitigen Implementierung des PTPv2-Protokolls fragt der Switch einen Zeitstempel von der Firmware an. Das Problem besteht darin, dass die Firmware zyklisch arbeitet und daher gewartet werden muss, bis der aktuelle Zyklus abgeschlossen ist, das Anforderung bearbeitet wird und im nächsten Zyklus der Zeitstempel ausgegeben wird. Auch dies erfordert Zeit und führt zu einer Verzögerung, die zwar nicht so erheblich ist wie ohne softwareseitige Unterstützung für PTPv2.
Nur hardwareseitige Unterstützung für PTPv2 ermöglicht die notwendige Genauigkeit. 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.
- Body – Die Größe hängt vom Nachrichtentyp ab.
- Suffix – optional.
Header
Das Header-Feld ist für alle PTP-Nachrichten gleich. Seine Größe beträgt 34 Bytes.
Format des Header-Feldes:
messageType – enthält den Typ der übermittelten Nachricht, z. B. Sync, Delay_Req, PDelay_Req usw.
messageLength – enthält die gesamte Größe der PTP-Nachricht, einschließlich Header, Body und Suffix (aber ohne Füllbytes).
domainNumber – bestimmt, zu welchem Domain PTP die Nachricht gehört.
Domain – das sind mehrere verschiedene Uhren, die zu einer logischen Gruppe zusammengefasst und von einer Hauptuhr synchronisiert werden, jedoch nicht unbedingt mit Uhren, die zu einer anderen Domäne gehören, synchronisiert sind.
flags – dieses Feld enthält verschiedene Flags zur Identifizierung des Status der Nachricht.
correctionField – enthält die Verzögerungszeit in Nanosekunden. Die Verzögerungszeit umfasst die Verzögerung beim Übertragen durch transparente Uhren sowie die Verzögerung beim Übertragen über den Kanal im Peer-to-Peer-Modus.
sourcePortIdentity – dieses Feld enthält Informationen darüber, von welchem Port die Nachricht ursprünglich gesendet wurde.
sequenceID – enthält die Identifikationsnummer für einzelne Nachrichten.
controlField – ein Artefaktfeld=) Es stammt aus der ersten Version des Standards und enthält Informationen über den Typ der Nachricht. Es ist im Wesentlichen das Gleiche wie messageType, jedoch mit weniger Optionen.
logMessageInterval – dieses Feld wird durch den Nachrichtentyp definiert.
Body
Wie oben diskutiert, gibt es mehrere Typen von Nachrichten. Diese Typen sind nachfolgend beschrieben:
Nachricht Ankündigung
Die Announce-Nachricht wird verwendet, um anderen Uhren innerhalb einer Domäne über ihre Parameter zu "informieren". Diese Nachricht ermöglicht es, eine Hierarchie von "Master-Uhren – Slave-Uhren" festzulegen.
Sync-Nachricht
Die Synchronisationsnachricht (Sync) wird von den Master-Uhren gesendet und enthält die Zeit der Master-Uhren zum Zeitpunkt, als die Sync-Nachricht erstellt wurde. Wenn die Master-Uhren zweistufig sind, wird der Zeitstempel in der Sync-Nachricht auf 0 gesetzt, während der aktuelle Zeitstempel in der verbundenen Follow_Up-Nachricht gesendet wird. Die Sync-Nachricht wird für beide Mechanismen zur Messung der Verzögerung verwendet.
Die Nachricht wird über Multicast übertragen. Optional kann Unicast verwendet werden.
Delay_Req-Nachricht
Das Format der Delay_Req-Nachricht ist identisch mit dem der Sync-Nachricht. Die Slave-Uhren senden Delay_Req. Sie enthält die Sendezeit der Delay_Req von den Slave-Uhren. Diese Nachricht wird ausschließlich für den Anfrage-Antwort-Mechanismus der Verzögerung verwendet.
Die Nachricht wird über Multicast übertragen. Optional kann Unicast verwendet werden.
Follow_Up-Nachricht
Die Follow_Up-Nachricht wird optional von den Master-Uhren gesendet und enthält die Sendezeit der Sync-Nachricht vom Master. Die Follow_Up-Nachricht wird nur von zweistufigen Master-Uhren gesendet.
Die Follow_Up-Nachricht wird für beide Mechanismen zur Messung der Verzögerung verwendet.
Die Nachricht wird über Multicast übertragen. Optional kann Unicast verwendet werden.
Nachricht Delay_Resp
Die Delay_Resp-Nachricht wird von den Masteruhren gesendet. Sie enthält die Empfangszeit von Delay_Req durch die Masteruhren. Diese Nachricht wird ausschließlich für den Request-Response-Mechanismus zur Verzögerungsmessung verwendet.
Die Nachricht wird über Multicast übertragen. Optional kann Unicast verwendet werden.
Nachricht Pdelay_Req
Die Pdelay_Req-Nachricht wird von dem Gerät gesendet, das die Verzögerung anfragt. Sie enthält die Zeit der Sendung der Nachricht von diesem Gerät. Pdelay_Req wird nur für den Mechanismus zur Verzögerungsmessung des benachbarten Knotens verwendet.
Nachricht Pdelay_Resp
Die Pdelay_Resp-Nachricht wird von dem Gerät gesendet, das die Verzögerungsanfrage erhalten hat. Sie enthält die Empfangszeit der Pdelay_Req-Nachricht durch dieses Gerät. Die Pdelay_Resp-Nachricht wird ausschließlich für den Mechanismus zur Verzögerungsmessung des benachbarten Knotens verwendet.
Nachricht Pdelay_Resp_Follow_Up
Die Pdelay_Resp_Follow_Up-Nachricht wird optional von dem Gerät gesendet, das die Verzögerungsanfrage erhalten hat. Sie enthält die Empfangszeit der Pdelay_Req-Nachricht durch dieses Gerät. Die Pdelay_Resp_Follow_Up-Nachricht wird nur von den zweistufigen Masteruhren gesendet.
Diese Nachricht kann auch zur Laufzeit anstelle des Zeitstempels verwendet werden. Die Laufzeit ist die Zeit vom Empfang der Pdelay-Req bis zum Versand der Pdelay_Resp.
Pdelay_Resp_Follow_Up wird nur für das Mechanismus zur Messung der Verzögerung des benachbarten Knotens verwendet.
Management-Nachrichten
PTP-Management-Nachrichten sind erforderlich, um Informationen zwischen einer oder mehreren Uhren und dem Managementknoten auszutauschen.
Übertragung im LV
PTP-Nachrichten können auf zwei Ebenen übertragen werden:
- Netzwerkebene – als Teil der IP-Daten.
- Sichtbarkeitsebene – als Teil des Ethernet-Frames.
Übertragung von PTP-Nachrichten über UDP über IP über Ethernet
PTP über UDP über Ethernet
Profile
PTP bietet eine Vielzahl von "flexiblen" Parametern, die konfiguriert werden müssen. Zum Beispiel:
- BMCA-Optionen.
- Mechanismus zur Messung der Verzögerung.
- Intervalle und Anfangswerte aller konfigurierbaren Parameter usw.
Und obwohl wir früher gesagt haben, dass PTPv2-Geräte miteinander kompatibel sind, ist das in der Praxis nicht ganz richtig. Die Geräte müssen dieselben Einstellungen haben, um miteinander zu kommunizieren.
Deshalb gibt es die sogenannten PTPv2-Profile. Profile sind Gruppen von konfigurierten Einstellungen und bestimmten Einschränkungen des Protokolls, um eine Zeit-Synchronisation für eine bestimmte Anwendung zu ermöglichen.
Der Standard IEEE 1588v2 beschreibt nur ein Profil – das „Default Profile“. Alle anderen Profile wurden von verschiedenen Organisationen und Verbänden erstellt und beschrieben.
Zum Beispiel wurde das Profil für die Energiewirtschaft oder das PTPv2 Power Profile vom Power Systems Relaying Committee und dem Substation Committee der IEEE Power and Energy Society erstellt. Das Profil trägt den Namen IEEE C37.238-2011.
Das Profil beschreibt, dass PTP übertragen werden kann:
- Nur über L2-Netzwerke (d.h. Ethernet, HSR, PRP, nicht IP).
- Die Nachrichten werden nur durch Multicast gesendet.
- Als Mechanismus zur Messung der Verzögerung wird der Peer delay measurement mechanism verwendet.
Die Standarddomäne ist 0, die empfohlene Domäne ist 93.
Das Konzept von C37.238-2011 basiert auf dem Wunsch, die Anzahl der optionalen Merkmale zu reduzieren und nur die notwendigen Funktionen für eine zuverlässige Interaktion zwischen Geräten und die Stabilität des Systems zu belassen.
Außerdem wurde die Übertragungsfrequenz der Nachrichten definiert:
Im Grunde genommen gibt es nur ein Auswahlkriterium – den Typ der Master-Uhren (ein- oder zweistufig).
Die Genauigkeit darf nicht mehr als 1 µs betragen. Mit anderen Worten, in einem Synchronisationsweg können maximal 15 transparente Uhren oder drei Grenzüberschreitungsuhren enthalten sein.
Quelle: habr.com
