Precision Time Protocol bei Datenerfassung und Prüfung Precision Time Protocol bei Datenerfassung und Prüfung | HBM

Precision Time Protocol bei Datenerfassung und Prüfung

In den letzten Jahrzehnten sind viele verschiedene Zeitsteuerungsmechanismen entwickelt worden, um Geräte miteinander zu synchronisieren. Eines der ersten standardisierten, Ethernet-basierten Protokolle für die Zeitsynchronisation war das Networked Time Protocol (NTP). Es wurde 1982 festgelegt und erfuhr 1994 als NTP Version 4 eine umfassende Aktualisierung, mit der die Nutzung einer lokalen oder öffentlichen Master-Zeitquelle eingeführt wurde.

Eine weitere Möglichkeit für die Synchronisation dezentraler Systeme bieten die Timecodes des B-Typs der Inter-Range Instrumentation Group (IRIG) auf der Grundlage von Arbeiten, die auf das Jahr 1956 zurückgehen. In diesem Fall werden oft satellitengestützte Empfänger als Quelle für eine genaue Zeitsteuerung verwendet. Hierbei werden die Zeitsteuerungsinformationen direkt als analoge oder digitale Signale übertragen.

FireWire geht auf das Jahr 1985 zurück und wurde 2002 als IEEE1394b standardisiert. Das Protokoll bietet einen benutzerfreundlichen, automatischen Zeitsynchronisationsmechanismus. Dieser Standard ist bei Peripheriegeräten sowohl im Haushalts- und Unterhaltungssegment als auch für professionelle Anwendungen weit verbreitet. Beispielsweise verfügen alle QuantumX-Module von HBM über zwei FireWire-Schnittstellen.

Standards wie NTP, IRIG B und IEEE1494b waren zwar verfügbar, doch die nächste Aufgabe bestand darin, die existierende Ethernet-Infrastruktur beim Synchronisieren verteilter Systeme einzusetzen. Neben anderen Anforderungen sollte der neue Ansatz höhere Flexibilität und Benutzerfreundlichkeit bei niedrigeren Kosten bieten. Von der IT-Infrastruktur in der Industrie bis zu Privathaushalten im Endkundenmarkt ist Ethernet de facto der weltweite Standard für die Kommunikation zwischen Maschinen oder zwischen Mensch und Maschine. Selbst mobile Geräte wie Smartphones oder sogar Fahrzeuge können über mobile Telekommunikationsnetze wie LTE, EDGE oder GSM mit Ethernet-basierten Netzwerken verbunden werden. 


Wie genau ist zeitsynchron?

Wir schauen auf die Uhr, damit wir pünktlich zu einer Besprechung oder anderen Veranstaltungen kommen. Im Sport können Sekundenbruchteile darüber entscheiden, wer gewinnt oder verliert. Im Hochfrequenzhandel an der Börse kann ein Zeitunterschied von Millisekunden den Kauf- oder Verkaufspreis um Tausende Euro verändern. In Prüf- und Messanwendungen spielen hochgenaue, mit einem Zeitstempel versehene Signaleingänge, die denselben, zum gleichen Zeitpunkt erfassten physikalischen Prozess darstellen, eine wichtige Rolle bei der Qualifizierung und Analyse von Messdaten in Echtzeit oder bei der anschließenden Auswertung. In jedem dieser Beispiele und auch sonst hängt die Definition der „Genauigkeit“ von Uhren selbstverständlich von ihrer konkreten Anwendung ab. 

Worin besteht der Unterschied zwischen absoluter und relativer Zeit?

Eine absolute Zeit wird benötigt, wenn Messdaten einem bestimmten realen Ereignis zugeordnet werden müssen oder, wenn zwei oder mehr Datenerfassungssysteme (DAQ-Systeme) sich nicht im gleichen Netzwerk befinden. Ein Beispiel, wann die absolute Zeit wichtig sein könnte, ist der Fall, wenn der Belastungseinfluss eines Zuges, der über eine Brücke fährt, überwacht werden muss. Hier müsste der Zug genau identifiziert werden, um eine Datenbasis für mögliche weitere Maßnahmen wie eine Überbelastungswarnung zu haben. Die absolute Zeit ist eindeutig verfügbar, wenn sie von einer Uhr dargestellt wird.

