Details zur Umsetzung des Zeit-Synchronisationsprotokolls PTPv2

Einführung

Das Konzept zum Aufbau einer "Digitalen Umspannstation" in der Elektroenergiebranche erfordert eine Synchronisation mit einer Genauigkeit von 1 µs. Auch für die Durchführung von finanziellen Transaktionen ist eine Genauigkeit in Mikrosekunden notwendig. In diesen Anwendungen reicht die Genauigkeit der NTP-Zeitmessung bereits nicht mehr aus.

Das Zeit-Synchronisationsprotokoll PTPv2, das im Standard IEEE 1588v2 beschrieben ist, ermöglicht eine Synchronisationsgenauigkeit von wenigen Dutzend Nanosekunden. PTPv2 erlaubt das Senden von Synchronisationspaketen über L2- und L3-Netze.

Die Hauptbereiche, in denen PTPv2 eingesetzt wird, sind:

• Energiewirtschaft;
• Mess- und Prüfgeräte;
• Verteidigung und Industriekomplex;
• Telekommunikation;
• Finanzsektor.

In diesem Beitrag wird erörtert, wie das Zeit-Synchronisationsprotokoll PTPv2 funktioniert.

Wir haben mehr Erfahrung in der Industrie und treffen häufig auf dieses Protokoll in der Energiewirtschaft. Daher werden wir auch die Übersicht mit einem Fokus auf die Energiewirtschaft geben. Warum ist es notwendig?.

Derzeit enthalten die Normen STO 34.01-21-004-2019 der PJSC "Rosseti" und STO 56947007-29.240.10.302-2020 der PJSC "FSK EES" Anforderungen an die Organisation eines Prozessbusses mit Gewährleistung der Zeit-Synchronisation nach PTPv2.

Dies hängt damit zusammen, dass an den Prozessbus Terminals für relaischutz und Messgeräte angeschlossen sind, die über den Prozessbus durch sogenannte SV-Streams (Multicast-Streams) sofortige Werte für Strom und Spannung übertragen.

Die Terminals für relaischutz nutzen diese Werte zur Implementierung von Schutzmaßnahmen für Anschlüsse. Wenn die Genauigkeit der Zeitmessung gering ist, können einige Schutzmaßnahmen fälschlicherweise aktiv werden.

Beispielsweise können Schutzmaßnahmen für absolute Selektivität Opfer einer "schwachen" Zeit-Synchronisation werden. Oft basiert die Logik solcher Schutzmaßnahmen auf dem Vergleich zweier Größen. Wenn die Werte sich um einen ausreichenden Betrag unterscheiden, wird der Schutz aktiviert. Wenn diese Größen mit einer Zeitgenauigkeit von 1 ms gemessen werden, kann eine große Abweichung auftreten, während die Werte tatsächlich im Normbereich liegen, wenn sie mit einer Genauigkeit von 1 µs gemessen werden.

Versionen von PTP

PTP-Versionen

Das PTP-Protokoll wurde ursprünglich im Jahr 2002 im Standard IEEE 1588-2002 beschrieben und trug den Titel „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. In dieser Version des Protokolls wurden die Genauigkeit und Stabilität verbessert, jedoch wurde die Rückwärtskompatibilität zur ersten Version des Protokolls nicht beibehalten. Außerdem wurde 2019 die Version des Standards IEEE 1588-2019 eingeführt, 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 mit den Versionen:

PTPv1
(IEEE 1588-2002)

PTPv2
(IEEE 1588-2008)

PTPv2.1
(IEEE 1588-2019)

PTPv1 (IEEE 1588-2002)

—
Nicht kompatibel

Nicht kompatibel

PTPv2 (IEEE 1588-2008)

Nicht kompatibel

—
Kompatibel

PTPv2.1 (IEEE 1588-2019)

Nicht kompatibel

Kompatibel

—

Aber wie immer gibt es Nuancen.

Die Inkompatibilität zwischen PTPv1 und PTPv2 bedeutet, dass ein PTPv1-fähiges Gerät nicht mit präzisen Uhren, die auf PTPv2 basieren, synchronisiert werden kann. Für die Synchronisierung verwenden sie unterschiedliche Nachrichtenformate.

Es ist jedoch möglich, Geräte mit PTPv1 und Geräte mit PTPv2 im selben Netzwerk zu kombinieren. Dafür erlauben einige Hersteller, dass an den Ports der Grenzuhren die Protokollversion ausgewählt werden kann. Das bedeutet, dass Grenzuhren sich über PTPv2 synchronisieren können und gleichzeitig andere angeschlossene Uhren sowohl über PTPv1 als auch über PTPv2 synchronisieren können.

