+(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
hans.weibel@zhwin.ch
© 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