Mögliche absolute Zeitquellen können sein:

  • Referenzuhren („Grandmaster Clocks“) für das Precision Time Protocol (PTP)
    • für Laboranwendungen von der Firma Meinberg, GPS-basiert
    • für mobile Anwendungen von der Firma OMICRON, GPS-basiert
  • GPS-Sensoren
    • nutzen direkt den Precise Positioning Service (PPS) vom GPS-Sensor
    • übernehmen die protokollbasierte absolute Zeit, wenn der Datenerfassungsauftrag gestartet wird
  • Network Time Protocol (NTP)-Master
    • öffentlich verfügbar über einen Internetzugang, beispielsweise bereitgestellt durch das NIST
    • lokaler Vertrieb durch die Firmen Hopf oder Meinberg, GPS-basiert
    • läuft auf einem PC und übernimmt die absolute Zeit vom Betriebssystem
  • Terrestrisch übertragenes niederfrequentes Funksignal
    • Ein Beispiel hierfür ist die von der Physikalisch-Technischen Bundesanstalt PTB in Braunschweig betriebene DCF-77 (Atomuhr)
  • Simple Network Time Protocol (SNTP)-Zeitserver

Die meisten Prüf- und Messanwendungen oder -prozesse können mit einer relativen Systemzeit arbeiten, insbesondre dann, wenn eine Prüfung reproduzierbar ist und es vor allem auf die relative Zeitsteuerung der Signale untereinander ankommt. Wenn eine absolute Zeit überhaupt benötigt wird, könnte sie Teil der META-Daten sein oder direkt im Dateinamen angegeben werden, zum Beispiel 2015-08-03_RLDA-test_Viper_No12.

Manchmal wird Zeitgenauigkeit mit Reaktionszeit, Latenzzeit oder Echtzeit durcheinandergebracht. Echtzeit-Fähigkeit kann durch Verwendung von Echtzeit-Bussen wie EtherCAT, ProfiNET, EtherNET/IP oder einer Vielzahl weiterer herstellerspezifischer Feldbusse erreicht werden.

Was muss bei der Durchführung von Echtzeit- und Hochgeschwindigkeits-Datenauswertungen mit einer DAQ-Lösung beachten werden?

Beim Prüfen und Messen haben wir es mit Anwendungen sehr unterschiedlicher Art zu tun. Bei einem Aspekt der Prüfungen und Messungen geht es in erster Linie um die zeitsynchrone Messung und Datenauswertung. Beispiele hierfür sind Bausubstanz- und Tragfähigkeitsprüfungen, Fahrzeugprüfungen, mobile Lastdatenermittlung („Road Load Data Acquisition“, RLDA) oder die Überwachung von Brücken. Ein anderer Teil des Prüfens und Messens beschäftigt sich mit dynamischen Laborprüfungen unter Einsatz von Aktoren mit den Schwerpunkten Simulation, Stimulation, Regelung oder In-the-Loop-Systeme. Hier spielt die Datenerfassung für die spätere Auswertung nicht die Hauptrolle. In der folgenden Auflistung sind einige wesentliche Überlegungen zusammengestellt:

  • Einige Anwendungen arbeiten für die Datenauswertung mit Datenraten bis 100 kS/s pro Kanal und mehr. Das Echtzeit-Verhalten ist hier nicht das Hauptkriterium und mit den herkömmlichen Echtzeit-Bussen auch nicht möglich. Dies würde die Komplexität erhöhen und den Freiheitsgrad verringern.
  • Hochgenaue Messgeräte arbeiten mit 24 Bit Sigma-Delta-AD-Wandlern und Filtern, die eine Phasenlaufzeit und Zeitverzögerung verursachen. Bei Echtzeit-Anwendungen geht es um einen Determinismus im Millisekundenbereich, d. h. sie benötigen kurze Reaktionszeiten. Moderne Datenerfassungslösungen wie QuantumX von HBM ermöglichen es, Sensoreingänge auf zwei für unterschiedliche Zwecke genutzte Signale aufzuteilen (1. Signal Echtzeit, 2. Signal gefilterte Hochgeschwindigkeitsdaten mit Zeitstempel).
  • „Auswertung“ und „Regelung“ haben jeweils einen unterschiedlichen Charakter, Arbeitsablauf und Zweck und fallen oft auch in unterschiedliche Zuständigkeiten. Wenn beide in einer einzigen Lösung kombiniert werden, kann das Konflikte verursachen, beispielsweise wenn ein Dynamometer-Prüfstand oder Versuche zur elektrischen Last durchgeführt und parallel dazu dynamische Hochgeschwindigkeitsdaten von dem zu prüfenden System – dem Antriebstrang – erfasst werden. Daher ist es durchaus sinnvoll, Zuständigkeiten und Arbeitsabläufe aufzuteilen, wenn sowohl Regelung als auch Auswertung benötigt werden.
  • Derzeit ist kein weltweit etablierter Standard für einen Hochleistungs-Echtzeitbus verfügbar. Alle Lösungen wie ProfiNET RT, EtherCAT und viele weitere werden von den weltweit tätigen Industrieunternehmen vorangetrieben, die ihre eigene Technologie in ihrem Markt und meistens für spezielle Anwendungen unterstützen. Die Task Group Time-Sensitive Networking (TSN) befasst sich mit einem nach IEEE standardisierten Echtzeit-Ethernetbus unter IEEE802.1AS, um hierfür einen weltweiten gültigen Standard anzubieten. Datenerfassungslösungen sind offen für die Einbindung in viele verschiedene Echtzeitbusse mithilfe von Gateways.
  • Für Echtzeit wird eine in Echtzeit ausgeführte Master-Anwendung benötigt. Eine Unterbrechung dieses Masters für Neukonfigurationen ist nicht möglich.

 

