AT13701U1 - Verfahren zur Synchronisation von Zeitbasis und Ereignissen in einem verzweigten Verbundnetz, z.B. in Windpark-Netzen - Google Patents

Abstract

Verfahren zur Synchronisation mindestens des Zeitstempels (Zeitbasis) einerMaster-Steuerung (1) mit mindestens einer Slave-Steuerung (5-7) in einemverzweigten Datennetz, z.B. einem Ethernet-Netzwerk, wobei dieMastersteuerung (1) zyklisch über das Netzwerk (4) ein Sync-Paket (8-11) viaMulticast oder Broadcast an die Slave-Steuerung (5-7) sendet,dass jedes Sync-Paket (8-11) den Zeitstempel der Master-Uhr (1.1) zumZeitpunkt der Versendung enthält,dass jede Slave-Steuerung (5-7) die mittlere zeitliche Verzögerung zur Master-Uhrberechnet und mit diesem Wert den Zeitstempel der Master-Uhr (1.1)korrigiert und als eigenen Zeitstempel in der Slave-Uhr (5.1, 6.1, 7.1)verwendet.

Description

österreichisches Patentamt AT13 701 U1 2014-06-15

Beschreibung VERFAHREN ZUR SYNCHRONISATION VON ZEITBASIS UND EREIGNISSEN IN EINEM VERZWEIGTEN VERBUNDNETZ, Z.B. IN WINDPARK-NETZEN.

[0001] Die vorliegende Erfindung beschreibt ein Verfahren, um mindestens 2 Steuerungseinheiten (SPSen) über Ethernet oder ein vergleichbares Netz sowohl bezüglich der Zeitstempels (Zeitbasis) als verteilt angeordneter Taktgeber (Ereignisquellen) zu synchronisieren. Dabei bilden mindestens eine der Steuerungseinheiten die Hauptsteuerung (Master) mit einer Master Uhr als Zeitbasis und ein oder mehrere Nebeneinheiten die Untersteuerungen (Slaves) mit synchronisierten Slave Uhren. Alle Steuerungseinheiten sind lediglich über Ethernet oder ein vergleichbares Netz vernetzt. Die Anzahl der Steuerungseinheiten insgesamt ist nach oben hin nur durch die verfügbare Bandbreite über das Ethernet begrenzt.

1 PROBLEMSTELLUNG

[0002] In verteilten und über Ethernet oder vergleichbaren Netzen vernetzten Systemen mit mehreren Steuerungseinheiten im Verbund, wie es beispielsweise in einem Windpark oder auf einem seegängigen Schiff (Marine-Anwendung) üblich ist, ist es oft notwendig, dass alle Teilnehmer eine synchronisierte Zeitbasis haben. Dies betrifft sowohl den Zeitstempel (genaue Uhrzeit) wie auch den Taktgeber des Betriebssystems. Ohne Synchronisierung driften bei handelsüblichen Steuerungseinheiten sowohl Zeitstempel wie auch Taktgeber untereinander um mehrere Sekunden pro Tag auseinander und weichen auch in diesem Ausmaß zur Absolut Zeit (GMT, UTC) ab.

[0003] Die Anforderung an Genauigkeit und Jitter hängt stark von der Anwendung ab, ist aber üblicherweise im Bereich von wenigen Millisekunden für die Abweichung aller Steuerungseinheiten untereinander und etwa 10 bis 1000 ms für die erlaubte Abweichung zur Absolut Zeit (Atomuhr) über längere Zeiträume wie Jahre.

2 STAND DER TECHNIK

[0004] Die moderne Steuerungstechnik basiert vielfach auf der PC-Technologie. Die Zeitbasis für Datum und Uhrzeit in PCs ist ein Uhrenbaustein mit 32.768 kHz Quarz. Bei einer Quarz-Genauigkeit von 50ppm ergibt sich pro Tag ein maximaler Fehler von 4,32 Sekunden. In einem Jahr sind das dann im schlechtesten Falle etwa 26 Minuten. Die zweite Zeitbasis in PCs ist der Betriebssystem-Taktgeber mit einer konfigurierbaren Auflösung. Dieser Taktgeber basiert auf einer relativ ungenauen Zeitbasis (via Clock Synthesizer aus der Prozessor-Clock) mit einer Frequenz von 1.193.180 Hz. Ein ungünstiges Teilungsverhältnis im verwendeten Timer 0 (Intel 8253) verschlechtert die Genauigkeit mitunter noch mehr. Je höher die Tickrate, desto höher auch die Ungenauigkeit. Der Taktgeber kann im schlechtesten Fall bei einer Tickrate von 5000 bis zu 0,3 Prozent abweichen. Dies ergibt pro Tag einen maximalen Fehler von 260 Sekunden.

[0005] Die Zeitsynchronisation erfolgt seit einigen Jahren über die Protokolle SNTP (einfache Variante von NTP), über PTP oder über eigene Funk-/Satelliten Empfänger je Steuerungseinheit. Daneben gibt es noch viele proprietäre Lösungen, die teilweise auch über Anwendungen oder spezielle Hardware gemacht werden.

[0006] SNTP/NTP: Mit SNTP können beliebig viele Slaves auf eine Master-Uhr synchronisiert werden Die erreichbare Genauigkeit ist dabei >= 100 ms. Eine Synchronisation des Taktgebers erfolgt bei SNTP nicht. Bei SNTP kann bei belasteten und ausgedehnten Netzen ein Jitter im Bereich von Sekunden entstehen. In Kombination mit einem proprietären Low-Level Protokoll wie „bluecom“ sind IP-basierte Protokolle nicht erwünscht/erlaubt und SNTP ist ein solches Protokoll. Das NTP-Protokoll bietet eine höhere Genauigkeit wie SNTP, ist allerdings auch wesentlich aufwendiger (mehrere Master-Uhren, die sich untereinander abstimmen). NTP ist im Bereich von SPSen unüblich. 1 /25 österreichisches Patentamt AT13 701 U1 2014-06-15 [0007] PTP: Mit PTP, auch bekannt unter dem Standard IEEE1588 oder Precision Time Proto-col, können Teilnehmer sowohl im Bereich Zeitstempel wie auch Taktgeber mit einer Genauigkeit von wenigen Mikrosekunden realisiert werden. Dafür sind aber mindestens ein genauer Master-Zeitgeber, spezielle Netzwerk Switche mit PTP-Fähigkeit (Boundary Clock oder Transparent Clock) und auch spezielle Ethernet Controller mit „on-the-fly“ Zeitstempelung notwendig. Dieser Aufwand wird in den derzeitigen Windpark- und Marine-Anwendungen nicht getrieben. Dazu kommt noch, dass bei einer redundanten Vernetzung (2 unabhängige Netzwerke) PTP kaum ersetzbar ist. Solche PTP Datenpakete sind nicht priorisiert und werden daher, während eine Übertragung unter dem Protokollstandard „bluecom“ aktiv ist, nicht übertragen. Das kann bei großen Parks einen Zeitfehler im Bereich von 10 ms sein. PTP scheidet aus obigen Gründen vielfach aus. EMPFANG VON ZEITSIGNALEN IN JEDER STEUERUNGSEINHEIT: [0008] Die genaue Zeit kann in jeder Steuerungseinheit eigenständig über entsprechende Empfangseinrichtungen für DCF77 Funksignale oder GPS Satellitensignalen gelöst werden. Damit ist eine recht genaue Synchronisation von Uhrzeit und Datum möglich. Neben der Tatsache, dass diese Lösung mit erheblichen Kosten verbunden ist, ist eine Taktsynchronisation nicht möglich. SYNCHRONISATION ÜBER EIGENE SIGNALLEITUNGEN: [0009] Eine Zeitsynchronisation aller Steuerungseinheiten kann auch über eigens dafür verlegte Signalleitungen erfolgen. Eine solche Lösung ist nur in Anlagen mit begrenzter Ausdehnung möglich. In Windparks oder auf Schiffen sind die Steuerungseinheiten sehr weit verteilt, eine solche Lösung scheidet daher in diesen Anwendungsbereichen aus.