PTP-Geräte. Welche Arten gibt es und wie unterscheiden sie sich?

Der Standard IEEE 1588v2 beschreibt mehrere Gerätetypen. Alle sind in der Tabelle aufgeführt.

Die Geräte interagieren über LAN und verwenden PTP.

PTP-Geräte werden als Uhren bezeichnet. Alle Uhren beziehen die genaue Zeit von Meisteruhren.

Es gibt 5 Arten von Uhren:

Grandmaster clock (Meisteruhr)

Die Hauptquelle für genaue Zeit. Oft mit einem GPS-Anschluss ausgestattet.

Ordinary Clock (Gewöhnliche Uhr)

Ein Gerät mit einem Port, das als Meister (führende Uhr) oder Slave (nachfolgende Uhr) fungieren kann.

Führende Uhren (Meister)

Sind die Quelle der genauen Zeit, nach der sich andere Uhren synchronisieren.

Nachfolgende Uhren (Slaves)

Endgerät, das sich von führenden Uhren synchronisiert.

Boundary Clock (Grenzuhren)

Gerät mit mehreren Ports, das Meister oder Slave sein kann.

Das bedeutet, dass diese Uhren sich von übergeordneten führenden Uhren synchronisieren können und untergeordnete nachfolgende Uhren synchronisieren.

End-to-End Transparente Uhr (End-to-End transparente Uhren)

Ein Mehrportgerät, das weder eine Master Uhr noch eine Slave Uhr ist. Es überträgt PTP-Daten zwischen zwei Uhren.

Bei der Datenübertragung korrigiert die transparente Uhr alle PTP-Nachrichten.

Die Korrektur erfolgt durch Hinzufügen von Verzögerungszeit auf diesem Gerät im Korrekturfeld im Header der übertragenen Nachricht.

Peer-to-Peer Transparente Uhr (Peer-to-Peer transparente Uhren)

Ein Mehrportgerät, das weder eine Master Uhr noch eine Slave Uhr ist.
Es überträgt PTP-Daten zwischen zwei Uhren.

Bei der Datenübertragung korrigiert die transparente Uhr alle PTP-Nachrichten Sync und Follow_Up (darüber wird weiter unten mehr gesagt).

Die Korrektur erfolgt durch Hinzufügen von Verzögerungen zum Korrekturfeld des übertragenen Pakets und zur Verzögerung im Übertragungsweg.

Management Knoten (Verwaltungsknoten)

Ein Gerät, das andere Uhren konfiguriert und diagnostiziert.

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

• Ereignisnachrichten – dies sind synchronisierte Nachrichten, die die Generierung eines Zeitstempels zum Zeitpunkt des Sendens der Nachricht und beim Empfang der Nachricht vorsehen.
• Allgemeine Nachrichten – diese Nachrichten erfordern keine Zeitstempel, können jedoch Zeitstempel für verwandte Nachrichten enthalten.

Ereignisnachrichten

Allgemeine Nachrichten

Sync
Delay_Req
Pdelay_Req
Pdelay_Resp

Ankündigung
Follow_Up
Delay_Resp
Pdelay_Resp_Follow_Up
Management
Signalisierung

Im Folgenden werden alle Nachrichtentypen genauer betrachtet.

Hauptprobleme bei der Synchronisation

Bei der Übertragung eines Synchronisationspakets über ein Netzwerk wird es am Switch und im Übertragungsweg verzögert. Jeder Switch verursacht eine Verzögerung von etwa 10 µs, was für PTPv2 inakzeptabel ist. Schließlich müssen wir auf dem Endgerät eine Genauigkeit von 1 µs erreichen. (Dies gilt für die Energiewirtschaft. Andere Anwendungen könnten noch höhere Genauigkeiten erfordern.)

In IEEE 1588v2 sind mehrere Betriebsalgorithmen beschrieben, die es ermöglichen, die Zeitverzögerung zu erfassen und zu korrigieren.

Betriebsalgorithmus
Im Normalbetrieb arbeitet das Protokoll in zwei Phasen.

• Phase 1 – Einrichtung der Hierarchie "Master Uhren – Slave Uhren".
• Phase 2 – Synchronisation der Uhren mittels des End-to-End- oder Peer-to-Peer-Mechanismus.

Phase 1 — Einrichtung der Hierarchie „Master-Slave“