Was bedeutet Echtzeit und was ist zeitliche Latenz?

Echtzeit bezeichnet ein deterministisches Verhalten: Eine „Entscheidung“ oder „Antwort“ muss innerhalb eines bestimmten Zeitrahmens getroffen bzw. gegeben werden und wird hauptsächlich in Regelungs- oder Automatisierungsaufgaben verwendet (Sensor -> Regelungsalgorithmus -> Reaktion / Aktor).

Zeitliche Latenz ist ein Aspekt, der bei der Entwicklung von Regelungsalgorithmen berücksichtigt werden muss oder wenn eine Antwort innerhalb einer vorgegebenen maximalen Zeit benötigt wird. Echtzeit-Regelungsanwendungen erfordern normalerweise eine feste und sehr geringe zeitliche Latenz vom Sensor zum Regler. Bei nicht-deterministischen Protokollen wie Ethernet TCP/IP, CANbus oder beliebigen PC-basierten Aktivitäten kann die zeitliche Latenz variabel sein. Zeitliche Latenz spielt auch eine Rolle, wenn Daten für Überwachungszwecke mittels Streaming an einen Echtzeit-Regler übertragen werden, falls der mit dem Datenwert gesendete Zeitstempel nicht berücksichtigt wird oder nicht berücksichtigt werden kann.


Was ist das Precision Time Protocol nach IEEE1588:2008 oder PTPv2 und wie funktioniert es?

Das PTP ist ein internationaler Standard, der in IEEE1588 festgelegt ist und 2008 mit Version 2 überarbeitet wurde. Das Precision Time Protocol (PTPv2) ist ein Netzwerk-basiertes Zeitsynchronisations-Kommunikationsprotokoll, das zum Synchronisieren der Taktsignale von unterschiedlichen Gerätetypen verwendet werden kann und das eine Zeitgenauigkeit im Bereich unter einer Mikrosekunde liefert. PTPv2 basiert auf Ethernet. Im Gegensatz zu NTP ist PTPv2 in die physikalische Schicht eingebettet, und daher sprechen wir von einer echten Hardware-basierten Zeitstempelung für eine präzise Zeitsynchronisation aller Teilnehmer in einem Ethernet-Netzwerk. 