3 AUFGABENSTELLUNG

[0010] Der Erfindung liegt die Aufgabe zugrunde eine Synchronisation von Zeitbasis und Ereignissen auf mehreren SPSen über ein Standard-Kommunikationsmedium, wie Ethernet, in einem weitverzweigten Verbundnetz zu gewährleisten.

4 ERFINDUNG

[0011] Der einfacheren Beschreibung wird in der folgenden Beschreibung davon ausgegangen, dass die Datenübertragung im weit verzweigten Datennetz nach dem Ethernet-Standard erfolgt. Dies ist nur der einfacheren Beschreibung geschuldet und soll die Erfindung nicht beschränken. Es können demnach auch andere Datennetz-Protokolle, wie z.B. Profibus, CAN-Bus, IC2-Bus und dergleichen verwendet werden.

[0012] Erfindungsgemäß sendet die Mastersteuerung zyklisch über Ethernet ein Sync- Paket via Multicast oder Broadcast über ein proprietäres Protokoll (beim Anmelder ist das Teil seines Protokolls „bluecom“ oder auch „Windparkprotokoll“ genannt. Eine Beschreibung dieses Protokolls findet sich in der österreichischen Anmeldung A663/2010 vom 23.04.2010. Auf die dortige Beschreibung wird Bezug genommen, sie soll im gesamten Umfang vom Gegenstand der vorliegenden Erfindung umfasst sein.

[0013] Die Slaves empfangen dieses Sync-Paket mit einer geringen zeitlichen Verzögerung. Das Sync-Paket beinhaltet den Zeitstempel der Master-Uhr zum Zeitpunkt der Versendung. Jeder Slave kennt die eigene mittlere zeitliche Verzögerung (Versatz) zur Master-Uhr und kompensiert den Zeitstempel um diesen Wert und macht so eine Laufzeitkompensation.

[0014] Die Laufzeit des Sync-Paketes über die gesamte Netzwerk Infrastruktur ist abhängig von der Netzwerk Topologie, der aktuellen Auslastung des Netzwerkes und der Leistungsfähigkeit der Teilnehmer. Für jeden einzelnen Teilnehmer ist die Laufzeit daher zwar unterschiedlich, aber ausreichend deterministisch. Bei Verbindungsaufnahme mit einem neuen Slave erfolgt jeweils ein bidirektionaler Datenaustausch über priorisierte Ethernet Pakete. In diesem Verbin-2/25 österreichisches Patentamt AT13 701 U1 2014-06-15 dungsaufbau wird die Laufzeit über die gesamte Netzwerk Infrastruktur mitgemessen und dem Slave nach erfolgreichem Verbindungsaufbau als fixen Offset zur Laufzeitkompensation mitgeteilt.

[0015] Die Laufzeitmessung kann jederzeit im laufenden Betrieb oder zum Startzeitpunkt wiederholt werden. Im Slave kann dadurch über Mittelwertbildung von mehreren Laufzeitmessungen eine höhere Genauigkeit der Verzugszeit erreicht werden.

[0016] Die Startzeitpunkte der Applikationen (Cycle Start) auf allen Teilnehmern (Master und Slave) lassen sich über eine konfigurierbare Zeitversetzung mit einem reproduzierbaren Zeitbezug untereinander betreiben. Diese Logik gewährleistet, dass keine unnötigen Reservezeiten bei Übertragungsketten wegen Schwebung der Zyklen oder Phasenversetzung notwendig sind.

[0017] Dadurch lassen sich alle Applikationen aller Teilnehmer in einem definierten und reproduzierbaren Zeitbezug untereinander betreiben, alle SPSen und Applikationen darauf laufen somit im Gleichtakt.

4.1 AUSREGELN DES JITTERS VON SYNC-PAKETEN

[0018] Nachdem die Sync-Pakete auch mit Jitter behaftet sind, muss im Slave die Übernahme der Zeitstempelwerte über mehrere Zyklen geglättet werden. Die Sync-Pakete treffen in Zykluszeiten von typisch 1 bis 100 ms beim Slave ein (konfigurierbar). Der Sync-Paket Jitter hängt von der Netzwerk Geschwindigkeit, der aktuelle Auslastung und Topologie ab. Der Zeitstempelwert darf im eingeregelten Betrieb nicht springen, beim Hochstarten aber sehr wohl. Zur Glättung der Zeitstempelwerte muss ein geeigneter Regler verwendet werden. Aus dem Zeitstempelwert wird auch der Taktgeber abgeleitet. Damit ist die Voraussetzung für synchronen Betreib von Applikationen auf allen Steuerungseinheiten möglich.

[0019] Der Jitter im Sync-Paket beträgt je Netzwerk-Knoten im Transportkanal bei einem 1 GBit Netzwerk etwa 12,5 ps und bei einem 100 MBit Netzwerk 125 ps. Bei einer hohen Switch Verschachtelung in einem 100 MBit Netzwerk können so Sync-Paket Jitter im Bereich von bis zu 1 ms entstehen. Der Normalfall ist allerdings ein ungehinderter Pakettransport. Mit einem Jitter dieser Größenordnung muss das System ab und zu rechnen. Die Zeitstempel Glättung soll auf diese Tatsache Rücksicht nehmen.

[0020] Die Ungenauigkeiten der Laufzeitkompensation kann überwacht werden. Nachdem jeder Slave einen Zeitstempel hat (geregelter Wert, der über mehrere Zyklen angeglichen wird), kann dieser im Rückpaket die Abweichung (aktuelles Delta) zurückmelden. Aus dieser Rückmeldung kann der Master feststellen, wie gut der Slave eingeregelt ist und gegebenenfalls die Laufzeitmessung nochmals wiederholen. Ein Indikator für Synchronisationsqualität ist auch die Anzahl von Ausreißern, die nicht für die Regelung herangezogen werden und die Schwankungsbreite des Regler Eingangs.

4.2 NETZWERK TOPOLOGIE

[0021] Die Sync-Pakete und die Verbindungsaufnahme müssen mit der höchsten Ethernet Priorität betrieben werden. Es gibt Switche, die sind nicht im Stande priorisierte Paket zu verarbeiten. Die Qualität der Netzwerk-Infrastruktur muss sichergestellt sein und kann optional im Hochstartvorgang getestet werden.

[0022] Optional kann bei dynamischen Netzen (Topologie verändert sich) eine laufende Ermittlung der Laufzeitkompensation durchgeführt werden. Dies erfolgt entweder über eine im Betrieb zwischengeschobene Neuermittlung oder über eine simulierte Verbindungsaufnahme.

4.3 AUTONOMER BETRIEB

[0023] Für den Fall des Master-Ausfalls muss der Zeitstempelwert und der Taktgeber der Slave Steuerung autonom weitergeführt werden. Die Zeitquelle ist in diesem Falle die interne Zeitbasis. Bei Wiederaufnahme des synchronisierten Betriebes muss die Abweichung des Zeitstem-3/25 österreichisches Patentamt AT13 701 U1 2014-06-15 pels über einen längeren Zeitraum eingeschliffen werden. Zeitsprünge und rücklaufende Zeiten sind nicht erlaubt.

4.4 SYNCHRONISATION DER APPLIKATION UNTEREINANDER

[0024] Der Taktgeber in den Slave Steuerungen (ist üblicherweise ein Timer Interrupt) muss auf die geglätteten Zeitstempelwerte geregelt werden. Applikationen müssen über einen Offset und einen eindeutigen Phasenbezug zu diesem synchronisierten Taktgeber betreibbar sein. Der Phasenbezug wird aus dem Zyklus der jeweiligen Applikation errechnet. Der Phasenbezug ist durch den Nulldurchgang aus der Operation Zeitstempel MODULO Zykluszeit definiert. Wenn die Zykluszeit der Slave Applikation ein ganzzahliges Teilverhältnis oder Vielfaches von der Sync-Paket Zykluszeit beträgt, ist die Zyklus-Synchronität zwischen Slave-Applikation und Master Sync-Paket Zyklus sichergestellt.

4.5 REDUNDANZSYSTEME

[0025] In einem Redundanzsystem muss auch der Zeit-Master redundant vorhanden sein. Die beiden Master müssen sich untereinander ebenfalls synchronisieren, damit bei einem Failover oder Switchover kein Sprung entsteht. Diese Master- Master Synchronisation kann genauso wie die Master - Slave Synchronisation ablaufen. Der Primary-Master ist solange die Master-Uhr wie dieser Primary- Master ist. Im Slave wird nur ein Zeitstempel gehalten. Die Logik für Übernahme einer der beiden Zeitstempel ist gesondert zu definieren und ist nicht Teil dieses Patentes. Es muss vermieden werden, dass die Zeitstempel Quelle ständig zwischen den beiden Master-Uhren wechselt. Es muss auch vermieden werden, dass bei Ausfall der aktiven Quelle ein Synchronisationsloch entsteht (Bumpless Failover).

[0026] Der Erfindungsgegenstand der vorliegenden Erfindung ergibt sich nicht nur aus dem Gegenstand der einzelnen Patentansprüche, sondern auch aus der Kombination der einzelnen Patentansprüche untereinander.

[0027] Alle in den Unterlagen, einschließlich der Zusammenfassung offenbarten Angaben und Merkmale, insbesondere die in den Zeichnungen dargestellte räumliche Ausbildung, werden als erfindungswesentlich beansprucht, soweit sie einzeln oder in Kombination gegenüber dem Stand der Technik neu sind.

[0028] Im Folgenden wird die Erfindung anhand von mehreren Ausführungswege darstellenden Zeichnungen näher erläutert. Hierbei gehen aus den Zeichnungen und ihrer Beschreibung weitere erfindungswesentliche Merkmale und Vorteile der Erfindung hervor.

[0029] [0030] [0031] [0032] [0033] [0034] [0035] [0036] [0037]

Es zeigen:

Figur 1: Schematisiert: Die Darstellung im Blockschaltbild der Netzwerktopologie mit Darstellung aller Teilnehmer

Figur 2: Ein gegenüber Figur 1 verfeinertes Blockschaltbild mit Darstellung weiterer Einzelheiten

Figur 3: Eine erste Darstellung einer veränderten Netzwerktopologie

Figur 4: Eine zweite Darstellung einer veränderten Netzwerktopologie

Figur 5: Eine weitere Ausführung der Erfindung, wobei redundante Netzwerkverbindungen zwischen einer primären CPU und einer sekundär CPU angeordnet sind.

Figur 6: Ablauf eines Synchronisationszyklus zwischen einem Master und mehreren Slaves

Figur 7: Der zeitliche Ablauf der Laufzeitermittlung mehrerer Slaves

Figur 8: Die Synchronisation einzelner Applikationen in einem der Slaves untereinander 4/25 österreichisches Patentamt AT13 701 U1 2014-06-15 [0038] Figur 9: Schematische Darstellung des Regelalgorithmus für die Einregelung der

Zeitverzögerung im jeweiligen Slave [0039] Figur 10: Schematische Darstellung des Aufbaus einer Taktregelung im Slave [0040] Figur 11: Die Darstellung des möglichen Jitter-Bereiches im Slave [0041] Die in Figur 1 dargestellte Master-Steuerung ist über ein Standard Ethernet mit beliebig vielen Slave-Steuerungen verbunden. Die Slave Uhren werden erfindungsgemäß über Ethernet mit einer für Windparks und Marine ausreichenden Genauigkeit periodisch synchronisiert. Die Master Uhr ihrerseits synchronisiert sich auf einen genauen Zeitgeber über geeignete Techniken wie GPS, DCF77, PTP, NTP oder hat ein Präzisionszeitquelle eingebaut.

[0042] Gemäß Figur 1 und 2 steht im Mittelpunkt der vorliegenden Erfindung, dass die bei der Mastersteuerung (1) angesiedelte Masteruhr (1.1) mit der Masterzeit (t1) diese genaue Zeit an die einzelnen Slave-Steuerungen (5, 6, 7) weitergibt, dass die Slave-Steuerungen (5, 6, 7) ebenfalls die gleiche Zeit (t1) der Mastersteuerung 1 besitzen.

[0043] Die Mastersteuerung (1) kann zum Beispiel ihre Zeit über einen Empfänger (3) funkgestützt oder netzgestützt empfangen und definiert dadurch eine Masteruhr (1.1) mit der Masterzeit (t1).

[0044] Die Mastersteuerung (1) ist über ein Netzwerk, bevorzugt ein Ethernet-Netzwerk mit einer Anzahl von Slave-Steuerungen (5, 6, 7) verbunden, wobei es - wie oben ausgeführt -darauf ankommt, dass die Slave-Steuerungen (5, 6, 7) mit der gleichen Zeit (t1) arbeiten.

[0045] Die in den Slave-Uhren (5.1, 6.1 und 7.1) verwendete Zeit muss synchron zu der Masterzeit (t1) sein.

[0046] Aufgrund der unterschiedlichen Laufzeiten der Datenpakete im Netzwerk (4) kann die Synchronisation jedoch nicht einfach so geschehen, dass jede Slave-Steuerung einen bestimmten zeitlichen Nachlauf berücksichtigt. Dieser zeitliche Nachlauf muss für jede einzelne Slave-Steuerung (5, 6, 7) getrennt bestimmt werden.

[0047] Die Figur 2 zeigt als Blockschaltbild einen solchen Kompensationsmechanismus nach der Erfindung.

[0048] Maßgebend ist, dass ausgehend von der Mastersteuerung (1) in der Masteruhr (1.1 )die Masterzeit (t1) erzeugt wird und diese Masterzeit (t1) in Form eines Sync-Paketes (8), das heißt also in Form eines Datenpaketes, über das Netzwerk (4) an alle Slaves verteilt wird.

[0049] Die Verteilung über das Netzwerk (4) kann entweder drahtgebunden oder auch funkgestützt erfolgen.

[0050] Die Erfindung ist deshalb nicht auf ein Ethernet-Netzwerk beschränkt, obwohl dies bevorzugt wird. Ebenso können funkgestützte Netzwerke verwendet werden.

[0051] Der einfacheren Beschreibung wegen wird in der folgenden Beschreibung jedoch davon ausgegangen, dass es sich um ein drahtgebundenes Ethernet-Netzwerk handelt.

[0052] Wenn nun das von der Mastersteuerung (1) erzeugte Sync-Paket (8) mit der Masterzeit (t1) über das Netzwerk (4) an die einzelnen Slave-Steuerungen verteilt wird, kommt dieses Sync-Paket (8) aufgrund der im Netzwerk (4) gegebenen Verzögerungszeiten zu unterschiedlichen Zeitpunkten in Form eines (durch den Zeitablauf veränderten) Sync-Paketes (9) bei der Slave-Steuerung (5), in Form eines Sync-Paketes (10) bei der Slave-Steuerung (6) und in Form eines Sync-Paketes (11) bei der Slave-Steuerung (7) an.

[0053] Kennzeichnend hierfür ist, dass die Ankunft der in den einzelnen Slave-Steuerungen (5 -7) eintreffenden Sync-Pakete (9 - 11) zu verschiedenen Zeitpunkten erfolgt, wobei in jeder Slave-Steuerung eine für diesen Slave charakteristische mittlere Verzögerungszeit (12, 13, 14) entsteht.

[0054] Kern der vorliegenden Erfindung ist die Erfassung der mittleren Verzögerungszeit in 5/25 österreichisches Patentamt AT13 701 U1 2014-06-15 jeder Slave-Steuerung (5, 6, 7) und die Kompensation dieser mittleren Verzögerungszeit (Tv1, Tv2 und Tv3) durch einen Kompensator (15, 16, 17), der genau diese spezielle mittlere Verzögerungszeit (12-14) beseitigt und hieraus durch eine Rückwärtskalkulation die originale Masterzeit (t1) für den jeweiligen Slave erzeugt, wie dies in Figur 2 auf der rechten Seite dargestellt ist.

[0055] Auf diese Weise sorgt die Erfindung dafür, dass jede Slave-Steuerung mit der Original-Masterzeit (t1) der Masteruhr (1.1) arbeitet und nicht mit davon abweichenden Zeiten.

[0056] Die Master-Steuerung nach Figur 3 ist über mehrere, teilweise verschachtelte (Kaska-dierung) Ethernet Switches beliebig mit beliebig vielen Slave-Steuerungen baumartig verbunden. Diese Topologie ist in Steuerungsanwendungen sehr verbreitet, hat aber zur Folge, dass die Paketlaufzeiten je Switch-Kaskade um eine bestimmet Zeit verzögert wird. Das Problem sind die unterschiedlichen Verzögerungszeiten je Slave.

[0057] Die Figur 3 zeigt den Grund für die Entstehung der unterschiedlichen mittleren Verzögerungszeiten (12 - 14). Dort ist eingezeichnet, dass im Netzwerk (4) eine Anzahl von Switches (18, 19, 20) an verteilten Stellen angeordnet sind.

[0058] Die Switches (18 - 20) verbinden verschiedene Netzwerke untereinander, wobei zu berücksichtigen ist, dass es sich bei der vorliegenden Erfindung um ein über mehrere Kilometer verteiltes Netzwerk handelt, bei dem aufgrund der großen Entfernungen von bis zu 50 Kilometer zwischen den einzelnen Bestandteilen (1,5, 6, 7) beträchtliche Zeitverzögerungen beim Datentransport über das Netzwerk in Kauf genommen werden müssen.

[0059] Die in den Netzwerken vorhandenen Switches (18,19, 20) führen zu weiteren Verzögerungen beim Datentransport, sodass es praktisch nicht möglich ist, von vornherein zu bestimmen (oder eine theoretische Berechnung durchzuführen), mit welcher Verzögerungszeit ein von der Mastersteuerung (1) ausgesendetes Sync-Paket (8) bei den verschiedenen Slave-Steuerungen in Form eines der unterschiedlichen Laufzeit entsprechenden, veränderten Sync-Paketes (9, 10, 11) ankommt.

[0060] In Figur 4 ist eine weitere Netzwerkkonfiguration dargestellt. Die Figur 4 zeigt eine weitere Netzwerktopologie nach der Erfindung, nämlich eine sogenannte Ringtopologie. Dies bedeutet, dass ausgehend vom Switch (18) im Fall eines Fehlers entweder nach rechts in Richtung A oder nach links in Richtung B umgeschaltet wird und dass deshalb immer nur die eine Hälfte des Rings der Netzwerktopologie angesteuert wird.

[0061] Ansonsten gelten für die gleichen Teile die gleichen Erläuterungen, sodass auch aus dieser Darstellung ersichtlich ist, dass es wegen des Vorhandenseins unterschiedlicher Switches (18 - 20) zu einer nicht vorhersehbaren Verzögerung beim Eintreffen eines von der Mastersteuerung erzeugten Sync- Paketes in der jeweiligen Slave-Steuerung kommt.

[0062] Im Übrigen kann sich die Verzögerung auch dynamisch ändern und zwar in Abhängigkeit von einem Unterbruch, wenn es zum Beispiel zwischen den Switch (19) und (20) zu einer Unterbrechung kommt. Es wird dann, wenn vorher auf die Richtung B geschaltet war, auf die Richtung A umgeschaltet, was zu völlig anderen Laufzeiten führt.

[0063] Dementsprechend ist Gegenstand der vorliegenden Erfindung auch die dynamische Bestimmung der Verzögerungszeit, mit der jeder Slave in Abhängigkeit von der Netzwerktopologie mit dem Empfang der Masterzeit zu rechnen hat.

[0064] Die in Figur 4 dargestellte Master-Steuerung ist über mehrere Ethernet Switches mir ringförmiger Vernetzung mit beliebig vielen Slave-Steuerungen verbunden. Diese Topologie ist in Windparks sehr verbreitet. Die Ringtopologie hat zur Folge, dass die Datenpakete zwischen Master- und Slave-Steuerung wahlweise in Richtung A oder Richtung B transportiert werden. Bei einem Unterbruch an einer beliebigen Stelle sucht sich das Netzwerk automatisch die andere Richtung. Die Paketlaufzeiten ändern sich somit dynamisch im Betrieb.

[0065] Die Figur 5 zeigt als weiteres Beispiel für eine Netzwerktopologie, bei der die Maßnahmen der Erfindung angewendet werden, ein sogenanntes redundantes Netzwerk. Hier geht es 6/25 österreichisches Patentamt AT13 701 U1 2014-06-15 darum, dass eine erste Mastersteuerung (1) von einem beliebigen Factory-Netzwerk (22) angesteuert wird, wobei das Vorhandensein des Factory-Netzwerkes nicht zwingend ist. Dieses Factory-Netzwerk kann nach einem bestimmten Protokoll betrieben werden, zum Beispiel nach dem Protokollstandard SMI oder dem Protokollstandard FTP oder dem Protokollstandard HTTP.

[0066] Wichtig hierbei ist, dass zunächst bei der vollen Funktion des redundanten Netzwerkes davon ausgegangen wird, dass die Mastersteuerung (1) mit der Masteruhr (1.1) die relevante Zeit (t1) erzeugt und über das Netzwerk (4) in der vorher beschriebenen Weise die Sync-Pakete an die einzelnen Slave-Steuerungen (5, 6, 7) verschickt.

[0067] Sobald aber die Mastersteuerung (1) ausfällt, wird dies von einer in der Mastersteuerung angeordneten Redundanzsteuerung bemerkt, und es wird über eine Redundanzverbindung (21) auf eine weitere Mastersteuerung (2) umgeschaltet, die genau identisch wie die Mastersteuerung (1) ausgebildet ist und alle Funktionen gleich wie die primäre Mastersteuerung (1) hat.

[0068] Das heißt, die Mastersteuerung (1) ist ein Klon zu der Mastersteuerung (2) und erzeugt demzufolge ebenfalls die Masteruhr (1.1) mit der Master-Zeit (t1). Hieraus ergibt sich, dass auch bei redundanten Netzwerken die Zeitverzögerungen unregelmäßig und dynamisch bei der Synchronisation der einzelnen Slave-Steuerungen (5, 6, 7) entstehen und nach den Merkmalen der Erfindungen berücksichtigt werden müssen.

[0069] Die 3 I/O Devices nach Figur 5 sind jeweils über die beiden IO-Netzwerke A und B mit 2 Master-Steuerungen verbunden. Eine der beiden Master-Steuerungen ist die Primary CPU, die andere die Secondary-CPU. Die IO- Devices und auch die Secondary-CPU beziehen die Zeitreferenz von der Primary-CPU. Sobald ein Switchover der Master CPU erfolgt, wechselt die Master-Uhr zur anderen Master-CPU. Die IO-Devices beziehen dann die Zeitreferenz von dieser CPU ohne Zeitsprung.

[0070] Die Figur 6 zeigt die Entstehung der Verzögerungszeit, wobei jeweils auf der Zeitachse in der obersten Darstellung der Mastertakt (23) angegeben ist und hierbei als Unterteilung des Mastertaktes ein Teilungszyklus (24, 25) gegeben ist.

[0071] Als grobes Beispiel wird angegeben, dass jeder Teilungszyklus (24, 25) zum Beispiel aus acht Mastertakten besteht, sodass nach Ablauf eines Teilungszyklus (24) sich der Teilungszyklus (25) periodisch anschließt und damit wiederholt.

[0072] Wichtig ist nun, dass in der Zeitachse darunter die Mastersteuerung (1) ein Sync-Paket (8) erzeugt, welches gemäß den eingezeichneten Pfeilrichtungen zu verschiedenen Zeiten an den verschiedenen Slave-Steuerungen (5, 6, 7) ankommt.

[0073] So ist erkennbar (in der Zeitdarstellung darunter), dass in der Slave-Steuerung (5) das Sync-Paket (8) in Form des Sync-Paketes (9) mit einer ersten mittleren Verzögerungszeit (12) ankommt, während in der Slave-Steuerung (6) das Sync- Paket (8) in Form des Sync-Paketes (10) mit einer zweiten mittleren Verzögerungszeit (13) ankommt und weiterhin in der Slave-Steuerung (7) das vom Master ausgesendete Sync-Paket (8) mit einer dritten mittleren Verzögerung (14) in Form des Sync-Paketes (11) bei der Slave-Steuerung (7) ankommt.

[0074] Es wird demnach die Entstehung unterschiedlicher mittlerer Verzögerungszeiten (12-14) dargestellt. Wie dies anhand der vorstehenden Zeichnungen erläutert wurde, ist dies durch die unterschiedliche Netzwerktopologie bedingt.

[0075] Die Figur 6 zeigt auch, dass sich der Zyklus der Synchronisation nach Ablauf des Teilungszyklus 24 bei 25 periodisch wiederholt.

[0076] Ein solcher Teilungszyklus wiederholt sich also innerhalb von einigen 100 Mikrosekun-den bis hin zu einigen 100 Millisekunden.

[0077] Nach Figur 6 sendet die Master-Steuerung zyklisch in einer konfigurierbaren Rate ein Sync-Paket über Ethernet via Multicast oder Broadcast gleichzeitig an alle Slave-Steuerungen. Die Slave-Steuerungen empfangen diese Sync-Pakete mit einem zeitlichen Versatz. Der Versatz ist jeder Slave-Steuerung durch vorherige Ermittlung bekannt. Durch Subtraktion dieses 7/25 österreichisches Patentamt AT13 701 U1 2014-06-15

Versatzes ist ein eindeutiger Bezug zum Zeitstempel der Master-Steuerung gegeben.

[0078] In Figur 7 ist der Ablauf eines Synchronisationszyklus, das heißt die Berechnung der für die Slave-Steuerung maßgebenden mittleren Verzögerungszeit wird zeichnerisch dargestellt.

[0079] Ausgehend von der obersten Zeitachse ist dargestellt, dass die Mastersteuerung (1) ihr Sync-Paket (8) in Pfeilrichtung (35) zum Beispiel zur Slave-Steuerung (5) versendet. Dort kommt dieses Sync-Paket in Form des Sync-Paketes (9) mit einer mittleren Verzögerungszeit (Tms1) an. Diese mittlere Verzögerungszeit ist unbekannt und muss berechnet werden, und zwar nach den Maßgaben der Figur 7.

[0080] Um diese Tms1 (mittlere Verzögerungszeit) zu berechnen, wird folgender Rechenalgorithmus verwendet: [0081] Es ist bekannt, dass das an der Slave-Steuerung (5) eintreffende Sync-Paket (9) eine gewisse Durchlaufzeit Ta1 (mit dem Bezugszeichen 26 als Abarbeitungszeit benannt) hat, wobei diese Durchlaufzeit stets gleich ist und von dem speziellen Schaltungsaufbau der Slave-Steuerung (5) abhängt. Diese Arbeitungszeit (26) ist also bekannt.

[0082] Das Sync-Paket (9) soll beispielsweise zu der Zeit (Tms1) bei Position (28) bei der Slave-Steuerung eintreffen und die Abarbeitungszeit (26) kann gemessen werden. Sie wird dadurch gemessen, dass die Zeit zwischen Eintreffen des Sync-Paketes (9) und einem erneuten Versenden der Abarbeitungszeit (26) entspricht. Bei Position 29 wird nämlich dieses Sync-Paket (9) nach Ablauf der Abarbeitungszeit (26) erneut in Form eines Antwortpaketes (34) an die Mastersteuerung (1) zurückgesendet und trifft dort nach der Versendung in Pfeilrichtung (31) bei Position (36) beim Master ein. Dort wird das eintreffende Antwortpaket (34) mit dem Bezugszeichen (30) als Antwortpaket bezeichnet.

[0083] Damit wird von Position (24) zu Position (36) eine sogenannte Round-Trip-Zeit (37) definiert, was bedeutet, dass die Mastersteuerung nun genau weiß, dass das an die Slave-Steuerung (5) versendete Sync-Paket (8) nach einer Round- Trip-Zeit (37) wieder zurück an den Master gesendet wurde. Dieses zurückgesendete Paket in Form des Antwortpaketes (30) trifft also bei Position (36) beim Master wieder ein und damit weiß der Master die Round-Trip-Zeit (Tr1) für die Slave-Steuerung (5).

[0084] Aus der Round-Trip-Zeit (37, Tr1) kann nun die gesuchte Zeit (mittlere Verzögerungszeit, 12, Tv1) berechnet werden. Es sind nämlich die Abarbeitungszeit (26, Ta1) und ebenso die Zeit (Tr1) — dies ist die Round-Trip Zeit vom Master zum Slave und zurück zum Master (37) -bekannt.

[0085] Es wird nun angenommen, dass die Transportzeit vom Slave zum Master Tsm1 (Bezugszeichen 27) identisch ist mit der Transportzeit vom Master zum Slave Tms1 (Bezugszeichen 12). Wenn man von der Round-Trip Zeit Tr1 die Abarbeitungszeit Ta1 abzieht und das Ergebnis halbiert, kommt man auf die gesuchte mittlere Verzögerungszeit Tv1.

[0086] Der Master muss nun bei Position (36) in Pfeilrichtung (32) das von ihm empfangene Antwortpaket (30) entsprechend der einer im Master zwangsläufig gegebenen Verzögerungszeit (33) in Pfeilrichtung (32) dem Slave mitteilen. Der Slave empfängt dieses Paket als Antwortpaket (34) mit dem Ergebnis der vorher errechneten mittleren Verzögerungszeit als Inhalt. Diese Verzögerungszeit wird im Slave gespeichert und zur Kompensation der nachfolgend empfangenen Master-Sync-Pakete verwendet.

[0087] Ab dem Teilungszyklus X + 1 (Bezugszeichen 25) wiederholt sich der Vorgang von Neuem und es ist lediglich in Figur 7 in der untersten Zeitachse schematisiert dargestellt, wie das vorher anhand der Slave-Steuerung (5) dargestellte Synchronisationsverfahren nun bei der Slave-Steuerung (6) stattfindet.

[0088] Zur Ermittlung des Versatzes Tv wird von der Master-Steuerung eine Round-Trip-Laufzeitmessung Tr mit jeder Slave-Steuerung durchgeführt. Dabei wird der betroffene Slave beauftragt, nach Empfang des Sync-Paketes sofort ein Antwortpaket zurück zu senden. Im 8/25 österreichisches Patentamt AT13 701 U1 2014-06-15

Antwortpaket ist die Verarbeitungslaufzeit Ta mit enthalten. Aus der Round-Trip Zeit Tr kann dann unter der Annahme, dass Tms etwa gleich groß ist wie Tsm mit ausreichender Genauigkeit die Versatzzeit Tv ermittelt werden.

Tv: Durchschnittliche Versatzzeit zwischen Master und Slave

Tr: Round-Trip Laufzeit zwischen Master und Slave (hin und zurück)

Ta: Zeit die ein Slave für die Verarbeitung von Sync-Paketen bei der Laufzeitermittlung benötigt

Tms: Paket-Laufzeit vom Master zum Slave Tsm: Paket-Laufzeit vom Slave zum Master [0089] Über die Formel:

Tv - (Tr - Ta) / 2 kann die Versatzzeit Tv je Slave-Steuerung errechnet werden. Die errechnete Versatzzeit wird dann der Slave-Steuerung mitgeteilt. Sobald eine Slave-Steuerung die Versatzzeit erhalten hat, wird im nächsten Zyklus der Zeitstempelwert vom Master übernommen und um die Versatzzeit korrigiert, und dem Zeitstempel-Timer übergeben. Ab diesem Zeitpunkt startet die Regelung des Zeitstempel-Wertes in der betroffenen Slave-Steuerung.

[0090] Der maximale Jitter für die Versatzzeit ist die Differenz zwischen Worst Gase und Best Oase und errechnet sich mit folgender Formel:

Max-Jitter = Anzahl Netzwerk-Knoten * Paketlaufzeit [0091] Die Figur 8 zeigt nun, dass neben der Synchronisation und der Verwendung eines Zeitstempels, der von der Mastersteuerung der Slave-Steuerung zugestellt wird, es auch möglich ist, den Slave-Taktgeber zu synchronisieren und abhängig davon auch die im Slave ablaufenden Applikationen zueinander zu synchronisieren.

[0092] In jeder der Slave-Steuerungen (5-7) können die Applikationen in Phasenlage und Offset auf einen fixen und reproduzierbaren Zeitpunkt in Bezug auf dem Master Taktgeber (Tick) eingerichtet werden. Die Slave Taktgeber regeln sich auf den Master Taktgeber, sowohl was Zeitpunkt und Rate anbelangt, ein. Damit haben die Slave Applikationen innerhalb eines Slaves, zu den anderen Slaves und auch zur Master Steuerung einen eindeutigen zeitlichen Bezug zueinander.

[0093] Hier ist zunächst auf der obersten Zeitachse der Mastertakt (23) angegeben und der vierte und siebente Folgetakt besonders hervorgehoben.

[0094] In der vorher beschriebenen Weise wird mit dem von der Mastersteuerung (1) in Pfeilrichtung (35) ausgesendetem Sync-Paket (8) dieses Sync-Paket in Form des Sync-Paketes (9) von der Slave-Steuerung (5) empfangen, und nach dem in Figur 7 angegebenen Schema ist nun die mittlere Verzögerungszeit Tv1 (Bezugszeichen 12) bekannt.

[0095] Nach der so ermittelten mittleren Verzögerungszeit (12) wird nun auch der Slave-Taktgeber (38) entsprechend synchronisiert. Das heißt, die Slave-Takte werden genau um die mittlere Verzögerungszeit Tv1 zu den Mastertakten aufgrund der bekannten Laufzeiten verschoben, sodass der Slave-Takt (38) genau synchron zu dem Mastertakt (23) abläuft.

[0096] Wichtig ist nun, dass in der vorletzten Zeitdarstellung eine in der Slave-Steuerung angeordnete Slave-Applikation (39) zu einer genau festgelegten Zeit, nämlich einer Offset-Zeit (40) gestartet werden kann, die genau von dem Master-Takt (23) und dem Beginn des Teilungszyklus (24) abhängig ist.

[0097] Damit kann die Slave-Applikation (39) hochpräzise in der Slave-Steuerung in der Abhängigkeit vom Master-Taktgeber gesteuert werden, weil alle dazwischen liegenden Verzögerungszeiten bekannt sind und synchronisiert wurden. 9/25 österreichisches Patentamt AT13 701 U1 2014-06-15 [0098] Gleiches gilt im Übrigen auch für eine in der gleichen Slave-Steuerung (5) ablaufende weitere Slave-Applikation (42), die eine Offset-Zeit (41) in Bezug zum Mastertakt (23) und dem Teilungszyklus (24) aufweist.

[0099] Damit können hochpräzise, und zwar auf wenige Mikrosekunden genau, die Slave-Applikationen (39 und 42) in der Slave-Steuerung (5) gestartet werden und haben eine hochpräzise Synchronisation zum Mastertakt (23).

[00100] Nach Figur 9 werden zu dem im Sync-Paket empfangenen Master Zeitstempel im Addierer (43) die Verzugszeit des Slaves aufaddiert. Das Ergebnis ist ein um die Übertragungszeit korrigierter Master Zeitstempel. Im Subtrahierer wird die Differenz zwischen dem aktuellem Slave Zeitstempel und dem korrigierten Master Zeitstempel gebildet. Die Differenz ist die für diesen Zyklus geltende Abweichung. Im Filter für Ausreißer werden die unbrauchbaren Werte, die durch Übertragungsfehler entstanden sind, ausgefiltert. Diese Werte werden nicht weiter verarbeitet und der Zeitstempel bleibt unkorrigiert. Der nachgeschaltete Regler macht eine Glättung der Abweichungen über eine spezielle Mittelwertbildung. Das Ergebnis ist ein Wert für die Nachstellung des Tick-Timers und ein Werte für die Nachstellung des Zeitstempel-Timers.

[00101] Der Abgleichwert kann sowohl positiv wie auch negativ sein. Im Addierer 2 wird der aktuell Zeitstempel-Wert um die Abweichung korrigiert. Dabei wird durch den Begrenzer berücksichtigt, dass der Zeitstempel nie rückwärtsgehen darf und auch keine zu großen Sprünge machen darf. Die Korrektur soll nie mehr wie 10% der Zykluszeit ausmachen. Zur Verhinderung des Rückwärtslaufes wird der Wert des letzten Zeitstempel-Zugriffs (letztmalige Auslesung) gesichert. Dieser Wert darf nicht unterschritten werden. Der neue Zeitstempel-Wert wird direkt in den Zeitstempel-Timer gespeichert und ist ab diesem Zeitpunkt aktuell nachgeregelt.

[00102] Für den Fall, dass der Zeitstempel noch nicht synchronisiert wurde, muss der Zeitstempelwert des Masters um die Verzugszeit direkt in den Timer des Zeitstempels gespeichert werden (Hochstart-Vorgang).

[00103] Die Figur 9 zeigt einen Regelalgorithmus für die Ermittlung der mittleren Verzögerungszeit.

[00104] Ausgehend von der Masteruhr (1.1) mit dem von der Mastersteuerung (1) erzeugten Zeitstempel (t1) wird dieser Zeitstempel in einen ersten Addierer (43) eingespeist, der die ermittelte Verzugszeit Tvr (Bezugszeichen 12) mit der Masterzeit (t1) addiert und das Ergebnis einem Subtrahierer (44) zuführt. Der Subtrahierer (44) subtrahiert die aktuelle Zeit, das heißt den aktuellen Zeitstempel, und ermittelt daraus eine Differenz (53). Das ist die für diesen Zyklus geltende Differenzzeit der idealen Uhr und der Slave-Uhr.

[00105] Diese Differenz wird einem Filter (45) zugeführt, der eine bestimmte Plausibilitätsprüfung durchführt. Ist die Differenz unglaubwürdig, wird sie als Ausreißer (46) betrachtet und verworfen. Liegt sie in einem bestimmten Plausibilitätsrahmen, wird sie weiterverarbeitet, und zwar in Form einer Abweichung (47) einem Regler (48) eingespeist.

[00106] Der Regler macht eine Glättung der gemessenen Zeit, das heißt er wirkt zum Beispiel wie ein PI-Regler und am Ausgang dieses Reglers (48), der die Abweichung (49) geglättet hat, wird diese geglättete Abweichung einem zweiten Addierer (50) zugeführt, indem der alte Zeitstempel (51) zugeführt ist und der die Abweichung mit dem alten Zeitstempel (51) addiert.

[00107] Die Korrektur erfolgt also im Addierer (50), weil am Ausgang des Addierers der aktuelle neue Zeitstempel (52) ausgegeben wird und nun die aktuelle mit der Masterzeit synchronisierte Slave-Uhr (5.1) darstellt.

[00108] Weil die Slave-Zeit (5.1) möglicherweise in einem anderen Tempo läuft als vergleichsweise die Masterzeit, muss eine ständige Korrektur durch Zuführung des alten Zeitstempels (51) in den Addierer (50) erfolgen, wobei der Begrenzer (58) dafür sorgt, dass der Wert nie negativ wird und rückwärts läuft.

[00109] Damit wird durch den Addierer immer sichergestellt, dass der neueste Zeitstempel 10/25 österreichisches Patentamt AT13 701 U1 2014-06-15 (52), der exakt mit der nun synchronisierten Slave-Uhr übereinstimmt, auch der Masterzeit entspricht.

[00110] Dieser aktuelle Zeitstempel wird in der eingezeichneten Pfeilrichtung (54) dem Subtrahierer zugeführt, damit dieser wiederum den aktuellen Zeitstempel von dem Masterzeitstempel subtrahieren kann. Dies erfolgt beim nächsten Zyklus.

[00111] Die Figur 10 zeigt, wie man aus einem bestimmten Zeitstempelwert, der die synchronisierte Slave-Zeit darstellt, einen entsprechenden Slave-Takt gewinnt, der gemäß der Darstellung in Figur (8) mit dem Slave-Takt (38) angegeben ist und der genau zu dem Mastertakt (23) synchronisiert ist.

[00112] Der Taktgeber erzeugt aus dem Zeitstempel-Wert ein Rechteck Signal, welches als Tick-Interrupt verwendet wird. Der Taktgeber ist ein einfacher Teiler, der beim Nulldurchgang der Operation Zeitstempel-Wert MODULO Tick-Rate eine Flanke erzeugt und bei 50% halber Tick-Rate einen Gegenflanke erzeugt.

[00113] Dadurch ist der Slave-Taktgeber immer synchron zum Master-Taktgeber (Info: bei Verwendung eines Komparators an Stelle eines Teilers zur Erzeugung des Tick-Interrupts müsste der Komparatorswert ebenfalls geregelt werden, um eine Synchronität der Taktgeber zu erhalten). Bei der Übernahme des Zeitstempelwertes beim Hochstarten oder nach einer Re-Synchronisation muss darauf geachtet werden, dass der Taktgeber nie kürzer wie 95% der Zykluszeit sein darf. Im Extremfall wird ein Intervall fast 2 Zyklen lang.

[00114] Hierbei zeigt die Figur (10), dass einfach der Zeitstempelwert (55, ist identisch mit 5.1) in einen Taktgeber (57) eingespeist wird, dem ein bestimmtes Teilverhältnis (56) zugeführt wird. Dieses Teilverhältnis wird auch Tick-Rate bezeichnet. Damit wird der Zeitstempelwert um ein Vielfaches heruntergeteilt und daraus entsteht der Slave-Takt (38), wie dies in Figur 10 dargestellt ist.

[00115] Die Figur 11 zeigt, dass im Addierer (50) gemäß Figur 9 auch noch ein Begrenzer (58) angeordnet ist, der einen bestimmten Regelbereich (59) definiert.

[00116] Zum Beispiel werden die ermittelten Werte um ein Prozent nach unten und um fünf Prozent nach oben maximal korrigiert. Dies wurde mit den Begriffen „unten“ und „oben“ in Figur 11 eingetragen.

[00117] Der Begrenzer (58) zeigt den Regelbereich (59) und einen Mittelwert (60), um den herum geregelt wird.

[00118] Alles was außerhalb des Regelbereiches (59) an Zeitabweichungen gemäß Figur 9 (Bezugszeichen 49) eintrifft, wird entweder in einem Ausschlussbereich nach unten oder in einen Ausschlussbereich nach oben verworfen.

[00119] Der maximale zulässige Jitter liegt im Bereich des Regelbereiches (59) und alles, was außerhalb des Regelbereiches (59) stattfindet, wird als unzulässiger Jitter nach unten (siehe linke Darstellung in Figur 11) oder unzulässiger Jitter nach oben mit einer unzulässig längeren Laufzeit verworfen.

[00120] Die Jitter-Zeiten sind demnach nur in einem bestimmten Regelbereich noch zulässig. Man kann bei der erfindungsgemäßen Synchronisierung zwischen einem Master und einer Anzahl von daran angeschlossenen Slaves mit einer gewissen Ungenauigkeit leben, die im vorliegenden Fall zum Beispiel bis zu 100 Mikrosekunden beträgt. Dies wird durch den Regelbereich (59) symbolisiert.

[00121] Gemäß der allgemeinen Beschreibung hängt der jedem Sync-Paket zugeordnete Jitter von der Netzwerkgeschwindigkeit, der aktuellen Auslastung und der Netzwerktopologie ab.

[00122] Der Zeitstempelwert darf deshalb im eingeregelten Betrieb nicht springen. Beim Hochstarten des Systems ist aber ein solches Springen zugelassen.

[00123] Deshalb wird zur Glättung der Zeitstempelwerte der in Figur 9 dargestellte Regler (48) 11 /25 österreichisches Patentamt AT13 701 U1 2014-06-15 verwendet.

[00124] Gemäß Figur 11 muss damit gerechnet werden, dass die Paketlaufzeiten der Sync-Pakete um bis zu 1 ms nach oben schwanken. Mit einer Laufzeitschwankung nach unten ist nur geringfügig zu rechnen. Das hängt damit zusammen, dass im Normalfall ein ungehinderter (wenig Jitter aufweisender) Sync-Paket Transport gewährleistet ist. Im eingeregelten Bereich werden nur die sich im Regelbereich befindlichen Sync-Pakete verwertet. Im Ausschussbereich erfolgt keine Nachregelung, es gilt der Werte des vorangegangenen Zyklus. ERLÄUTERUNGEN (GLOSSAR): [00125] Max-Jitter: Maximale Zeitschwankungen [00126] Netzwerk-Knoten ist ein Knoten im Netzwerk, bei dem üblicherweise eine Netzwerk Verkabelung an oder abgeht. Jeder Switch und jede Steuerungseinheit ist ein Netzwerk-Knoten, bei 3 Switches sind das somit 5 Netzwerk-Knoten [00127] Paketlaufzeit ist die Übertragungszeit für ein Maximalpaket, bei 100 MBit Technologie ist dies 125 ps, bei 1 GBit Technologie ist dies 12,5 ps. [00128] Ethernet Priorität ist die Prioriät eines einzelnen Ethernet Pakete. Mit dieser Priorität wird die Verarbeitung von Ethernet Paketen in den Switches priori-siert. Siehe auch IEEE 802.1 Q oder VLAN- Tag. [00129] Zeitstempel [00130] Zeitstempel-Timer [00131] Taktgeber ist ein 64 Bit Wert mit einer Auflösung von ps. ist ein Zähler, der den Zeitstempel aktuell hält (inkrementiert). ist die Zeitbasis in Form von Tick Interrupts für das Betriebssystem und somit für die gesamte Steuerung [00132] Hauptsteuerung ist die Steuerung, welche die Zeitbasis für alle Untersteuerungen zur Verfügung stellt und diese aktiv synchronisiert. [00133] Master-Steuerung [00134] Untersteuerung ist identisch mit Hauptsteuerung ist die Steuerung, welche sich auf die Hauptsteuerung synchronisiert. [00135] Slave-Steuerung ist eine andere Bezeichnung für Untersteuerung. 12/25 österreichisches Patentamt AT 13 701 U1 2014-06-15

ZEICHNUNGSLEGENDE 1 Master-Steuerung 31 Pfeilrichtung 32 Pfeilrichtung 1.1 Master-Uhr 33 Verzögerungszeit 2 Master-Steuerung (redundant) 34 Antwortpaket 3 Empfänger für Referenzzeit 35 Peilrichtung 4 Netzwerk (Ethernet) 36 Position 5 Salve-Steuerung 1 37 Round-Trip-Zeit Tr1 5.1 Slave-Uhr 1 38 Slave-T akt 6 Salve-Steuerung 2 39 Slave-Applikation 1 6.1 Slave-Uhr 2 40 Offset-Zeit 1 7 Slave-Steuerung 3 41 Offset-Zeit 2 7.1 Slave-Uhr 3 42 Slave-Applikation 2 8 Sy nc-Paket 43 Addierer 1 9 Sy nc-Paket 1 44 Substrahierer 10 Sy nc-Paket 2 45 Filter 11 Sy nc-Paket 3 46 Ausreißer 12 Mittlere Verzögerungszeit (Tv1) 47 Abweichung 13 Mittlere Verzögerungszeit (Tv2) 48 Regler 14 Mittlere Verzögerungszeit (Tv3) 49 Abweichung 15 Kompensator 1 50 Addierer 2 16 Kompensator 2 51 Zeitstempel alt 17 Kompensator 3 52 Zeitstempel neu 18 Switch 53 Differenz 19 Switch 54 Pfeilrichtung 20 Switch 55 Zeitstempelwert 21 Redundanz-Verbindung 56 Teilverhältnis (Tick-Rate) 22 Factory-Netzwerk 57 Taktgeber 23 Mastertrakt 58 Begrenzer 24 Teilungszyklus (X) 59 Regelbereich 25 Teilungszyklus (X +1) 60 Mittelwert 26 Abarbeitungszeit (Ta1) 27 Transportzeit Slave-Master (Tsm1) 28 Position 29 Position 30 Antwortpaket 13/25

Claims (10)

1. österreichisches Patentamt AT13 701 U1 2014-06-15 Ansprüche 1. Verfahren zur Synchronisation mindestens des Zeitstempels (Zeitbasis) einer Master-Steuerung (1) mit mindestens einer Slave-Steuerung (5 -7) in einem verzweigten Datennetz, z.B. einem Ethernet-Netzwerk, dadurch gekennzeichnet, dass die Mastersteuerung (1) zyklisch über das Netzwerk (4) ein Sync-Paket (8-11) via Multicast oder Broadcast an die Slave-Steuerung (57) sendet, dass jedes Sync-Paket (8-11) den Zeitstempel der Master-Uhr (1.1) zum Zeitpunkt der Versendung enthält, dass jede Slave-Steuerung (5-7) die mittlere zeitliche Verzögerung zur Master-Uhr berechnet und mit diesem Wert den Zeitstempel der Master-Uhr (1.1) korrigiert und als eigenen Zeitstempel in der Slave-Uhr (5.1, 6.1,7.1) verwendet.
2. 2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass bei Verbindungsaufnahme mit einer neuen Slave-Steuerung (5-7) jeweils ein bidirektionaler Datenaustausch über priori-sierte Ethernet Pakete im Netzwerk (4) erfolgt, dass in diesem Verbindungsaufbau die Laufzeit über die gesamte Netzwerk Infrastruktur (4) gemessen wird und der Slave-Steuerung (5-7) nach erfolgreichem Verbindungsaufbau als Offset zur Laufzeitkompensation mitgeteilt wird.
3. 3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Laufzeitmessung zum Startzeitpunkt gemacht wird und im laufenden Betrieb wiederholt wird und dass im Slave über eine Mittelwertbildung von mehreren Laufzeitmessungen eine höhere Genauigkeit der Verzugszeit erreicht wird.
4. 4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die Startzeitpunkte der Applikationen (Cycle Start) auf allen Teilnehmern (Master-Steuerung 1 und Slave-Steuerungen 5-7) über eine konfigurierbare Zeitversetzung mit einem reproduzierbaren Zeitbezug untereinander betrieben werden.
5. 5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass zur Glättung der Zeitstempelwerte ein Regler (48) verwendet wird und aus dem Zeitstempelwert auch der Taktgeber abgeleitet wird.
6. 6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass die Ungenauigkeiten der Laufzeitkompensation durch die Master-Steuerung (1) überwacht wird, und dass jede Slave-Steuerung (5-7) einen Zeitstempel (5.1, 6.1,7.1) als geregelten über mehrere Zyklen ermittelten Wert aufweist, dessen Abweichung (aktuelles Delta) als Rückpaket an die Master-Steuerung zurückgemeldet wird.
7. 7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass die Synchronisation zwischen der Master-Steuerung (1) und den Slave-Steuerungen (5-7) nach der Formel: Tv = (Tr-Ta) / 2 erfolgt, wobei Tv: die durchschnittliche Versatzzeit zwischen Master und Slave ist Tr: die Round-Trip Laufzeit zwischen Master und Slave (hin und zurück) ist Ta: die Zeit ist, die ein Slave für die Verarbeitung von Sync-Paketen bei der Lauf zeitermittlung benötigt
8. 8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass der maximale Jitter für die Versatzzeit aus der Differenz zwischen Worst Case und Best Case nach folgender Formel errechnet wird: Max-Jitter = Anzahl Netzwerk-Knoten * Paketlaufzeit 14/25 österreichisches Patentamt AT13 701 U1 2014-06-15
9. 9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass in jeder der Slave-Steuerungen (5-7) die Applikationen (39, 42) in Phasenlage und Offset-Zeit (40, 41) auf einen fixen und reproduzierbaren Zeitpunkt in Bezug auf dem Master-Taktgeber (23) (Tick) eingerichtet werden.
10. 10. Vorrichtung zur Ausführung des Verfahrens nach mindestens einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass die Verzugszeit in der Slave-Steuerung (5-7) durch ein vom Master Zeitstempel (1.1) empfangenes Sync-Paket (8-11) in einem Addierer (43) der Slave-Steuerung (5-7) addierbar ist, dass das Ergebnis ein um die Übertragungszeit korrigierter Master Zeitstempel (1.1) ist und dass in einem Subtrahierer (44) die Differenz zwischen dem aktuellem Slave Zeitstempel (5.1, 6.1, 7.1) und dem korrigierten Master Zeitstempel gebildet ist und dass die daraus gebildete Differenz die für diesen Zyklus geltende Abweichung zwischen der Masterzeit (1.1) und der Slave-Zeit (5.1,6.1 und 7.1) ist. Hierzu 10 Blatt Zeichnungen 15/25