Jeder Anschluss gewöhnlicher oder Grenzuhren hat eine bestimmte Anzahl von Zuständen (Slave-Uhren und Master-Uhren). Der Standard beschreibt den Algorithmus zum Übergang zwischen diesen Zuständen. In der Programmierung wird ein solcher Algorithmus als endlicher Automat oder Zustandsmaschine bezeichnet (weitere Informationen in der Wiki).

Dieser endliche Automat verwendet den Best Master Clock Algorithm (BMCA), um den Master bei der Verbindung von zwei Uhren festzulegen.

Dieser Algorithmus ermöglicht es Uhren, die Verantwortung für Masteruhren zu übernehmen, wenn übergeordnete Masteruhren das GPS-Signal verlieren, vom Netz getrennt werden usw.

Die Übergänge zwischen den Zuständen gemäß BMCA sind in der folgenden Abbildung kurz dargestellt:


Die Informationen über die Uhren am anderen Ende des „Kabels“ werden in einer speziellen Nachricht (Announce-Nachricht) gesendet. Sobald diese Informationen empfangen werden, wird der Zustandsmaschinenalgorithmus ausgeführt, und es erfolgt ein Vergleich, welche Uhren besser sind. Der Anschluss der besten Uhren wird zur Master-Uhr.

Eine einfache Hierarchie ist im folgenden Schema dargestellt. Die Wege 1, 2, 3, 4, 5 können transparente Uhren (Transparent Clock) enthalten, die jedoch nicht an der Einrichtung der Hierarchie „Masteruhren – Slaveuhren“ beteiligt sind.

Phase 2 — Synchronisation der gewöhnlichen und Grenzuhren

Unmittelbar nach der Einrichtung der Hierarchie „Masteruhren – Slaveuhren“ beginnt die Phase der Synchronisation von gewöhnlichen und Grenzuhren.

Zur Synchronisation senden die Masteruhren den Slave-Uhren eine Nachricht, die einen Zeitstempel enthält.

Masteruhren können sein:

• einzelstufig;
• zwei-stufig.

Einzelstufige Uhren senden zur Synchronisation eine Nachricht Sync.

Zwei-stufige Uhren verwenden zur Synchronisation zwei Nachrichten – Sync und Follow_Up.

Für die Phase der Synchronisation können zwei Mechanismen verwendet werden:

• Mechanismus der verzögerten Anfrage-Antwort (Delay request-response mechanism).
• Mechanismus zur Messung der Verzögerung des benachbarten Knotens (Peer delay measurement mechanism).

Lassen Sie uns zunächst diese Mechanismen im einfachsten Fall betrachten – wenn keine transparenten Uhren verwendet werden.

Mechanismus der verzögerten Anfrage-Antwort (Delay request-response mechanism)

Der Mechanismus sieht zwei Schritte vor:

1. Messung der Verzögerung beim Übertragen der Nachricht zwischen den Masteruhren und den Slave-Uhren. Dies erfolgt mittels des Mechanismus der verzögerten Anfrage-Antwort.
2. Es erfolgt eine Korrektur der Zeitverschiebung.

Messung der Verzögerung


t1 – Zeitpunkt des Sendevorgangs der Sync-Nutzdaten; t2 – Zeitpunkt des Empfangs der Sync-Nutzdaten durch die Slave-Uhren; t3 – Zeitpunkt der Anfrage zur Verzögerung (Delay_Req) durch die Slave-Uhren; t4 – Zeitpunkt des Empfangs des Delay_Req durch die Master-Uhren.

Wenn die Slave-Uhren die Zeiten t1, t2, t3 und t4 kennen, können sie die durchschnittliche Verzögerung bei der Übertragung der Synchronisierungsnachricht (tmpd) berechnen. Diese wird wie folgt berechnet:

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

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

Wenn zwischen diesen beiden Werten eine Asymmetrie auftritt, entsteht ein Fehler bei der Korrektur des exakten Zeitabgleichs. Der Fehler rührt daher, dass die berechnete Verzögerung der Durchschnitt der Verzögerungen t-ms und t-sm ist. Wenn die Verzögerungen ungleich sind, werden wir die Zeit ungenau korrigieren.

Korrektur des exakten Zeitabgleichs

Nachdem die Verzögerung zwischen den Master- und Slave-Uhren bekannt ist, führen die Slave-Uhren die Zeitkorrektur durch.