PTPv2 ist ein relativer Zeitsynchronisationsmechanismus. Ein Teilnehmer wird dafür ausgewählt, dass er als Master-Uhr fungiert, die Nachrichten für die Zeitsynchronisation an alle Slaves liefert. Der Synchronisationsprozess beginnt mit einem Zeitsynchronisationstelegramm an das Netzwerk. Alle Teilnehmer (Slaves) berechnen die Zeitdifferenz (Verzögerung) zwischen ihrer lokalen Zeit und der jeweiligen Master-Uhr und passen sich schrittweise bis zu einer Zeitdifferenz von weniger als 2 µs daran an. Beispielsweise sei angenommen, dass die PTP-Quelle eine PTP-Nachricht mit einer Zeitangabe von 1:00:00 pm sendet. Das Problem besteht nun darin, dass es einige Zeit dauert, bis diese Nachricht ihr Ziel erreicht. Wenn das PTP-Paket 1 Sekunde benötigt hat, um die Quelle zu erreichen, wäre es 1:00:01 pm, wenn die Quelle ein PTP-Paket mit der Angabe 1:00:00 pm empfängt. Die Latenz des Netzwerks muss deshalb kompensiert werden, was durch eine Reihe von Nachrichten erreicht wird, die zwischen der Master-Uhr und den Slave-Uhren ausgetauscht werden, wie in der Abbildung gezeigt.

  1. Die Master-Uhr sendet die Nachricht „Sync“. Der Zeitpunkt, an dem die Nachricht „Sync“ den Master verlässt, erhält den Zeitstempel t1, der in die Nachricht „Sync“ selbst eingebettet (Vorgang mit einem Schritt) oder in der Nachricht „Follow_Up“ gesendet werden kann (Vorgang mit zwei Schritten).
  2. Der Slave empfängt die Nachricht „Sync“; t2 ist der Zeitpunkt, an dem der Slave die Nachricht „Sync“ empfängt.
  3. Der Slave sendet die Nachricht „Delay_Req“, die den Zeitstempel t3 erhält, wenn sie den Slave verlässt, und den Zeitstempel t4, wenn der Master sie empfängt.
  4. Der Master antwortet mit einer Nachricht „Delay_Resp“, die den Zeitstempel t4 enthält.

Beispiel: Die Master-Zeit ist anfangs 100 Sekunden und die Slave-Zeit ist 80 Sekunden. Die Zeitanpassung im Slave würde dann wie folgt verlaufen. 

Alle PTP-Teilnehmer müssen PTP-fähig sein. Dies gilt auch für die Ethernet-Switches, nicht jedoch für die Datensenke (d. h. den PC, auf dem die DAQ-Software läuft). Die Uhr in einem DAQ-Modul wird als Ordinary Clock bezeichnet. Eine Uhr in einem Ethernet-Switch wird als Boundary Clock bezeichnet. Der Master wird automatisch ausgewählt, wenn keine Grandmaster Clock (Referenzuhr) absolute Zeitinformationen liefert. Dieser Mechanismus wird als „Best Master Clock“ (BMC)-Algorithmus bezeichnet.

Einige DAQ-Topologien haben eine Linien- oder Ringstruktur mit vielen Switches, sodass Boundary Clocks ihre eigenen Zeitsteuerungsschleifen verwenden. Als Alternative ermöglicht die sogenannte transparente Uhr – Transparent Clock (TC) – eine Ende-zu-Ende (E2E)-Synchronisationssteuerung und Follow-up-Nachrichten. Die Einführung von TCs ermöglicht eine wesentlich einfachere Lösung zum Korrigieren einer variablen Latenz des Switches. Der Grundgedanke der TC besteht darin, dass die Zeit gemessen wird, während der sich eine PTP-Ereignisnachricht im Switch befunden hat (die sogenannte Verweilzeit). Die Verweilzeit wird durch die Nachricht selbst oder durch eine anschließende Nachricht „Follow_up“ oder „Delay_Resp“ an den Empfänger gemeldet. Hierfür wurde ein neues Nachrichtenfeld, das sogenannte Korrekturfeld („Correction Field“), hinzugeführt. Es gibt die Art des Zeitintervalls an, das zum Ansammeln der Verweilzeiten entlang des Pfads der Nachricht verwendet werden kann, und kann außerdem auch noch für andere Korrekturen genutzt werden. Die Hauptvorteile sind:

  • Keine Konfiguration erforderlich: Transparent Clocks erfordern keine Berechnung und müssen in der Berechnung des BMC-Algorithmus nicht berücksichtigt werden. Daher müssen sie nicht unbedingt Verwaltungsnachrichten senden oder empfangen.
  • Schnelle Neukonfiguration des Netzwerks bei Störungen.
  • Schnellere Einrichtungszeiten: In der Initialisierungsphase und nach einer Änderung der Topologie brauchen Transparent Clocks nicht erneut mit einer Master-Uhr synchronisiert zu werden, bevor sie als Teil eines gültigen synchronisierten Pfades betrachtet werden können.
  • Ideal für kleine Konfigurationen.

