War bisher höchste Präzision

Transkript

1 Automatisieren Verteilte Systeme Precision Time Protocol IEEE 1588 in der Praxis Zeitsynchronisation im Submikrosekundenbereich Immer mehr Daten können in immer kürzerer Zeit übertragen und verarbeitet werden. Dieser Trend ist natürlich auch in der Automatisierung zu beobachten. Hier spielt aber neben der Verarbeitungsgeschwindigkeit die Echtzeit-Fähigkeit eine besondere Bedeutung. Eine wesentliche Facette dabei ist die präzise Zeitsynchronisation unterschiedlicher Endgeräte. Mit dem Precision Time Protocol IEEE 1588 [1] besteht ein Standard, der es ermöglicht, die Uhrzeiten unterschiedlicher Endgeräte über ein Netzwerk deutlich besser als 1 µs zu synchronisieren. Der Artikel beschreibt, wie man dieses Protokoll einsetzt und implementiert, und welche Ergebnisse zu erwarten sind. Von Timo Gramann und Dirk S. Mohl War bisher höchste Präzision zwischen unterschiedlichen Geräten gefordert, dann wurde die Synchronisation über spezielle Verbindungen hergestellt. Entweder wurde dafür ein eigenes Kabel oder ein speziell dafür optimierter Feldbus eingesetzt. In Zeiten von nahezu unbegrenzter Bandbreite mit Internet und Ethernet hat der Anwender aber den Wunsch, alle Informationen über ein einziges Medium übertragen zu können. Dabei soll, neben der Datenübertragung, auch ein möglichst genauer Abgleich der Uhrzeiten durchgeführt werden. Hierfür sind bereits diverse Protokolle verfügbar, z.b. NTP (Network Time Protocol [2]) bzw. die vereinfachte Version SNTP (Simple NTP [3]) oder das SynUTC der TU Wien [4]. Allerdings haben diese den Nachteil, dass sie entweder sehr komplex oder nicht genau genug sind, dass sie eine sehr lange Zeit benötigen, bis eine entsprechende Präzision erreicht ist, oder dass sie bisher nicht die nötige Akzeptanz gefunden haben. Das Protokoll der Wahl Hier setzt nun das Precision Time Protocol nach IEEE 1588, kurz PTP genannt, an. Zum einen funktioniert es wie die zuvor genannten über ein Standard-Netzwerk. Als Basis dient das Internet Protocol (IP), und für die Übertragung wurde Ethernet ausgewählt, wobei aber der Standard auch andere Medien nicht ausschließt. Zum anderen ist das Protokoll von seiner Definition auf höchste Präzision ausgelegt, deutlich besser als eine Mikrosekunde. Erste Implementierungen bestätigen dies und lassen sogar eine zeitliche Synchronisierung im Bereich von deutlich unter 100 ns als möglich erscheinen. Um diese Genauigkeit zu erreichen, benötigt das Verfahren natürlich Hardware-Unterstützung. Dafür wurde das Protokoll so definiert, dass ein Entwickler sowohl die Hardware als auch den Software- Protokoll-Stapel sehr kompakt realisieren kann. Großes Interesse an präziser Zeitsynchronisation Derzeit interessieren sich zahlreiche Gruppen für dieses Protokoll. Da sind natürlich die Hersteller von GPS-Uhren und Zeitservern. Sie haben hier zum ersten Mal die Möglichkeit, die von Atomuhren und GPS-Uhren gelieferte Zeitgenauigkeit in einem Netz ohne größere Abweichungen (Jitter) zu verteilen. Die Messtechnik, eine weitere Gruppe, hat damit bei verteilten Systemen nun die Möglichkeit, Messergebnisse sehr exakt zu korrelieren. PTP versorgt jedes am Netzwerk angeschlossene Gerät mit einer exakten, absoluten Uhrzeit. Das haben auch die Energieverteiler erkannt, die an vielen Orten in ihrem Stromnetz Messdaten erfassen. Diese müssen ebenfalls sehr exakt zusammenpassen, um Belastungsauswertungen, Kostenerfassungen usw. zuverlässig durchführen zu können. So möchte man beim Standard IEC (Communication Networks and Systems in Substations) neben SNTP nun auch IEEE 1588 einbringen. Ganz starkes Interesse findet das Protokoll in der Automatisierungstechnik im Bereich Motion Control. Da die Antriebshersteller ihre Antriebe mittlerweile auch mit Netzwerkschnittstellen ausstatten, geht es nun darum, mehrere Antriebe über das Netz so synchron wie möglich zu steuern. So haben sich gleich mehrere Gruppen aus dieser Branche vorgenommen, dieses Protokoll in ihren auf Ethernet basierenden Feldbussen zu verwenden. So möchte die ODVA [5] bei ihrem neuen Protokoll Ethernet/IP-CIPSync auch PTP verwenden. Siemens arbeitet bei Profinet V3 [6] an einer Abwandlung von IEEE Auch Lösungen von Beckhoff [7] oder Jetter [8] wollen darüber die zeitliche Korrelation gewährleisten. Auch die Ethernet Powerlink Standardization Group (EPSG, [9]) hat dieses Protokoll als festen Bestandteil der Version 3 ihrer Spezifikation vorgesehen. 86 Elektronik 24/2003