Die Slave-Uhren verwenden die Sync-Nachricht und die optionale Follow_Up-Nachricht, um den exakten Zeitversatz bei der Übertragung des Paketes von den Master-Uhren zu den Slave-Uhren zu berechnen. Der Versatz wird nach folgender Formel berechnet:

Mechanismus zur Messung der Verzögerung des benachbarten Knotens (Peer Delay Measurement Mechanism)

Dieser Mechanismus verwendet ebenfalls zwei Schritte zur Synchronisierung:

1. Die Geräte messen die Zeitverzögerung zu allen Nachbarn über alle Ports. Zu diesem Zweck verwenden sie den Peer Delay Mechanismus.
2. Korrektur des exakten Zeitversatzes.

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 Anpassungsfeldes für jede Sync-Nachricht oder optionale Follow_Up-Nachricht, die durch dieses Gerät geleitet wird.

Die Gesamtdelaysumme ergibt sich aus der Verzögerung bei der Übertragung durch dieses Gerät, der durchschnittlichen Verzögerung bei der Übertragung über den Datenkanal und der bereits in dieser Nachricht enthaltenen Verzögerung, die auf übergeordneten Geräten abgeschaltet wurde.

Die Nachrichten Pdelay_Req, Pdelay_Resp und das optionale Pdelay_Resp_Follow_Up ermöglichen es, die Verzögerung vom Master zum Slave und vom Slave zum Master (kreisförmig) zu erhalten.

Jede Asymmetrie zwischen diesen beiden Werten führt zu einer Korrekturfehler des genauen Zeitversatzes.

Korrektur des genauen Zeitversatzes

Die Slave-Uhren verwenden das Sync-Nachricht und die optionale Follow_Up-Nachricht zur Berechnung des genauen Zeitversatzes bei der Übertragung des Pakets von den Master-Uhren zu den Slave-Uhren. Der Versatz wird nach folgender Formel berechnet:

Ein Vorteil des Peer-to-Peer-Korrekturmechanismus besteht darin, dass die Verzögerung jeder Sync- oder Follow_Up-Nachricht während der Übertragung im Netzwerk berechnet wird. Daher hat eine Änderung des Übertragungsweges keine Auswirkungen auf die Genauigkeit der Korrektur.

Bei der Verwendung dieses Mechanismus benötigt die Zeit Synchronisation keine Berechnung der Verzögerung des über das Synchronisationspaket zurückgelegten Weges, wie dies beim Basis-Austausch der Fall ist. Das heißt, die Nachrichten Delay_Req und Delay_Resp werden nicht gesendet. In dieser Methode wird die Verzögerung zwischen den Master- und Slave-Uhren einfach im Korrekturfeld jeder Sync- oder Follow_Up-Nachricht summiert.

Ein weiterer Vorteil ist, dass die Master-Uhren von der Notwendigkeit entlastet werden, die Nachrichten Delay_Req zu verarbeiten.

Betriebsmodi transparenter Uhren

Entsprechend wurden einfache Beispiele analysiert. Nehmen wir nun an, dass Switches auf dem Synchronisationsweg auftauchen.

Wenn Switches ohne PTPv2-Unterstützung verwendet werden, wird das Synchronisationspaket im Switch um etwa 10 µs verzögert.

Switches mit PTPv2-Unterstützung werden in der Terminologie der IEEE 1588v2 als transparente Uhren (Transparent clock) bezeichnet. Transparente Uhren synchronisieren sich nicht mit den Master-Uhren und nehmen nicht an der Hierarchie „Master-Uhr – Slave-Uhr“ teil, speichern aber bei der Übertragung von Synchronisationsnachrichten, wie lange die Nachricht dort verzögert wurde. Dies ermöglicht die Korrektur der Zeitverzögerung.

Transparente Uhren können in zwei Modi arbeiten:

• End-to-End.
• Peer-to-Peer.

End-to-End (E2E)

E2E-transparente Uhren übertragen Sync-Nachrichten und zugehörige Follow_Up-Nachrichten an alle Ports. Selbst an die, die durch bestimmte Protokolle (z.B. RSTP) blockiert sind.

Der Switch speichert den Zeitstempel, wann das Sync-Paket (Follow_Up) am Port empfangen und wann es vom Port gesendet wurde. Basierend auf diesen beiden Zeitstempeln wird die Verarbeitungszeit der Nachrichten im Switch berechnet. In den Standards wird diese Zeit als Aufenthaltszeit bezeichnet.