Transparent Clocks, die mit Peer-to-Peer (P2P) arbeiten, sind gut auf die Anzahl der mit dem Subnetz verbundenen Geräte skalierbar und können sich rasch an Änderungen in der Netzwerktopologie anpassen. Dieser Mechanismus bietet daher eine hohe Skalierbarkeit und eignet sich am besten für stark kaskadierte Topologien (groß angelegte Systeme, die viele Switches in einer seriellen Verkettung (Daisy Chain) verwenden).

 

Was sind die Vorteile von PTPv2?

  • Es ermöglicht die Zeitsynchronisation zwischen verschiedenen Gerätetypen von verschiedenen Herstellern über ein standardisiertes Protokoll.
  • Es ermöglicht große Abstände zwischen DAQ-Modulen.
  • Es ermöglicht, unterschiedliche HBM-Produktlinien miteinander zu synchronisieren. QuantumX, SomatXR und Genesis High Speed bieten PTPv2 und ermöglichen eine Datenerfassung in einer Vielzahl von Situationen, u. a.:
    • Verteilt, mobil, im Freien in rauester Umgebung
    • Prüfungen im Labor oder im Feld mit Hunderten von Kanälen oder bis zu einigen Megasamples pro Sekunde und Kanal
  • Hohe Zeitgenauigkeit im Bereich unter einer Mikrosekunde zwischen allen Teilnehmern bei Arbeit mit hohen Datenraten
  • Verwendung von Ethernet als Standard
    • Elektrisch: bis zu 100 m Ethernet-Standardkabel
    • Optisch: große Abstände (einige Kilometer) zwischen Modulen und galvanische Trennung
    • Zusätzliche Synchronisationsleitungen werden nicht benötigt
  • Einfache Einrichtung ohne Administrator
    • automatische Master-Auswahl
    • robust gegenüber Master-Ausfällen (intelligente Slaves)
    • robust gegenüber Topologieänderungen
    • kontinuierliche Zeitskala (kein „Überspringen“ von Zeitstempeln, kein Rollover)
  • Sofern erforderlich, auch mit absoluter Zeit
    • Eine auf GPS basierende Grandmaster Clock kann integriert werden und dient als absolute Zeitquelle, wenn ein oder mehrere DAQ-Systeme nicht im selben Netzwerk arbeiten, ihre Daten jedoch rasch analysiert werden müssen.

Was sind einige typische Prüf- und Messanwendungen mit PTP-Zeitsynchronisation?

Die nachfolgende Liste nennt einige typische Anwendungen, die die Vorteile von PTP verdeutlichen:

  • Weiträumig verteilte Datenerfassungsmodule für:
    • Mobile Prüfungen großer Fahrzeuge im Landverkehr (Züge, Baumaschinen): Bremsen, Dynamik, Struktur und Weiteres
    • Laborprüfungen von Flugzeugen: Mechanik (Prüfstand „Iron Bird“), Struktur (Betriebsfestigkeit)
    • Überwachung großer Bauwerke: Brücken, Türme oder Windenergieanlagen unter Verwendung von GPS-basierter absoluter Zeit
  • Hybrid-Datenerfassungssysteme für:
    • Dynamometer-Prüfungen von Elektro- oder Hybridfahrzeugen, bei denen das mit hohen Datenraten arbeitende Datenerfassungssystem Genesis High Speed, das Strom und Spannung mit 2 MS/s pro Kanal erfasst, mit dem mit mittleren Datenraten arbeitenden QuantumX für die Erfassung der Daten von mechanischen und thermischen Sensoren kombiniert wird
    • Laborprüfungen von Flugzeugen: Elektrik (Prüfstand Electric Aircraft Testing)
    • Laborprüfungen von Maschinen oder Generatoren: Elektrik, Mechanik, thermische Eigenschaften
    • Mobile Fahrzeugprüfungen oder Überwachung mit Kameras, Messrädern oder anderen Zusatzeinrichtungen für analoge oder digitale Fahrzeugbusdaten
    • Generell für die Kombination unterschiedlicher DAQ-Systeme von unterschiedlichen Herstellern für Zwecke jeder Art

