+(t
Transcription
+(t
Zürcher Hochschule Winterthur IEEE 1588, Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Tutorial Prof. Hans Weibel, Zürcher Hochschule Winterthur [email protected] © 2003 ZHW Inhalt Systemzeit in verteilten Systemen Wesen und Bedeutung der Systemzeit Zeitbegriff in verteilten Systemen Anwendungen hochpräzis synchronisierter Uhren Verschiedene Synchronisationsprotokolle im Vergleich Ziele IEEE 1588 Prinzipieller Ablauf eines Uhrenabgleiches Hauptproblem: Auswirkungen von Delay und Jitter Einfluss des Netzwerkes und des Protokollstacks Was ist in IEEE 1588 enthalten? Topologie, Master Clock Selection Konzept Boundary Clock Performance Stand und Ausblick 23.09.03 / FOBS / ITG / Seite 2 Wesen und Bedeutung der Systemzeit Die Systemzeit kann verschiedenartig vorliegen implizit: System besitzt keine eigentliche Uhr, aber ein durch HW/SW-Abläufe gegebenes Zeitverhalten; typisch in kleinen geschlossenen Systemen explizit: Zeit ist repräsentiert durch eine Uhr; in komplexeren Systemen meistens eine Notwendigkeit Die Systemzeit hat Bedeutung zur Koordination von Messungen (Sampling, Triggering) bei der Messung von Zeiten (und der Berechnung daraus abgeleiteter Grössen) als Bezugsgrösse zur Feststellung der Reihenfolge (Zeitstempel zur Korrelation von Ereignissen und Daten) als Basis zur Ausführung koordinierter Aktionen (time based Behaviour) zeitlich gesteuerte Ausführung von Scripts zeitlich gesteuerte Mechanismen für gegenseitigen Ausschluss zur Entkopplung von Kommunikation und Ausführung 23.09.03 / FOBS / ITG / Seite 3 Zeitbegriff in verteilten Systemen In verteilten Systemen wird eine gemeinsamen Zeitbasis durch Kommunikationsvorgänge bereitgestellt. Dies kann auf unterschiedliche Arten geschehen Message-based: Aktionen werden ausgelöst durch den Empfang einer Meldung. Beispiele sind: Profibus, DeviceNet Cyclic: Das periodische Timing wird ermöglicht durch ein zyklisches Kommunikationsprotokoll. Beispiele sind: SERCOS, ETHERNET Powerlink im Protected Mode Time-based: Es existiert ein systemweiter Zeitbegriff, der durch synchronisierte Uhren in jedem Knoten implementiert ist. Das ist die flexibelste Variante. Methoden, diese Uhren abzugleichen, sind: Simple Network Time Protocol (SNTP) gemäss RFC 2030 IEEE 1588, Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Die systemweite Bereitstellung hochpräzis synchronisierter Uhren ermöglicht neue Lösungsansätze in Mess- und Automatisierungstechnik. 23.09.03 / FOBS / ITG / Seite 4 Anwendung hochpräzis synchronisierter Uhren Automatisierungstechnik Synchronisation von Antriebsachsen Synchronisation von zyklisch arbeitenden Subsystemen Messtechnik Korrelation dezentral erfasster Messwerte Time Stamping von Logging Daten Energieversorgung Steuerung von Schaltvorgängen Rekonstruktion von Netzvorgängen Problemeingrenzung (Unterscheidung von Ursache und Wirkung) Vermessung Triangulation Backup anderer Zeitquellen bei Verlust von GPS-Empfang 23.09.03 / FOBS / ITG / Seite 5 Synchronisationsprotokolle im Vergleich Abdeckung Kommunikation *) SNTP *) GPS IEEE 1588 Wide Area Wide Area einige Subnetze Internet Satelliten LAN < s < s *) Genauigkeit einige ms Administration konfiguriert n/a selbstorganisierend Spez. Hardware keine Receiver mit oder ohne Angaben entsprechen der typischen Implementation von SNTP. Bei entsprechender Anpassung des Verfahrens und HW-Unterstützung (Low Level Time Stamping) ist auch eine wesentlich höhere Genauigkeit erreichbar. SNTP Simple Network Time Protocol (RFC 2030) GPS Global Positioning System 23.09.03 / FOBS / ITG / Seite 6 Ziele IEEE 1588 Hochpräzise Synchronisation von Systemuhren (< Gs ) Anwendbar in jedem multicast-fähigen Netzwerk Einfache Installation; selbstkonfigurierend Unterstützung einer heterogenen Zusammensetzung von Uhren mit unterschiedlicher Genauigkeit, Auflösung und Stabilität Geringe Belastung von Netzwerk und Endgeräten 23.09.03 / FOBS / ITG / Seite 7 Prinzipieller Ablauf eines Uhrenabgleiches Master Clock Slave Clock PTP UDP IP MAC Die Zeit des Master Clocks wird an den Slave Clock übermittelt. Es entsteht ein Fehler in der Grösse des Transfer Delays. Netzwerk Precision Time Protocol (Application Layer) User Datagram Protocol (Transport Layer) Internet Protocol (Network Layer) Media Access Control Physical Layer 23.09.03 / FOBS / ITG / Seite 8 UDP IP MAC Phy Phy PTP UDP IP MAC Phy PTP Problematik von Delay und Jitter Master Clock tS1 Delay und Jitter Slave Clock PTP UDP IP MAC PTP Der Transfer Delay kann gemessen und eliminiert werden. Als Fehler bleibt die Fluktuation des Transfer Delays, der Jitter. UDP IP MAC Delay und Jitter tR2 tS2 Phy Phy Netzwerk tS3 23.09.03 / FOBS / ITG / Seite 9 tR3 Delay und Jitter tR1 Einfluss von Protokollstack und Betriebssystem Die in der PTP-Applikation erzeugten und empfangenen Meldungen werden durch unterschiedliche Faktoren unvorhersehbar verzögert: Kommunikationsvorgänge anderer Prozesse datenabhängige Ausführungszeit von Codesequenzen Scheduling Speicherverwaltung Caching Interrupt Latency Bus Arbitration Die einzelnen Anteile sind kumulativ und haben einen konstanten und einen variierenden Anteil, die sich als Delay und dessen Variation (Jitter) auswirken. Der konstante Anteil kann gemessen und somit kompensiert werden. 23.09.03 / FOBS / ITG / Seite 10 Einfluss des Netzwerkes Beispiel 100 Mbps Ethernet Kabel: für 100 m ca. 500 ns Delay (v H c für Cu und Glas) Hub: Jitter ca. 50 ns, unabhängig von der Framegrösse Switch: komplexe und von vielen Faktoren abhängige Charakteristik cut-through Switch hat mind. 1.12 µs Delay store-and-forward Switch hat einen min. Delay von 5.7 ... 122 µs, (proportional zur Länge des Frames) beide Typen haben bei hoher Netzlast infolge Queuing wesentlich grössere Delays im Bereich von ms Auch bei Switches, die Prioritäten unterstützen, muss ein Frame mit hoher Priorität bis zu 122 µs warten, bis der laufende Sendevorgang beendet ist je nach Architektur, Arbeitsweise und Bufferverwaltung kann es erheblichen zusätzlichen Delay und Jitter geben (z.B. Head-of-Line Blocking ) Router: Delay und Jitter tendenziell noch grösser als bei Switches Delay und Jitter: Selbe Anmerkungen wie auf der vorhergehenden Folie. 23.09.03 / FOBS / ITG / Seite 11 Einfluss eines Switches mit Priorisierung Der Switch unterhält eine separate Queue pro Prioritätsstufe. Zeitmeldungen könnten mit höchster Priorität gesendet werden. Weil diese Meldungen eine sehr geringe Last darstellen, treffen sie auf eine leere Queue. Ist bereits eine Übertragung im Gange, so verzögert sich die Aussendung des priorisierten Frames (im schlimmsten Fall um bis zu 122 Gs bei einem 100 Mbps Ethernet). Zudem können noch andere implementierungsbedingte Verzögerungen auftreten. Frame in Übertragung low Prio Queue high Prio Queue Switch 23.09.03 / FOBS / ITG / Seite 12 Ermittlung von Delay und Offset Master Clock 38 40 Slave Clock gkeit i t i e z h c i r e G le scheinba 46 48 Sync( testi ) m Follow _up(t 0) 50 _Req y a l e D 54 56 58 60 O 46 48 50 52 A D = Delay t1 = t0+D+O 54 52 t3 O = Offset = ClocksSlave – ClocksMaster 42 44 42 testim t0 44 40 56 B t2 58 60 Delay_ Resp(t 62 23.09.03 / FOBS / ITG / Seite 13 3) 62 64 t3 = t2-O+D Messwerte sind t1, t2, t3, t4 A = t1-t0 = D+O B = t3-t2 = D-O Delay D = A + B 2 A-B Offset O = 2 IEEE 1588 Inhalte Deskriptoren zur Charakterisierung von Systemuhren Zustände und Verhalten von Systemuhren Definition von Datentypen Repräsentation der Zeit Precision Time Protocol (PTP) zur Ermittlung einer schleifenfreien Topologie Auswahl der besten Systemuhr (Master Clock Selection) Synchronisation der Systemuhren detaillierte Spezifikation zur Anwendung mit Ethernet Conformance Requirements 23.09.03 / FOBS / ITG / Seite 14 IEEE 1588 Erzielung einer hohen Genauigkeit Zeitstempel so nahe wie möglich am Physical Layer, um Einfluss von Protokollstack und Betriebssystem zu eliminieren Implementierung mit HW-Unterstützung: Spezielle Time Stamp Unit am MII (Media Independent Interface, zwischen MAC und Phy). Exakter Zeitstempel bei Aussendung bzw. Empfang von relevanten PTPMeldungen. Implementierung ohne HW-Unterstützung: Zeitstempel-SW beim Eintritt in die Interrupt-Routine, die den MAC bedient Verwendung von Boundary Clocks in Switches (und Routers) Switch hat eine eigene Systemuhr, die mit dem Master abgeglichen wird und weitere Slaves synchronisiert spielt in die eine Richtung Slave, in die andere Richtung Master Verwendung statistischer Methoden zur weiteren Reduktion des Jitter Filterung, fliessende Mittelwertbildung, ... 23.09.03 / FOBS / ITG / Seite 15 IEEE 1588 Konzept des Boundary Clocks Master Clock Switch mit Boundary Clock Slave Slave Clock Master PTP PTP PTP PTP UDP UDP UDP UDP IP IP IP IP MAC MAC MAC MAC Phy Phy Phy MII Phy Time Stamp Unit 23.09.03 / FOBS / ITG / Seite 16 Switching Function IEEE 1588 Uhrenabgleich Master Clock PTP Applic. estimated send time Slave Clock Phy t0 Phy Sync(estimated send time) PTP Applic. t1 precise send time precise receive time Follow_up(precise send time) Berechnung Offset t3 Delay_Req t2 precise send time precise receive time Time Stamping 23.09.03 / FOBS / ITG / Seite 17 Delay_Resp(precise receive time) t t Berechnung Delay = (t1-t0)+(t3 -t2)/2 IEEE 1588 Topologie und „Best Master Clock“ M Ordinary Clock, Grandmaster: der als „best Master“ ausgewählte Clock (Wahl aufgrund Vergleich der Clock Deskriptoren) S M M M S S S S Boundary Clock, z.B. Switch S: Port im Slave State M: Port im Master State S M M M S 23.09.03 / FOBS / ITG / Seite 18 Ordinary Clock IEEE 1588 Sync Intervall und Netzlast Zu den Grössenordnungen 1 ppm Abweichung bedeutet 1 µs pro Sekunde (1 µs/s entspricht 1s/12 Tage) ein sehr guter Quarz hat eine Temperaturabhängigkeit von 1 ppm/0C Zur Erzielung einer hoher Genauigkeit sind häufige Abgleiche notwendig der Standard sieht Sync Intervalle von 1, 2, 8, 16 und 64 Sekunden vor Änderungsvorschläge erweitern nach unten auf V, ¼ und ½ Sekunden Sync und Follow_up Messages werden als Multicast versendet der Master bedient mit einer Meldung jeweils alle Slaves die Slaves können daraus bei bekanntem Delay den Offset berechnen Delay_Req und Delay_Resp Messages werden als Unicast versendet der Slave kann daraus den Delay zum Master berechnen (Voraussetzung ist eine Symmetrie der beiden Übrtragungsrichtungen) weil der Delay sich nicht schnell ändert, wird er seltener als der Offset ermittelt damit lässt sich die Netzbelastung gering halten 23.09.03 / FOBS / ITG / Seite 19 IEEE 1588 Performance Abweichung zwischen zwei synchronisierten Seconds tick deviations between the clocks of two system instruments Uhren 160 HP J2610A 140 =68ns mean = 37ns Relative frequency 120 Master HP J2610B 100 HP J2610B 80 HP J2610B 60 Slave 40 20 0 -215 -185 -155 -125 -95 -65 -35 -5 25 55 85 115 145 175 205 235 265 295 325 355 Deviation- nanoseconds Quelle: John C. Eidson, Agilent Laboratories 23.09.03 / FOBS / ITG / Seite 20 IEEE 1588 Repräsentation der Zeit 15 0 31 0 31 0 epoch_number seconds nanoseconds unsigned integer unsigned integer integer Die Zeitskala ist durch Grandmaster Clock definiert PTP Epoche startet am 1.1.1970 um 00:00 Uhr Die Variable seconds überläuft nach ca. 126 Jahren, also im Januar 2106 Überläufe von seconds werden in der Variablen epoch_number gezählt, die ihrerseits nach 8‘925‘512 Jahren überläuft Umrechnungen in andere Zeitsysteme PTP_Seconds = NTP_Seconds - 2‘208‘988‘800 + currentUTCOffset PTP_Seconds = GPS_Seconds + 315‘964‘819 23.09.03 / FOBS / ITG / Seite 21 IEEE 1588 PTP over UDP / IP / Ethernet UDP Port 319: Event Port für Sync und Delay_Req Meldungen Port 320: General Port für Follow_up, Delay_Resp und Mgmt Meldungen IP Time To Live = 0, d.h. von Router nicht weiterzuleiten Multicastadressen 224.0.1.129 für PTP-primary (default Domain) 224.0.1.130 für PTP-alternate1 (alternate Domain) 224.0.1.131 für PTP-alternate2 (alternate Domain) 224.0.1.132 für PTP-alternate3 (alternate Domain) Ethernet Ethernet Frame Preamble SFD Src Dst L/T 10101011 Time Stamp Point 23.09.03 / FOBS / ITG / Seite 22 Data CRC IEEE 1588 Stand und Ausblick Standard verabschiedet am 12.9.2002, publiziert im November 2002 Anwendung von IEEE 1588 angekündigt in verschiedenen Ansätzen für Real-time Ethernet ETHERNET Powerlink (u.a. ZHW, B&R, Lenze, Hirschmann, Kuka, ...) EtherCAT (Beckhoff) CIPSync (Rockwell, ODVA) ProfiNet (Siemens, PNO) Noch geringe Erfahrungen bezüglich Performance Verhalten bei mehrfach kaskadierten Boundary Clocks (Vorschlag: Bypass Clock anstelle Boundary Clock) Verhalten unter verschiedenen Umgebungs- und Lastverhältnissen Angebot der ZHW portierbaren PTP Stack für Ordinary Clock Beratung und Anwendungsunterstützung 23.09.03 / FOBS / ITG / Seite 23 Quellen IEEE 1588, Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems http://standards.ieee.org/catalog/ordering.html Preis: USD 90 34th Annual Precise Time and Time Interval (PTTI) Meeting Beitrag von John C. Eidson, Mike Fischer und Joe White IEC, Technical Commitee 65C, Result of Voting on new Work Item Proposal Digital data communications for measurement and control – Profiles for ISO/IEC 8802-3 based communication networks in real time applications MT9 / W1 23.09.03 / FOBS / ITG / Seite 24