Die Verarbeitungszeit wird im Feld correctionField der Sync-Nachricht (ein Schritt Uhren) oder Follow_Up (zwei Schritt Uhren) hinzugefügt.

Transparente E2E-Uhren messen die Verarbeitungszeit für Sync- und Delay_Req-Nachrichten, die durch den Switch wandern. Dabei ist es wichtig zu verstehen, dass die Verzögerungszeit zwischen den Master- und den Slave-Uhren mittels eines Frage-Antwort-Verzögerungsmechanismus berechnet wird. Wenn sich die Master-Uhren ändern oder der Weg von den Master-Uhren zu den Slave-Uhren wechselt, wird die Verzögerung neu gemessen. Dies erhöht die Übergangszeit im Falle von Änderungen im Netzwerk.

Transparente P2P-Uhren messen neben der Verarbeitungszeit der Nachricht durch den Switch auch die Verzögerung im Übertragungsweg zum nächsten Nachbarn, mithilfe des Mechanismus zur Messung der Nachbarverzögerung.

Die Verzögerung wird in beide Richtungen an jedem Kanal gemessen, auch an Kanälen, die durch ein Protokoll blockiert sind (z. B. RSTP). Dadurch kann sofort die neue Verzögerung auf dem Synchronisationsweg berechnet werden, wenn sich die Master-Uhren oder die Netzwerktopologie geändert haben.

Die Verarbeitungszeiten der Nachrichten durch die Switches und die Verzögerungszeiten werden bei der Übertragung von Sync- oder Follow_Up-Nachrichten akkumuliert.

Unterstützungstypen von PTPv2 durch Switches

Switches können PTPv2 unterstützen:

• softwareseitig;
• hardwareseitig.

Bei der softwareseitigen Implementierung des PTPv2-Protokolls fragt der Switch den Zeitstempel von der Firmware an. Das Problem dabei ist, dass die Firmware zyklisch arbeitet, sodass man warten muss, bis sie den aktuellen Zyklus abgeschlossen hat, die Anfrage bearbeitet und im nächsten Zyklus den Zeitstempel ausgibt. Auch dies benötigt Zeit, sodass eine Verzögerung entsteht, die jedoch nicht so erheblich ist wie ohne die softwareseitige PTPv2-Unterstützung.

Die erforderliche Genauigkeit kann nur durch hardwareseitige Unterstützung von PTPv2 gewährleistet werden. In diesem Fall erfolgt die Ausgabe des Zeitstempels durch einen speziellen ASIC, der am Port installiert ist.

Nachrichtenformat

Alle PTP-Nachrichten bestehen aus den folgenden Feldern:

• Header – 34 Bytes.
• Body – Größe variiert je nach Nachrichtentyp.
• 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 Gesamtgröße der PTP-Nachricht, einschließlich Header, Body und Suffix (aber ohne Auffüllbytes).

domainNumber – bestimmt, zu welchem Domain PTP die Nachricht gehört.

Domäne – ist eine Gruppe von verschiedenen Uhren, die zu einer logischen Gruppe zusammengefasst sind und von einer Masteruhr synchronisiert werden, aber nicht unbedingt mit Uhren synchronisiert sind, die zu einer anderen Domäne gehören.

flags – dieses Feld enthält verschiedene Flags zur Identifikation des Status der Nachricht.

correctionField – enthält die Verzögerungszeit in Nanosekunden. Die Verzögerung umfasst die Übertragungsverzögerung durch transparente Uhren sowie die Verzögerung bei der Übertragung durch den Kanal im 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 individuelle Nachrichten.

controlField – Feld-Aktualisierung =) Es stammt aus der ersten Version des Standards und enthält Informationen über den Typ dieser Nachricht. Im Wesentlichen dasselbe wie messageType, aber mit weniger Optionen.

logMessageInterval – dieses Feld wird durch den Nachrichtentyp bestimmt.

Body

Wie oben besprochen, gibt es mehrere Nachrichtentypen. Diese Typen sind unten beschrieben:

Ankündigungsnachricht
Die Ankündigungsnachricht wird verwendet, um anderen Uhren innerhalb einer Domäne von ihren Parametern zu "erzählen". Diese Nachricht ermöglicht die Festlegung einer Hierarchie von "Masteruhren – Slaveuhren."