Gemischte Systemarchitektur, bei der klassische analoge Datenerfassungssysteme mit Kameras oder anderen Informationsquellen kombiniert werden.

 

 

Mit welchen Verfahren wird PTP in der DAQ-Software parametriert?

Da QuantumX verschiedene Mechanismen der Zeitsynchronisation unterstützt, ist bei der erstmaligen Einrichtung des Netzwerks eine entsprechende Parametrierung erforderlich. Der Zeitsteuerungsmechanismus der Standard- oder AUTO-Systemuhr ist FireWire. Zusätzlich können die folgenden Zeitquellen oder Zeitsteuerungsmechanismen ausgewählt werden:

  • PTPv2
  • NTP
  • IRIG-B
  • EtherCAT

Zum Parametrieren von PTPv2 kann die Software catmanEasy, MX-Assistent oder perceptionverwendet werden. Bitte klicken Sie auf einen Screenshot um die Screenshot-Gallerie zu starten.

Was sind Beispiele für empfohlene Ethernet-PTP-Switches und Referenzuhren (Grandmaster Clocks)?

Bei der Auswahl eines PTPv2-Switches sind die folgenden wesentlichen Merkmale zu beachten:

  • Unterstützung von IEEE1588:2008 (PTPv2)
  • Transparent Clock (TC)
  • Verzögerungsmechanismus: End-to-End (E2E) oder Peer-to-Peer (P2P)
  • Transportmechanismus: IPv4 oder IPv6

 Empfohlene Switches

  • HBM: Gigabit-Ethernet-Switch EX23-R mit folgenden Parametern:
    • System: robuste Ausführung für Einsatz im Freien mit 10 Schnittstellen, Stromversorgung 10‑30 V Gleichspannung, IP65/IP67, stoßfest
    • erzögerungsmechanismus: E2E
    • Transportmechanismus: IPv4, IPv6.
  • Siemens: Scalance XR324-12M
    • System: Rack-Ausführung mit bis zu 16 Schnittstellen (elektrisch oder optisch)
    • Verzögerungsmechanismus: E2E
    •  Transportmechanismus: IPv4/UDP
    • Modus: Transparent Clock
    • Hirschmann: RSP Ethernet-Switch
    • System: Ausführung mit Montage auf Hutschiene, insgesamt 11 Schnittstellen
    • Verzögerungsmechanismus: E2E
  • Oregano Systems: syn1588® Gbit Ethernet-Switch
    • System: Desktop-Ausführung mit 8 Schnittstellen
    • Verzögerungsmechanismus: In 1 Schritt mit E2E
    • Transportmechanismus: IPv4 (IPv6 wurde nicht getestet)
    • Modus: Transparent Clock (keine Parametrierung)
  • B&K: PTPv2-Switch in der LAN-XI-Serie
    • System: Desktop-Ausführung mit 8 elektrischen und 2 optischen Schnittstellen

 Weitere auf dem Markt verfügbare, aber noch nicht getestete Switches:

 

  •  CISCO: IE 3000 Switch
  • MOXA: PT-7728-PTP-Switch im Rack
  • MOXA: EDS-405A-PTP Series

Empfohlene Ethernet-Referenzuhren (Grandmaster Clocks)

