PTP – Precision Time Protocol

Perle Systems - Technischer Hinweis

PTP – Precision Time Protocol

IEEE 1588 V1 und V2 PTP Boundary Clock Kompetenzen in Industriellen Managed Switches

Mit einer Genauigkeit im Millisekundenbereich sind Network Time Protocol (NTP) und Simple Network Time Protocol (SNTP) beliebte Methoden zur Synchronisation verteilter Uhren in einem lokalen Netz (Local Area Network, LAN). Für industrielle Netzwerke ist zur Uhrensynchronisation allerdings eine sehr viel größere Präzision erforderlich.

Der erstmals 2002 für Automatisierungs- und Messanwendungen eingesetzte Standard IEEE 1588 für Precision Time Protocol (PTP) bietet eine Methode zur Uhrensynchronisation im Mikrosekundenbereich. 2004 wurde PTP außerdem im Standard IEC 61588 eingeführt. Und in 2008 wurde die Version 2 des Standards IEEE 1588 für den Einsatz bei Anwendungen im Bereich Telekommunikation und Audio-Video Bridging ratifiziert.

PTP ist überall da gefragt, wo Prozesse exakt synchronisiert werden müssen, z. B. für Automatisierungs- und Regelsysteme, Messsysteme und automatische Prüfsysteme, Energieerzeugungs-, übertragungs- und verteilungssyteme sowie Telekommunikation.

Funktion von PTP

Eine einfache Lösung zur Synchronisation von Uhren in einem Ethernet-Netz besteht möglicherweise darin, eine Nachricht mit dem Wert der Master-Uhr an die Slaves zu senden. Nach Erhalt der Nachricht würden die Slaves ihre eigenen Uhren in Übereinstimmung mit dem Wert der Master-Uhr korrigieren. Der Zeitaufwand für die Übertragung der Meldung aufgrund von Signalverzögerungen im Ethernet-Pfad und Verzögerungen durch Prozessor-Warteschlangen, IP-Telegrammerstellung und Latenz, bedeutet jedoch, dass die tatsächliche Uhrzeit, zu der die Meldung vom Slave empfangen wird, nicht mehr der vom Master vorgegebenen Uhrzeit entspricht. Aus diesem Grund nutzt PTP Protokollmeldungen, die zwischen diversen PTP-Knoten versendet werden, um Uhren-Offsets und netzwerk-inhärente Verzögerungen zu ermitteln.

PTP kennt zwei Arten von Uhren: Masters und Slaves. Eine Uhr in einem Endgerät ist ein Slave. Ein Master, der idealerweise von einer externen Funkuhr oder einem GPS-Empfänger gesteuert wird, synchronisiert jeweils die an ihn angeschlossenen Slaves. In einem Netzwerk gibt es außerdem Übertragungskomponenten wie ein Ethernet Switch als Boundary Clock. Die Boundary Clock arbeitet als Slave für eine Master-Uhr und anschließend als Master-Uhr für die angeschlossenen Slave-Geräte.   Jeder Slave wird auf Zeit, Frequenz und Phase der Master-Uhr und demzufolge auf alle anderen Slave-Knoten synchronisiert.

PTP Clock Diagram

Der Synchronisationsvorgang wird in zwei Phasen gegliedert: Zuerst wird eine Offset-Korrektur und anschließend eine Delay-Messung durchgeführt.

Im Diagramm unten werden die Schritte zur Synchronisation der Slave-Uhr auf die Master-Uhr gezeigt. In diesem Beispiel beginnt die Slave-Uhr mit einem Offset (einer Differenz) von 20 Sekunden vom Master (d. h. Master steht auf 100 Sekunden und Slave auf 80 Sekunden). Hinweis: Die in diesem Beispiel verwendeten Zeitwerte dienen lediglich der Veranschaulichung der Erklärung und stellen keine tatsächliche Netzwerkleistung dar.

PTP Synchronization Process Diagram

Der Master erstellt eine Synchronisationsnachricht (Synch Message) bei 100 Sekunden, die an den Slave gesendet wird. Aufgrund interner Warteschlangen und Latenzen wird die Nachricht jedoch effektiv zur lokalen Master-Uhrzeit von 101 Sekunden versendet und zeitgestempelt. Aufgrund von Verzögerungen im Netzwerk erhält der Slave die Sync Message zwei Sekunden später, d. h. bei 83 Sekunden.