Synchronisationsnachricht
Die Synchronisationsnachricht (Sync) wird von Masteruhren gesendet und enthält die Zeit der Masteruhr zu dem Zeitpunkt, als die Sync-Nachricht erstellt wurde. Wenn die Masteruhren zweistufig sind, wird der Zeitstempel in der Sync-Nachricht auf 0 gesetzt, und der aktuelle Zeitstempel wird in der zugehörigen Follow_Up-Nachricht gesendet. 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 der Sync-Nachricht. Die Slaveuhren senden Delay_Req. Es enthält die Zeit, zu der Delay_Req von den Slaveuhren gesendet wurde. Diese Nachricht wird nur für den Anfrage-Antwort-Mechanismus zur Verzögerung verwendet.

Die Nachricht wird über Multicast übertragen. Optional kann Unicast verwendet werden.

Nachricht Follow_Up

Die Nachricht Follow_Up wird optional von den führenden Uhren gesendet und enthält die Zeit der Sendung Nachricht Sync meister. Die Nachricht Follow_Up wird nur von zweistufigen führenden Uhren gesendet.

Die Nachricht Follow_Up 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 Nachricht Delay_Resp wird von den führenden Uhren gesendet. Sie enthält die Empfangszeit von Delay_Req durch die führenden Uhren. Diese Nachricht wird nur für den Mechanismus der Anfrage-Antwort-Verzögerung verwendet.

Die Nachricht wird über Multicast übertragen. Optional kann Unicast verwendet werden.

Nachricht Pdelay_Req

Die Nachricht Pdelay_Req wird von dem Gerät gesendet, das die Verzögerung anfordert. Sie enthält die Sendezeit der Nachricht von diesem Gerät. Pdelay_Req wird nur für den Mechanismus der Verzögerungsmessung des benachbarten Knotens verwendet.

Nachricht Pdelay_Resp

Die Nachricht Pdelay_Resp wird von dem Gerät gesendet, das die Anfrage zur Verzögerung erhalten hat. Sie enthält die Empfangszeit der Nachricht Pdelay_Req durch dieses Gerät. Die Nachrichten Pdelay_Resp werden nur für den Mechanismus zur Verzögerungsmessung des benachbarten Knotens verwendet.

Nachricht Pdelay_Resp_Follow_Up

Die Nachricht Pdelay_Resp_Follow_Up wird optional von dem Gerät gesendet, das die Anfrage zur Verzögerung erhalten hat. Sie enthält die Empfangszeit der Nachricht Pdelay_Req durch dieses Gerät. Die Nachricht Pdelay_Resp_Follow_Up wird nur von zweistufigen führenden Uhren gesendet.

Diese Nachricht kann auch für die Ausführungszeit anstelle des Zeitstempels 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 Verzögerungsmessung des benachbarten Knotens verwendet.

Verwaltungsnachrichten (Nachricht Management)

Die Verwaltungsnachrichten PTP sind notwendig, um Informationen zwischen einer oder mehreren Uhren und dem Steuerknoten zu übertragen.

Übertragung in der LAN

PTP-Nachrichten können auf zwei Ebenen übertragen werden:

• Netzwerkebene – als Teil der IP-Daten.
• Schnittstellebene – als Teil des Ethernet-Frames.

Übertragung von PTP-Nachrichten über UDP über IP über Ethernet

PTP über UDP über Ethernet

Profile

PTP hat eine Reihe von "flexiblen" Parametern, die konfiguriert werden müssen. Zum Beispiel:

• BMCA-Optionen.
• Mechanismus zur Verzögerungsmessung.
• Intervalle und Anfangswerte aller konfigurierbaren Parameter usw.

Und obwohl wir zuvor gesagt haben, dass PTPv2-Geräte untereinander kompatibel sind, ist das nicht unbedingt korrekt. Die Geräte müssen die gleichen Einstellungen haben, um zu interagieren.

Daher gibt es die sogenannten PTPv2-Profile. Profile sind Gruppen von konfigurierten Einstellungen und bestimmten Protokollbeschränkungen, um die Zeitsynchronisation 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 Vereinigungen erstellt und beschrieben.

Zum Beispiel wurde das Profil für die Elektroenergie 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, kein IP).
• Die Nachrichten werden nur durch Multicast gesendet.
• Als Mechanismus zur Messung der Verzögerung wird der Peer Delay Measurement Mechanism verwendet.

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

Das Konzept von C37.238-2011 beruhte 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 zur Erhöhung der Systemstabilität beizubehalten.

Außerdem wurde die Frequenz der Nachrichtenübertragung definiert:

Im Wesentlichen steht nur ein Parameter zur Auswahl – der Typ der Master-Uhr (einfach oder doppelt).

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

Quelle: habr.com