Die Integration einer Referenzuhr in das Netzwerk ist nicht zwingend erforderlich, da PTP über einen „Best Clock“-Mechanismus verfügt; in einigen Anwendungen wird jedoch eine absolute Zeit benötigt.

  • Meinberg: LANTIME M600 - IEEE 1588-2008 Grandmaster Clock (GPS-basiert)
    • System: Lösung mit Rack-Montage, Stromversorgung 110 – 230 V Wechselspannung
    • Schnittstellen: insgesamt 6 (RJ45)
  • Omicron: OTMC 100 (integriertes GPS)
    • System: kleine Ausführung für Installation im Freien (IP67, Stromversorgung 24 V Gleichspannung, ‑40 °C … +70 °C / -40 °F ... +158 °F)
    • Schnittstellen: insgesamt 1, Unterstützung von Power over Ethernet (PoE) nach IEEE 802.3af mit < 2 W.
  • Auch der eigene PC kann als Referenzuhr verwendet werden.

In diesem Fall empfehlen wir die Verwendung eines Netzwerkadapters mit Intel i210-Chip.

Ist PTPv2 rückwärtskompatibel mit PTPv1?

PTP Version 1 war hauptsächlich auf Prüf- und Messanwendungen und Industrieautomation ausgerichtet. Es handelt sich um ein Multicast-Protokoll zum Einsatz in einem LAN, wobei die Leistung über die Fähigkeiten von NTP hinausgeht.

PTP Version 2 oder IEEE-1588-2008 ist eine Erweiterung von Version 1. Die Versionen sind nicht miteinander kompatibel. Der neuere PTPv2-Standard bietet u. a. folgende Funktionen:

  • Multicast-Nachrichten
  • Uhr mit Zwei-Schritt-Verfahren
  • Verzögerungsmechanismus Peer-to-Peer (P2P) oder End-to-End (E2E)
  • Synchronisationsintervall: 1, 2, 4, 8, 16, 32, 64 oder 128 Pakete/Sekunde
  • Intervall für Verzögerungsabfrage: 1, 2, 4, 8 oder 16 Sekunden
  • Unterstützte Transportprotokolle: IPv4 und das aktuelle IPv6

Welche Genauigkeit kann bei Verwendung von PTPv2 erzielt werden?

Die Zeitgenauigkeit hängt stark vom Netzwerktyp und den im Netzwerk vorhandenen Geräten ab. Wir empfehlen die Einrichtung eines privaten LANs, in dem alle Netzwerkteilnehmer PTPv2 vollständig unterstützen. Mit dieser Konfiguration kann eine Zeitgenauigkeit von bis zu 100 Nanosekunden von Gerät zu Gerät und seinen Kanälen erzielt werden. Hierbei ist aber immer noch zu berücksichtigen, dass unterschiedliche Datenraten und Filter zu Jitter und Phasenlaufzeiten in der Zeitsteuerung führen können.

Worin besteht der Unterschied zwischen Hardware- und Software-Zeitstempelung?

Der Hauptunterschied liegt in der unterschiedlichen Synchronisationsgenauigkeit, die erzielt werden kann. Mit softwarebasierter Zeitstempelung, die zum Beispiel im NTP verwendet wird, können bei der Slave-Synchronisation Genauigkeiten bis 100 Mikrosekunden in kleinen Netzwerken erreicht werden, üblicherweise liegen sie jedoch bei 1 ms. Mit einer Hardware-Zeitstempelung ist es möglich, eine Zeitsynchronisation mit einer Genauigkeit bis zu 100 Nanosekunden zu erreichen. Um eine so hohe Genauigkeit zu erhalten, muss allerdings die Netzwerktopologie, d. h. die Hardware der Switches und Slaves, Hardware-Zeitstempelung unterstützen. 

Kann auch ein Standard-Switch verwendet werden, und wenn ja, welche Auswirkungen hätte dies?

Die Verwendung von nicht PTP-fähigen Switches ist riskant. Die Übertragung von PTP-Nachrichten hängt dann vom Verkehr ab und ist daher kritisch im Hinblick auf die Gesamt-Zeitsteuerung. Falls der Switch QoS unterstützt, kann dieses Problem mit einer Regel gelöst werden, die die Priorität von PTP-Paketen erhöht. Grundsätzlich können wir die Verwendung von Switches ohne PTPv2-Unterstützung nicht empfehlen. Im schlimmsten Fall können PTP-Pakete verloren gehen, das heißt, die Zeitsteuerung und die benötigten Daten wären nicht mehr zuverlässig.