Der Master sendet kurz danach bei 103 Sekunden eine Follow-up-Nachricht. Diese Follow-up-Nachricht enthält den zuvor zeitgestempelten Wert von 101 Sekunden in der Nachricht. Diese Follow-up-Nachricht wird zwei Sekunden später erhalten, zur lokalen Slave-Uhrzeit von 85 Sekunden. Vom Zeitwert 101 Sekunden in der Nachricht subtrahiert der Slave anschließend den zuvor zeitgestempelten Wert von 83 Sekunden, was ein Offset von 18 Sekunden ergibt. Das Offset wird anschließend zur aktuellen Zeit addiert, was in einer neuen Uhrzeit von 103 Sekunden resultiert. Master und Slave sind jedoch noch nicht vollständig synchron. Bei dieser Korrektur wurde die Verzögerung im Netzwerk nicht in Betracht gezogen.

In der zweiten Phase wird die Netzwerkverzögerung (Delay) ermittelt. Der Slave sendet bei 108 Sekunden eine Delay Request Nachricht an den Master Der Master erhält und speichert diese Meldung bei 112 Sekunden lokaler Master-Zeit. Nur wird eine Delay Reply Nachricht mit der Zeit, zu der die Delay Request Message erhalten wurde (112 Sekunden), an den Slave zurückgesendet. Der Slave erhält die Delay Reply Nachricht bei 115 Sekunden lokaler Slave-Uhrzeit. Der Slave kann jetzt die Netzwerkverzögerung berechnen, indem er die Uhrzeit, zu der der die Delay Request Nachricht versendete (108 Sekunden), von der Uhrzeit, zu der der Master die Delay Request Nachricht erhielt (112 Sekunden) subtrahiert. Dies ergibt einen Zeitwert von 4 Sekunden. Da jedoch zwei Nachrichten versendet wurden, wird das Ergebnis durch 2 dividiert, was eine Verzögerung von 2 Sekunden ergibt. Der Slave korrigiert daraufhin seine Uhr um 2 Sekunden ( 117 Sekunden ) und ist jetzt völlig synchron mit dem Master.

Bei den internen Echtzeituhren der diversen Geräte kommt im Laufe der Zeit zwangsläufig ein Zeitversatz vor. Um dies zu korrigieren sendet die Master-Uhr die Abfragefolge in regelmäßigen Zeitabständen an die Slaves , um sie synchron mit der Master-Uhr zu erhalten.

Bei der Verwendung von Switches zwischen Master-Uhr und Slaves können Laufzeitabweichungen in den Switches zu Ungenauigkeiten bei den zwischen Master und Slaves versendeten Nachrichten führen. Da Switches die empfangenen Datenpakete komplett speichern, und durch Warteschlangeneffekte die Übertragung unter Umständen deutlich verzögert werden kann, sind hier bedeutende Schwankungen möglich. Bei geringer Netzwerklast wirkt sich dieser Effekt kaum aus, bei größerer Netzwerklast kann dies jedoch die Synchronisationsgenauigkeit deutlich verschlechtern.

Die Lösung ist der Einsatz von Ethernet Switches mit IEEE 1588 PTP Boundary Clock Kompetenzen. Diese enthalten eine eigene PTP-Instanz, wobei sie als PTP-Slave funktionieren und in Bezug auf die angeschlossene Master-Uhr synchronisiert werden. Gegenüber den nachgeschalteten PTP-Slaves arbeitet dann jeder Switch-Port wiederum als PTP-Master und synchronisiert diese Slaves mit seiner internen Uhrzeit. Damit werden alle Laufzeitschwankungen und Wartezeiten in den Switches kompensiert und lässt sich auch über größere Ethernet-Netzwerke hinweg maximale Genauigkeit erreichen.

IEEE 1588 V1 und V2 PTP Boundary Clock Kompetenzen sind erhältlich in Industriellen Managed Switches von Perle mit der PRO-Softwarefunktionsgruppe.

Hi!

Eine Frage haben? Chatten Sie mit einem Live-Produktspezialisten!

Produkt Frage?

Nehmen Sie hier Kontakt mit uns auf!


email-icon Email Schicken
contactus-icon Email Schicken callus-icon Anrufen
×

Email Schicken