2 Verteilte Systeme Automatisieren Die Funktion von IEEE 1588 Das Precision Time Protocol ist ein Zeitsynchronisations-Protokoll, welches ursprünglich John Eidson bei Agilent für verteilte Mess- und Steuerungsaufgaben entwickelt hat. Die Grundfunktion des PTP besteht darin OC 2 GPS-Empfänger (Zeitquelle) OC 1 (GM) OC 2, 3 Bild 1. Synchronisations-Bereiche beim IEEE-1588-Protokoll mit einer Kaskadiertiefe von 3. In der ersten Kaskade (grün) die vom GPS gesteuerte OC 1 die, in der zweiten Kaskade (orange) werden OC 2, OC 3 und OC 4 sowie BC 2, die in der nächsten Kaskade (rot) OC 5 usw.. OC: Ordinary Clock (Quelle oder Senke, 1 Port); BC: Boundary Clock (Switch oder Router, 1 bis n Ports; GM: Grandmaster (Synchronisations-Quelle). GM OC 3 OC 4 OC 1 Hub ausgehend von der genausten Uhr im Netz, die dann zum Grandmaster (GM) gewählt wird, alle anderen Teilnehmer zu synchronisieren. Die Ordinary Clock (OC) stellt dabei ein Endgerät dar, das entweder die Rolle einer Quelle (PTP-Master) oder einer Senke (PTP- Slave) einnimmt und nur einen einzigen PTP-Port besitzt. Dabei kann prinzipiell jede Uhr sowohl die Master- als auch die Slave-Funktion übernehmen. Die Präzision einer Uhr, genauer gesagt deren Zeitquelle, teilt das Protokoll in Klassen (Stratum) ein. Dabei ist die höchste Klasse eine Atomuhr, diese erhält den Stratum-Wert 1. Die Auswahl der besten Uhr im Netzwerk wird automatisch über den Best Master Clock -Algorithmus bestimmt. Die Präzision der Synchronisation hängt stark vom Netzwerk bzw. den darin verwendeten Komponenten ab, deshalb ermöglicht das Protokoll auch den Übergang über weniger deterministische Netzwerk-Komponenten wie z.b. Router und Switches. Eine solche Boundary Clock (BC) kompensiert den durch diese Geräte hervorgerufenen Übertragungs-Jitter (Variation der Durchlaufzeit). Eine BC besitzt im Gegensatz zu einer Ordinary Clock beliebig viele Ports, verhält sich aber an jedem dieser Ports wie eine OC für das entsprechende Segment. Je nach Konfiguration wird die lokale Uhr der Boundary Clock von einem Grandmaster falls nicht selbst der GM Steuereinheit (z.b. SPS) OC 5 BC 2 OC 4 BC 2 OC 5 BC 2 PTP Kaskadiertiefe über einen PTP- Port, der sich dann im Zustand Slave befindet. Die restlichen Ports der BC dienen als Master und synchronisieren wiederum weitere PTP-Elemente. Zur Verwaltung und Konfiguration der Uhren im Netzwerk definiert PTP ein eigenes Management-Protokoll, über das der Benutzer zum einen die Zustände aller beteiligten Uhren abfragen kann, zum anderen aber auch die Konfigurationen vornehmen kann. So kann er z.b. bestimmen, welche Uhr denn bevorzugt die Funktion des Grandmasters übernehmen soll. PTP basiert auf der IP Multicast - Kommunikation; es ist nicht auf das Ethernet beschränkt, sondern kann prinzipiell auf jedem multicastfähigen Bussystem eingesetzt werden. Die Multicast-Kommunikation bietet den Vorteil, dass sie einfach ist; es muss keine IP-Adressverwaltung auf den PTP-Knoten implementiert werden. Wegen der Verwendung von IP Multicast kann das PTP auch mit einer hohen Anzahl von PTP-Knoten arbeiten (Bild 1). Der Algorithmus der Zeitsynchronisation Der Kern des Protokolls besteht im Austausch der genauen Zeit. Dazu gliedert sich der Vorgang der Synchronisation in zwei Phasen (Bild 2): Zuerst korrigieren Master und Slave ihre zeitliche Differenz mit der Offsetwww.elektroniknet.de Für schnelle Anfragen: Elektronik-Leserservice auf Seite 122 Elektronik 24/

3 Automatisieren Verteilte Systeme t Master T M0 = 1050 s T M1 = 1051 s T M2 = 1053 s t = 1081 s T M3 = 1082 s T M4 = 1083 s Delay = 1 s Sync FollowUp(T M1 ) Offset-Messung Sync FollowUp(T M2 ) DelayRequest DelayResponse(T M3 ) Delay-Messung Sync FollowUp(T M4 ) Bild 2. Die Synchronisation verläuft in zwei Stufen. In der ersten Phase (gelb) wird der Korrekturwert zum Master (Offset Θ) ermittelt, die zweite Phase (grün) dient der Bestimmung der die Latenzzeit (T Delay ) zwischen Master und Slave. Unter der Voraussetzung, dass die Latenzzeiten für den Hin- und den Rückweg gleich sind, können der Offset vollständig bestimmt und die Uhren werden. Messung. Dabei sendet der Master zyklisch in definierten Intervallen (in der Grundeinstellung alle 2 s) eine eindeutige Synchronisations-Nachricht die Sync Message zu den entsprechenden Slaves. Diese Sync-Nachricht beinhaltet einen geschätzten Wert des exakten Sendezeitpunktes der Nachricht. Für eine hochgenaue Synchronisation werden Sendezeitpunkt des Masters T M1 und Empfangszeitpunkt des Slaves T S1 der Nachrichten jeweils mit der lokalen Uhr so präzise und so nah wie möglich an der physikalischen Schnittstelle zum Übertragungsmedium Slave T S0 = 39 s t = 40 s T S1 = 41 s da unbekannt Θ = T S1 - T M1 - T Delay Θ = 41 s s - 0 s = s korrigiere Uhr: t s := t s - Θ = t s s t = 1052 s T S2 = 1053 s Θ = T S2 - T M2 - T Delay = 0 T S3 = 1080 s T Delay = T S2 - T M2 + T M3 - T S3 2 T Delay = 0 s s s 2 = 1 s T S4 = 1083 s Θ = T S4 - T M4 - T Delay Θ = 1083 s s - 1 s = - 1 s korrigiere Uhr: t s := t s - Θ = t s + 1 s => Synchronisiert bestimmt. Der Standard sieht hier vor, den Zeitpunkt sogar direkt am Bitstrom auf dem Medium zu erfassen, und zwar am Ende des Start of Frame Delimiters des betreffenden Ethernet-Paketes. Den Sendezeitpunkt T M1 übermittelt der Master in einer zweiten Nachricht, der FollowUp Message, an den Slave. Mit dem Empfang der Follow- Up Message berechnet der Slave, unter Berücksichtigung des Empfangszeitstempels der Sync Message T S1, den Korrekturwert (Offset Θ) zum Master. Die Slave-Uhr t s muss anschließend um diesen Offset korrigiert werden. Diese präzisen Zeitstempel ermöglichen es nun, dass zeitliche Schwankungen des darüberliegenden Protokoll-Stapels der so genannte Protokoll-Jitter keine Bedeutung mehr haben. Hätte die Übertragungsstrecke keine Verzögerung, dann wären nun beide Uhren synchron. Die zweite Phase des Synchronisationsvorgangs bestimmt die Verzögerungszeit zwischen Slave und Master Latenzzeit oder Delay genannt. Für diese Delay-Messung sendet der Slave ein sog. Delay Request -Paket an den Master und ermittelt dabei die exakte Sendezeit der Nachricht T S3. Der Master generiert einen Zeitstempel bei Empfang des Pakets und sendet die Empfangszeit T M3 in einem Delay Response -Paket an den Slave zurück. Aus dem lokalen Sendezeitstempel T S3 und dem Empfangszeitstempel des Masters T M3 ermittelt der Slave die Verzögerungszeit T Delay zwischen Slave und Master und berücksichtigt sie ab der nächsten Offset-Messung. Die Delay -Messung erfolgt unregelmäßig und in größeren Zeitintervallen als eine Offset-Messung (zwischen 4 s und 60 s). Dadurch werden das Netz und insbesondere die Endgeräte nicht zu sehr belastet. Entscheidend für eine Delay -Messung und deren Genauigkeit ist jedoch eine symmetrische Verzögerung (T Delay_Hin = T Delay_Rück = T Delay ) zwischen Master und Slave. Automatische Masterwahl Das Precision Time Protocol bestimmt Master/Slave-Beziehungen zwischen 88 Elektronik 24/2003 Für schnelle Anfragen: Elektronik-Leserservice auf Seite 122

4 Verteilte Systeme Automatisieren Port Network Protocol Stack MAC (x)mii PHY IEEE 1588 Precision Time Protocol Timestamp Sync & Delay_Req sending and receipt time TSU Bild 3. Mit der Trennung des in Hardware implementierten zeitkritischen Teils von dem Softwareteil kann das Protokoll auf einem Prozessor mit geringen Leistungsanforderungen laufen. Die Hardware-Einheit besteht aus der Echtzeituhr und einer Zeitstempeleinheit (Time Stamp Unit TSU), die Software- Komponente implementiert das eigentliche IEEE Protokoll. kommunizierenden PTP-Synchronisations-Elementen. Die Bestimmung der Zustände (Master/Slave) obliegt dem Best Master Clock -Algorithmus (BMC), welcher die Eigenschaften (Genauigkeit, Stratum, Drift, Varianz,...) der kommunizierenden Uhren vergleicht und daraus die Zustände für alle lokalen Ports des PTP-Elements ableitet. Jedes PTP-Element führt lokal den BMC-Algorithmus aus und bestimmt somit den Zustand aller lokalen Ports. Die aktuellen Eigenschaften der Master-Uhr übermittelt diese in Synchronisations-Nachrichten zyklisch an die Slaves. Der Vorteil dieses Algorithmus besteht darin, dass die Knoten diese Zustände nicht aushandeln müssen, sondern in jedem Knoten individuell berechnen. Dadurch wird gewährleistet, dass sich das PTP-Netzwerk automatisch zu einer Baumstruktur konfiguriert, ausgehend von der besten zur Verfügung stehenden Uhr, dem Grandmaster. Eine Konfiguration mit mehreren oder keinem Master sowie instabile Zustände verhindert dieser Algorithmus. PTP-Referenzarchitektur Clock Software Set/Get time Hardware- Echtzeituhr Hardware Das Besondere an dieser Architektur ist die Trennung des zeitkritischen Teils, der in Hardware implementiert ist, von dem Softwareteil, der von harten Zeitbedingungen entkoppelt ist. Somit läuft des Protokoll in einem Prozess Tx Rx mit niedriger Priorität bzw. auf einem Prozessor mit geringen Leistungsanforderungen. Die Hardware-Einheit besteht aus einer hochpräzisen Echtzeituhr und einer Zeitstempeleinheit (TSU), die die Zeitstempel generiert. Die Software-Komponente implementiert das eigentliche IEEE-1588-Protokoll mit der Anbindung an Echtzeituhr und Zeitstempeleinheit. Bild 3 illustriert das Zusammenwirken der Hardund Software-Komponente eines IEEE-1588-Synchronisations-Elements. Das Augenmerk der vorliegenden Architektur liegt auf einer Modellierung der Software-Komponente, die vom Betriebssystem nahezu unabhängig ist. Dazu wurden drei unterschiedliche Schichten (Layer) eingeführt (Bild 4). Der Protocol Layer implementiert das vom Betriebssystem unabhängige Precision Time Protocol. Der OS Abstraction Layer bildet die Schnittstelle zwischen PTP und dem verwendeten Betriebssystem. Die vom Betriebssystem bereitgestellten Funktionen Tasks bzw. Prozesse, Semaphoren, Timer, Sockets etc. werden über den OS Layer eingebunden. Die oberste Schicht implementiert das PTP zur Synchronisation von Uhren in einem Netzwerk und kann auf unterschiedlichen Kommunikationselementen (PC, Switch, Router etc.) eingesetzt werden. Hier befindet sich die eigentliche Intelligenz zur Synchronisation der einzelnen Kommunikationselemente. Innerhalb der Protokoll-Schicht wurden ausschließlich ANSI/ISO-C-konforme Funktionen verwendet; damit ist sichergestellt, dass das Protokoll ohne tiefe Eingriffe in die Funktionsweise auf verschiedene Plattformen portiert werden kann. Ein Protokoll-Dispatcher gewährleistet die atomare Ausführung von Funktionen in einem einzelnen Prozess. Die Kommunikation zwischen dem Protokol Layer und dem OS Abstraction Layer erfolgt über eine Warteschlange (Queue) und drei definierte Schnittstellen. Die mittlere Schicht kapselt die Funktionen, die vom Betriebssystem abhängig sind und bei Bedarf angepasst werden. Für schnelle Anfragen: Elektronik-Leserservice auf Seite 122 Elektronik 24/

5 Automatisieren Verteilte Systeme Dispatcher aufrufen Protokoll- Eingaben PTP-Management Dispatcher Pop Queue Push PTP API Timer PTP Port Rx / Tx PTP-Nachrichten Synchronisation Bild 4. Mit drei Schichten (Layer) wird die Software-Komponente der Synchronisations- Elemente von dem verwendeten Betriebssystem (OS Operating System) unabhängig gemacht: Der Protocol Layer implementiert das IEEE 1588 Precision Time Protocol (PTP), der OS Abstraction Layer vermittelt den Zugriff des Betriebssystems (OS Layer) auf das PTP. Das Timestamp stellt dem Precision Time Protocol die erfassten Zeitstempel für Sync- und Delay- Request-Nachrichten zur Verfügung. Je nach Ausbaustufe bzw. Präzisionsanforderung werden die Zeitstempel entweder von einer Hardware-Einheit (TSU) oder von der Software generiert. Software-Zeitstempel werden am besten in dem vom Betriebssystem abhängigen NIC-Treiber (Rx-ISR, Sendeprozess) so nah wie möglich am Transportmedium generiert. Die lokale Uhr wird über das Clock gelesen und modifiziert. Diese Funktionen müssen an die verwendete Plattform angepasst werden. Steht keine Echtzeituhr zu Verfügung, werden die Systemuhr des Betriebssystems oder optimierte Lösungen wie z.b. der Nanokernel unter Unix-Derivaten verwendet. Neben der Ansteuerung der lokalen Uhr beinhaltet diese Schnittstelle die Regelalgorithmen, welche für PTP Timestamp Sync- und DelayRequest- Zeitstempel Best Master Clock Algorithm PTP Clock Zeit lesen und setzen Protocol Layer OS Abstraction Layer OS Layer die Güte (Genauigkeit, Stabilität, Einschwingverhalten etc.) der Zeitsynchronisation verantwortlich sind. Über das Port werden PTP-Nachrichten versendet bzw. empfangen. Die IEEE-1588-Telegramme benutzen ausschließlich UDP/IP Multicast -Pakete und ermöglichen es somit, dass man sie über die Socket- Schnittstelle des IP-Protokoll-Stapels senden und empfangen kann. Zeitliche Anforderungen können vernachlässigt werden, da die Zeitstempel direkt am Transportmedium generiert werden. Die Eingaben an das Protokoll (Konfiguration, Diagnose, PTP-Telegramme) werden über die PTP API abgewickelt. Geringer Portierungsaufwand Durch diese Vorgehensweise wurde erreicht, dass bei einer Portierung des Protokolls auf eine andere Plattform nur die untersten zwei Schichten angepasst werden müssen; dadurch bleibt das eigentliche Protokoll (etwa 90 bis 95 % der Quelltexte) unberührt. Der Software-Teil der beschriebenen PTP- Referenzarchitektur wurde in objektbasiertem C geschrieben. Dadurch ließen sich trotz der Verwendung von C die Vorteile der objektorientierten Analyse/Design/Programmierung einsetzen: Methodik, Kapseln, Wiederverwendbarkeit etc. Die Unified Modeling Language (UML) half beim Entwurf und der Visualisierung der Software. Um die leichte Portierbarkeit der Software zu prüfen, hat Hirschmann Electronics Referenz-Implementierungen von Ordinary Clocks und Boundary Clocks unter den Plattformen Linux, VxWorks und Windows durchgeführt. Die Untersuchung einer reinen Software-Implementierung sowohl auf Linux-Plattformen als auch auf Windowsund VxWorks-Plattformen ergab eine typische Synchronisations-Genauigkeit von ±10 µs bis ±200 µs. Die erzielte Genauigkeit ist dabei im Wesentlichen abhängig von der verwendeten Plattform, der Netzlast, der Systemauslastung bzw. internen Buslast sowie dem Ort, an dem der Zeitstempel generiert wird. Hardware für höchste Präzision Für Synchronisations-Genauigkeiten im Submikrosekunden-Bereich genügt eine Software-Implementierung nicht, deshalb müssen hier die erforderlichen Zeitstempel in einer so genannten Hardware-Zeitstempeleinheit direkt am 90 Elektronik 24/2003 Für schnelle Anfragen: Elektronik-Leserservice auf Seite 122

6 Verteilte Systeme Automatisieren Transportmedium generiert werden (Bild 5). Die Timestamp Unit (TSU) wurde ebenfalls in Hardware umgesetzt; sie setzt auf das Media Independent (MII) auf. Erkennt die TSU eine Sync- oder DelayRequest- Nachricht, so vermerkt sie den Zeitpunkt des Auftretens. Weiterhin extrahiert sie Informationen zur eindeutigen Identifizierung der Nachricht. Diese Informationen puffert die TSU in einem FIFO und ermöglicht auf diese Weise, den erfassten Zeitstempel der korrespondierenden PTP-Nachricht später zuzuordnen. Die absolute Zeit des Synchronisations-Elements verwaltet die Hardware- Echtzeituhr; sie dient als sehr präzises Metronom. Die Hardware-Uhr zählt hierbei Oszillator-Ticks, die der Takttreiber in s und ns umrechnet. Integraler Bestandteil der digitalen Echtzeituhr ist die Korrektureinheit für Offset (Phase) und Drift (Frequenz). Sie ermöglicht die Justage einer Echtzeituhr im Submikrosekundenbereich auf eine Referenzuhr. Die Separierung von Phasen- und Frequenz-Einheit ermöglicht den gezielten Eingriff der Regelung; dadurch wird eine schnelle Konvergenz des Systems erreicht. Das System kann somit Phasensprünge wie sie z.b. durch eine Veränderung der Topologie hervorgerufen werden unabhängig von der Driftkorrektureinheit ausregeln. Dies hat den Vorteil, dass die lokale Uhr die Frequenz nicht verändern muss und ein Phasensprung schnell kompensiert ist. Die Offset-Kompensation gleicht den absoluten Wert der lokalen Uhr zur Referenzuhr ab. Die Driftkorrektur bewirkt die Frequenzsynchronisation der lokalen Echtzeituhr mit der Referenzuhr. Damit erreicht man, dass die lokale Uhr mit der Frequenz des Masters tickt. Die Herausforderung besteht nun darin, die relative Drift δ der lokalen Uhr zur Referenzuhr zu bestimmen. Folgende Abhängigkeit kann vereinfacht für die Driftkorrektur angenommen werden: Empfehlungen zur Erhöhung der Präzision. Dabei sollte man folgende Aspekte beachten: Betriebssystem und Network Stack Jitter : Jitter innerhalb eines Synchronisations-Elements vermeiden Zeitstempel in Hardware. Latenz zwischen Master und Slave: Symmetrische Latenz (Hin- und Rückrichtung identisch) zwischen Master und Slave kompensiert die Delay-Messung. Eine Unsymmetrie bewirkt aber eine nicht zu kompensierende Zeitdifferenz zwischen Master und Slave. Jitter in Netzwerk-Koppelelementen (Repeater, Switches, Router): Jitter-Untersuchungen mit Netzwerk-Koppelelementen haben gezeigt, dass der Jitter von Hubs bzw. Repeatern zu vernachlässigen ist. Werden jedoch Switches im Hochlast- oder Überlastfall betrachtet, so besitzen diese einen nicht unerheblichen Verzögerungs-Jitter. Hier sind Werte bis zu 1 ms keine Seltenheit. Der Jitter in einem Switch ist abhängig von der Nachrichtenlänge und der Anzahl der Pakete, die schon gepuffert sind. Selbst wenn nur ein einziges langes Paket im Switch dem Synft () = ft () + δ+ ε Slave Master Quantisierung Hierbei stellt f(t) Slave die gegenwärtige Frequenz der entsprechenden Uhr und ε Quantisierung den Quantisierungsfehler dar. Die gesamte Hardware lässt sich in einem FPGA realisieren. Eine grobe Abschätzung ergibt, dass für die Realisierung eines Ports zwischen und Logic Array Gates benötigt werden. Hochpräzise Zeitsynchronisation Für die Genauigkeit der Synchronisation definiert das PTP die Mindestanforderungen einer lokalen Uhr und gibt FIFO Timestamp Unit (TSU) Tx Rx xmii- CPU- Offset Drift Hardware- Echtzeituhr Zeit Zugriff auf Netzwerk Bild 5. Um Synchronisations-Genauigkeiten im Submikrosekunden-Bereich zu erzielen, müssen erforderliche Zeitstempel in einer Hardware-Zeitstempeleinheit direkt am Transportmedium erzeugt werden. PTP-Hardware Konfiguration Zeitstempel Oszillator Für schnelle Anfragen: Elektronik-Leserservice auf Seite 122 Elektronik 24/

7 Verteilte Systeme Automatisieren chronisations-paket zuvorgekommen ist, kann dies einen Jitter bis zu 125 µs hervorrufen. Deshalb wird für ein hochpräzises Netz empfohlen, Switches mit der Boundary Clock -Funktion auszurüsten. So kann der Anwender sicherstellen, dass die Synchronisation immer nur über eine Punkt-zu-Punkt- Verbindung erfolgt, d.h. über eine physikalische Verbindung, deren Übertragungs-Jitter dann zu vernachlässigen ist. Auflösung und Stabilität Werden die gegebenen Empfehlungen befolgt, dann bestimmt die lokale Uhr des Synchronisations-Elements überwiegend die Synchronisations-Genauigkeit. Erster begrenzender Faktor ist die Auflösung der lokalen Uhr, die durch Grandmaster Fast Ethernet PPS-Signalausgang Slave PPS-Signalausgang Bild 6. Messaufbau und Blockdiagramm für den Test der Hardware-Implementierung des IEEE-1588-Protokolls. Zwei Ordinary Clocks (OC) sind direkt miteinander verbunden, mit einem Generator wurde zusätzlich eine hohe Netzlast erzeugt (PPS: Pulse per Second). die Quarzfrequenz des Oszillators bestimmt wird. Der entscheidende Aspekt ist jedoch der Stabilität des Oszillators zuzuschreiben und hier insbesondere der Kurzzeitstabilität. Die Güte der Synchronisations-Genauigkeit im eingeschwungenen Zustand (driftkompensiert) ist also abhängig von der relativen Drift zwischen Master und Slave zwischen zwei aufeinanderfolgenden Synchronisations-Telegrammen. Regelung das Unterscheidungsmerkmal PTP beschreibt das Verfahren, mit dem Master und Slave ihre zeitliche Differenz (Offset) bestimmen. Das Protokoll kann diese Größe aber nicht direkt setzen. Es müssen hier verschiedene Algorithmen herangezogen werden, um den Offset und die Drift zu bestimmen bzw. den Wert zu verifizieren. Je höher die Präzision der lokalen Uhr zur Referenzuhr, desto ausgefeilter müssen diese Algorithmen sein. Die Verifikation könnte auf einfache Weise dadurch erreicht werden, dass der neue Wert mit den vorhergehenden verglichen wird. Wenn dieser eine bestimmte Differenz überschreitet, ist er ungültig. Dabei muss aber berücksichtigt werden, dass sich tatsächlich etwas geändert haben könnte. Die neuen Werte müssten dann doch akzeptiert werden, wenn sie mehrfach hintereinander kommen. Bewertungskriterien Die Anwender können zur Bewertung einer Regelung folgende Kriterien heranziehen. Das Einschwingverhalten einer Regelung charakterisiert deren Güte. Die ausschlaggebende Größe hierfür ist die Einschwingzeit. Das ist die Zeitdauer, welche eine lokale Uhr benötigt, um sich auf die Referenzuhr in Frequenz und Phase zu synchronisieren. Störunempfindlichkeit und Stabilität einer eingeschwungenen Uhr: Ist die Uhr, so sollte die Regelung eine gewisse Trägheit besitzen, um nicht minimalen Ausreißern mit hohem Eingriff des Reglers entgegenzuwirken. Dennoch muss die Regelung auf dauerhafte Änderungen (z.b. eine Änderung der Topologie oder einen Wechsel des Masters) zügig reagieren, um die Synchronisation wieder herzustellen. Dies wird z.b. durch eine adaptive Regelung erreicht. Messergebnisse In einem Laboraufbau wurden für einen ersten Versuch zwei Ordinary Clocks direkt miteinander verbunden. Es handelte sich dabei um Aufsteckmodule zum modularen Ethernet Switch MICE (Bild 6). Für einen weitgehenden Test des Protokolls wurde mit einem Generator zusätzlich eine hohe Netzlast erzeugt. Damit die Differenz zwischen lokaler Uhr und Referenzuhr möglichst anwendungsnah überprüft werden konnte, wurden beide Einheiten mit einem Pulse Per Second -Signalausgang (PPS) versehen und auf ein Oszilloskop geführt. Damit Für schnelle Anfragen: Elektronik-Leserservice auf Seite 122 Elektronik 24/

8 Automatisieren Verteilte Systeme Bild 7. Die gemessene Häufigkeitsverteilung der Abwei chung der Offset Werte zwischen 7000 Master und Slave; 6000 Der Mittelwert beträgt 4,248 ns bei 5000 einer Standardabweichung von ,95 ns. Die Messung lief über einen Zeitraum von 84 h. 0 Häufigkeit Offset ließ sich die Abweichung der beiden Signale erfassen und auch deren Häufigkeitsverteilung darstellen. Die erreichte Synchronisations-Genauigkeit lag bei ±100 ns (max. Jitter). Die Messung lief dabei über einen Zeitraum von 84 Stunden. Bild 7 zeigt die Häufigkeitsverteilung der Offset-Werte zwischen Master und Slave in ns. Die Standardabweichung beträgt 23,95 ns, der Mittelwert 4,248 ns. Die Drift der Oszillatoren beschränkte bei den vorliegenden Prototypen die Synchronisations-Genauigkeit. Eine Quarzfrequenz von 50 MHz (±50 ppm) ergibt eine Auflösung von 20 ns. Daher kann das System die Drift nur im Bereich von ±20 ns/s einstellen. Bei Betrachtung der relativen Drift zwischen der lokalen Uhr und der Master-Uhr während zweier aufeinanderfolgender Syn- ns chronisations-te- legramme wird schnell deutlich, dass im eingeschwungenen Zustand die Synchronisations-Genauigkeit wesentlich von der Kurzzeitstabilität der Oszillatoren bestimmt wird. Potential für höchste Präzision Das in IEEE 1588 standardisierte Precision Time Protocol erreicht Synchronisations-Genauigkeiten im Submikrosekundenbereich und hat durchaus das Potential für eine noch höhere Präzision. Es eignet sich sehr gut für Anwendungen, bei denen in einer überschaubaren Netzwerkdomäne eine Zeitsynchronisation verteilter Uhren mit höchster Genauigkeit benötigt wird. Die in diesem Artikel vorgestellte PTP-Referenzarchitektur versucht, die Vorteile von Abstraktion, Modularität und Skalierbarkeit zu vereinen. jw MSc, Dipl.-Ing. (FH) Timo Gramann geboren in Waldshut, studierte Nachrichtentechnik an der Fachhochschule Esslingen Hochschule für Technik. Seit 2001 arbeitet er beim Steinbeistransferzentrum für Softwaretechnik, wo er im Auftrag von Hirschmann Electronics Themen im Bereich Zeitsynchronisation und Echtzeit-Kommunikation über Ethernet bearbeitet. Neben seiner beruflichen Tätigkeit absolvierte er den Studiengang Master of Science für verteilte Systeme der Brunel University of West London. tgramann@nt.hirschmann.de Dipl.-Ing. Dirk S. Mohl ist in Stuttgart geboren. Er studierte an der Universität Stuttgart Elektrotechnik und erhielt sein Diplom im Jahre Seit 1992 arbeitet er bei Hirschmann Electronics im Netzwerkbereich sowohl als Hardwareals auch Software-Entwicklungsingieur. Sein Spezialgebiet ist dabei Ethernet und Switching sowohl auf Ebene 2 als auch Ebene 3 (IP). Seit einem Jahr ist er verantwortlich für die Entwicklung der Industrial-Ethernet-Produkte im Geschäftsbereich Automation und Network Solutions. dmohl@nt.hirschmann.de Literatur [1] IEEE Std IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems. [2] RFC Network Time Protocol (Version 3) Specification, Implementation and Analysis. [3] RFC Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. [4] SynUTC [5] ODVA Open DeviceNet Vendor Association, [6] profinet.htm [7] [8] [9] EPSG, 94 Elektronik 24/2003 Für schnelle Anfragen: Elektronik-Leserservice auf Seite 122