Beschreibung

Zur Herstellung eines synchronen Betriebs zwischen einem SPS ( Speicher-Programmierbare-Steuerung) -LaufzeitSystem und einem lokalen I/O ( Input /Output ) -Bus mit dem Ziel der Jitter- Minimierung bedarf es in der Regel einer

hardwareunterstützten Synchronisierung dieser Komponenten, bei der sowohl die CPU (Central Processing Unit) als auch die Logik des Lokalbusses von einem durch Hardware generierten Signal getriggert werden muss. Steht dieses Signal nicht zur Verfügung oder sprechen andere Gründe gegen eine

hardwareunterstützte Synchronisierung, wie z.B. die

Komplexität der FPGA (Frei Programmierbaren Gate Array) - Modelle oder die damit verbundenen Kosten, laufen das SPS- LaufzeitSystem und der Lokalbus asynchron zu einander.

Werden dann z.B. I/O-Daten stets nach Abschluss eines

jeweiligen SPS-Zyklusses direkt auf den Lokalbus ausgegeben, hat dies in der Regel zur Folge, dass ungleichmäßige

Bearbeitungsdauern von SPS-Tasks oder auch der allgemeine System itter , z.B. hervorgerufen durch die Interrupt-Last und also durch kurzfristige Unterbrechungen der normalen

Programmausführung, um andere, meist kurze, aber

zeitkritische Verarbeitungen durchzuführen, sich ungefiltert auf den Lokalbus auswirken und dort als unerwünschte Jitter, d.h. Störungen, die eine Genauigkeitsschwankung im

Übertragungstakt hervorrufen, erkennbar sind. Je kleiner jedoch die vorgegebene Zykluszeit und das Zeitraster von aufeinanderfolgenden Zyklen eines Lokalbusses sind, desto gravierender sind die Auswirkungen solcher Jitter auf den Lokalbus und verhindern deterministische Ausgaben von I/O- Daten auf dem Lokalbus .

Eine Synchronisierung ausgehend vom Lokalbus zur Erzielung deterministischer Ausgaben von I/O-Daten auf den Lokalbus, z.B. indem nach jedem Zyklus ein "Zyklus beendet" Interrupt generiert wird, hat zumindest dann ihre Grenzen, wenn die Zykluszeiten so schnell sind, dass dadurch das komplette System blockiert werden würde und/oder der Lokalbus

dahingehend ausgelegt ist, dass systembedingt permanent

Zyklen gefahren werden müssen und somit keine künstlichen Pausen zwischen den Zyklen eingebaut werden dürfen.

Insbesondere in Fällen eines Lokalbusses mit extrem kurzen und/oder systembedingt permanent zu fahrenden Zyklussen können die Jitter-Werte zum Einen zu hoch und zum Anderen derart nicht deterministisch sein, da die Größe eines jeden Jitters von vielen Systemparametern abhängt, wie z.B. von der SPS-Zykluszeit , dem Jitter der Ausführungsdauer einer SPS- Task und/oder der Interrupt Last, dass die im asynchronen Betrieb erzielten Werte des Jitters auf einem Lokalbus unbefriedigend sind und sich folglich Prozess-störend, gegebenenfalls auch sicherheitskritisch auf die an den

Lokalbus angeschlossenen Lokalbus-Teilnehmer auswirken. Eine Aufgabe der Erfindung ist es, einen Weg zur Synchronisierung eines SPS-LaufzeitSystems mit einem lokalen I/O Bus mit dem Ziel zu schaffen, den Jitter auf dem lokalen I/O Bus einerseits absolut zu minimieren sowie andererseits die durchschnittlichen Abweichungen vom Mittelwert des

Jitters zu minimieren, so dass die Werte des Jitters

unabhängig von den Systemparametern ansonsten konstant bleiben . Die Lösung der Aufgabe ist durch ein Verfahren sowie eine Steuerungsvorrichtung mit den Merkmalen der unabhängigen Ansprüche gegeben. Vorteilhafte oder zweckmäßige Ausführungen und Weiterbildungen sind Gegenstand der abhängigen Ansprüche.

Die Erfindung schlägt folglich als eine Lösung ein Verfahren zum Betreiben einer Steuerungsvorrichtung, welche ein SPS- LaufzeitSystem zur Ausführung von SPS-Tasks und eine

Anschalt- und Steuereinrichtung zum Anschalten eines

Lokalbusses und zur Steuerung der Ausgabe von durch

Ausführung bestimmter SPS-Tasks erhaltenen Daten auf einen angeschalteten Lokalbus aufweist, vor, ein echt zeitfähiges Betriebssystem mit einem Systemtakt vorzusehen und das SPS- LaufzeitSystem und die Steuerung der Ausgabe an ein und dasselbe Taktgebersignal für den Systemtakt, insbesondere den Systemtick, zu koppeln.

Ferner schlägt die Erfindung als Lösung eine

Steuerungsvorrichtung vor, welche ein echt zeitfähiges

Betriebssystem mit einem Systemtakt, ein SPS-Laufzeitsystem zur Ausführung von SPS-Tasks sowie eine Anschalt- und

Steuereinrichtung zum Anschalten eines Lokalbusses und zur Steuerung der Ausgabe von durch Ausführung einer SPS- Applikation erhaltenen Daten auf einen angeschalteten

Lokalbus aufweist, und wobei das SPS-LaufzeitSystem und die Steuerung der Ausgabe an ein und dasselbe Taktgebersignal für den Systemtakt, insbesondere den Systemtick, gekoppelt sind.

Die Erfindung schlägt zur Synchronisierung eines SPS- LaufzeitSystems mit einem lokalen I/O-Bus folglich zwei in einander greifende Komponenten bzw. Maßnahmen vor. Zum Einen die Kopplung des SPS-LaufzeitSystems an ein Taktgebersignal für den Systemtakt des Betriebssystems und zum Anderen die Kopplung der Steuerung der Ausgabe auf den Lokalbus an dasselbe Taktgebersignal, welches insbesondere der Systemtick ist. Durch das Zusammenspiel beider Maßnahmen wird eine

Synchronisierung zwischen SPS-LaufzeitSystem und lokalem I/O- Bus erreicht, und also das SPS-LaufzeitSystem und der lokale I/O-Bus aufeinander abgestimmt.

In einer bevorzugten Ausführung sieht die Erfindung hierbei vor, durch Ausführung einer SPS-Task erhaltene Daten, welche auf den Lokalbus auszugeben sind, in einem ersten Schritt in einen von wenigstens zwei Buffer abzulegen, welcher nicht an den angeschalteten Lokalbus gekoppelt ist und in einem zweiten Schritt einen Wechsel der Buffer durchzuführen, so dass der Buffer mit den abgelegten Daten an den

angeschalteten Lokalbus gekoppelt wird und in einem dritten Schritt die abgelegten Daten auf den angeschalteten Lokalbus ausgeben werden.

In einer bevorzugten Ausführung sieht die Erfindung vor, dass unter Ansprechen auf ein Interrupt von dem Betriebssystem hin und bei Vorliegen von Daten in einem Buffer, zunächst die Ausgabe dieser Daten auf den Lokalbus gesteuert wird, insbesondere ein Bufferwechsel durchgeführt wird und die Daten in dem dann an den angeschalteten Lokalbus gekoppelten Buffer auf diesen ausgegeben werden, und anschließend eine SPS-Task zum Erhalt von weiteren auf den angeschalteten

Lokalbus auszugebenden Daten gestartet wird.

In einer bevorzugten Ausführung sieht die Erfindung vor, nach Ausführung der SPS-Task zum Erhalt von auf den angeschalteten Lokalbus auszugebenden Daten und Ablage dieser Daten in dem Buffer für die Anschalt- und Steuereinrichtung ein

Signalisierungsflag zu setzen, wobei bei gesetztem

Signalisierungsflag auf das Vorliegen von Daten in einem Buffer, welcher nicht an den angeschalteten Lokalbus

gekoppelt ist, erkannt wird.

Im Folgenden wird der bisherige Stand der Technik sowie der Erfindungsgedanke anhand von Ausführungsbeispielen in den beigefügten Figuren näher erläutert. Hierbei zeigen:

Fig. 1 ein prinzipiell möglicher interner Aufbau zwischen einem SPS LaufzeitSystem und einem Lokalbus nach dem Stand der Technik; Fig. 2 einen zeitlichen Verlauf eines asynchronen Betriebs aufbauend auf einem internen Aufbau zwischen einem SPS LaufzeitSystem und einem Lokalbus nach dem Stand der Technik gemäß Fig. 1 ; Fig. 3 ein Beispiel eines prinzipiell möglichen internen

Aufbaus zwischen einem SPS LaufzeitSystem und einem Lokalbus im Rahmen der Erfindung; und

Fig. 4: einen zeitlichen Verlauf eines synchronen Betriebs im

Rahmen der Erfindung aufbauend auf einem Aufbau gemäß

Fig. 3, am Beispiel einer mit Firmware basierenden Synchronisierung .

Fig. 1 zeigt ein Ausführungsbeispiel eines prinzipiell möglichen internen Aufbaus zwischen einem SPS LaufzeitSystem und einem Lokalbus nach dem Stand der Technik;

Skizziert ist eine Steuerungsvorrichtung 100, welche z.B. eine Kompaktsteuerung mit integriertem Ethernet- und

Lokalbus-Anschluss sein kann. Die Steuerungsvorrichtung stellt als Kopf einer Lokalbus-Station die Funktion einer Steuerung zur Verfügung. Der Lokalbus 500 wird aufgebaut, indem Lokalbus-Module an die Steuerungsvorrichtung angereiht werden .

Die Steuerungsvorrichtung 100 umfasst ein echt zeitfähiges Betriebssystem mit einem Systemtakt, z.B. als Herstellereigene Firmware 200, und bietet einer SPS zur Ausführung von SPS-Tasks ein LaufzeitSystem 300. Ein solches LaufzeitSystem kann im Rahmen der Erfindung zweckmäßig ein eCLR-

LaufzeitSystem (Embedded Common Language Runtime) sein.

Ferner weist die Steuerungsvorrichtung 100 eine Anschalt- und Steuereinrichtung 400 auf, zum Anschalten eines Lokalbusses und zur Steuerung der Ausgabe von durch Ausführung einer SPS- Tasks erhaltenen Daten auf einen angeschalteten Lokalbus. Die Anschalt- und Steuereinrichtung 400 kann somit eine

Schnittstelle für die Lokalbus-Module 500 zur Verfügung stellen . Die Anschalt- und Steuereinrichtung 400 kann hierbei in der Steuerungsvorrichtung 100 vorintegriert sein oder mit dieser über entsprechende Schnittstellen, insbesondere modulhaft, verbunden sein.

Das SPS-LaufzeitSystem bietet das Umfeld, dass zu bestimmten Zeiten eine SPS-Task 310 abgearbeitet wird, wodurch Daten erhalten werden, die auf einem angeschalteten Lokalbus 500 und daran angeschlossenen Lokalbus-Teilnehmern zur Verfügung zu stellen sind. Bei diesen Daten kann es sich im Rahmen der Erfindung folglich bevorzugt um I/O Daten handeln,

insbesondere um Prozessdaten, die ein jeweils aktuelles

Datenbild eines jeweiligen ( Teil- ) Prozesses darstellen. Um nach einer jeweiligen Abarbeitung einer solchen SPS-Task 310 dann die erhaltenen Daten, und also insbesondere das

aktualisierte Prozessdatenbild dem Lokalbus zur Verfügung zu stellen, ist eine Einrichtung 320, z.B. ein I/O-Treiber, vorgesehen .

Die Anschalt- und Steuereinrichtung 400 kann hierfür ferner einen Buffer vorsehen, in welchem die auf den Lokalbus auszugebenden Daten vor Ausgabe zwischengespeichert werden können. So kann die Anschalt- und Steuereinrichtung 400 zweckmäßig mit einem wenigstens zwei Buffer 410, 420

umfassenden Wechselbuffer ausgebildet sein, wobei, z.B.

mittels eines Bufferschalters 430, jeweils einer der Buffer wechselweise an einen angeschalteten Lokalbus zu koppeln ist, um die darin enthaltenen Daten auf den Lokalbus auszugeben. Anstelle des Vorhandenseins eines Wechselbuffers kann z.B. auch nur lediglich ein einziger Buffer vorgesehen sein, so dass dann, z.B. mittels des Bufferschalters 430, lediglich die im Buffer enthaltenen Daten auf den Lokalbus auszugeben sind .

Basierend auf obigen Ausführungen einer im Rahmen der

Erfindung grundsätzlich einsetzbaren Steuerungsvorrichtung, besteht ein prinzipiell möglicher interner Aufbau zwischen dem SPS LaufzeitSystem 300 und dem Lokalbus 500 nach dem Stand der Technik gemäß Fig. 1 darin, dass nach Abarbeitung der SPS-Task 310 die Einrichtung 320 aufgerufen wird. Diese kopiert in einem ersten Schritt das Prozessdatenbild zunächst in den aktuell nicht benutzten Buffer, gemäß Fig. 1 in den

Buffer 420, des Wechselbuffers und anschließend weist sie in einem zweiten Schritt die Anschalt- und Steuereinrichtung 400 für den Lokalbus an, den Bufferwechsel durchzuführen, um daraufhin in einem dritten Schritt das aktualisierte

Prozessdatenbild auf den Lokalbus auszugeben.

Fehlt die Synchronisierung zwischen SPS-LaufzeitSystem 300 und Lokalbus 500, werden somit auch die zur Ausgabe an den Lokalbus vorgehaltenen Daten asynchron zum Zyklus des

Lokalbusses auf diesen ausgegeben.

Basierend auf Fig. 1 wird nach dem Stand der Technik im asynchronen Betrieb somit wie folgt verfahren. Am Ende eines jeden SPS-Zyklusses wird das durch die SPS-Task 310

aktualisierte Prozessdatenabbild durch die Einrichtung 320 in den aktuell freien Buffer des Wechselbuffers für den Lokalbus 500 kopiert und die Anschalt- und Steuereinrichtung 400 für den Lokalbus unmittelbar angewiesen, den Bufferwechsel durchzuführen und somit die neuen Daten auf den Lokalbus auszugeben, z.B. sofort nach dem Bufferwechsel das

aktualisierte Prozessdatenbild auf den Lokalbus auszugeben.

Fig. 2 zeigt einen zeitlichen Verlauf eines asynchronen

Betriebs aufbauend auf einem internen Aufbau zwischen einem SPS LaufzeitSystem und einem Lokalbus nach dem Stand der Technik gemäß Fig. 1.

Zu einem Zeitpunkt to wird mittels eines Interrupt Request (IRQ) ein Interrupt generiert. Ein auf einen Interrupt

Request zur Durchführung der anderen Verarbeitung folgendes Programm kann als Interrupt Service Routine (ISR) verstanden werden. Ist dieser Zeitpunkt z.B. der Systemtick für den Systemtakt des Betriebssystems, bei Fig. 2 mit „Systick" wiedergegeben, wird das Interrupt folglich mit einer Systick IRQ generiert. Die auf die IRQ folgende ISR, bei Fig. 2 aufgrund der angenommenen Systick IRQ als „OS (Operating System) Tick Handler" bezeichnet, ruft daraufhin mit einer Verzögerung tdi den Scheduler des SPS-LaufzeitSystems auf, welcher wiederum die SPS-Task 310 startet. Die Dauer der SPS- Task 310 ist mit td ₂ angegeben. Nach Abarbeitung der SPS-Task 310 werden dann die Ausgangsdaten in einen Buffer für den Lokalbus kopiert und daraufhin im Falle eines Wechselbuffers gemäß Fig. 1 die Anschalt- und Steuereinrichtung für den Lokalbus unmittelbar angewiesen, den Bufferwechsel

durchzuführen, um dann zu einem Zeitpunkt tl, die Daten auf den Lokalbus auszugeben. Zu einem nächstfolgenden Zeitpunkt to wird der nächste

Interrupt durch die Systick IRQ generiert, auf die wiederum die ISR „OS (Operating System) Tick Handler" folgt, für eine erneute Abarbeitung der SPS-Task 310. Die Kopplung des

SPS-LaufzeitSystems an den Systemtick kann zweckmäßig dadurch erfolgen, dass der Aufruf des SPS LaufzeitSystem Schedulers aus einer speziell für diesen Zweck angelegten hochprioren Task, z.B. einer sogenannten Systemtick Task, erfolgt.

Maßgeblich für den Jitter ist folglich zusammenfassend jedoch die Verzögerung tdi des Aufrufs des SPS Schedulers nach einem Interrupt, der z.B. durch eine Systick Interrupt Request (IRQ) zum Zeitpunkt to hervorgerufen wird, sowie die Dauer t _d 2 der SPS Task 310. Der in Bezug auf den Lokalbus unerwünschte Jitter ist letztendlich das Delta über die Zeit zwischen aufeinander folgenden Zeitpunkten ti. Der Jitter entspricht somit im Wesentlichen der in Fig. 2 dargestellten Zeitspanne

Fig. 3 zeigt nunmehr ein Beispiel eines prinzipiell möglichen internen Aufbaus zwischen einem SPS LaufzeitSystem und einem Lokalbus im Rahmen der Erfindung.

In Abwandlung zum prinzipiell möglichen internen Aufbau zwischen einem SPS LaufzeitSystem und einem Lokalbus nach Fig. 1 wird gemäß Lösung nach der Erfindung wie folgt

verfahren . Die Ausgabe der Daten auf den Lokalbus 500, basierend auf Fig. 3 zweckmäßig bereits die Initiierung des Bufferwechsels, wird erfindungsgemäß von der Abarbeitung der SPS-Task 310 entkoppelt und stattdessen an ein Taktgebersignal für den Systemtakt, insbesondere den Systemtick des Systemtaktes, gekoppelt. Damit sich das SPS-LaufzeitSystems 300 synchron zum Lokalbus 500 verhält, und insbesondere der Scheduler des SPS-LaufzeitSystems 300, der unter anderem für den Start der SPS-Task 310 zuständig ist, wird das SPS-LaufzeitSystem 300, insbesondere der Scheduler des SPS-LaufzeitSystems 300 ebenfalls an dasselbe Taktgebersignal für den Systemtakt, und also insbesondere auch an den Systemtick des Systemtaktes, gebunden, z.B. indem direkt aus der entsprechenden Interrupt Service Routine des Interrupts der Aufruf der Schedulers getriggert wird.

Damit dient ein einziges Taktgebersignal für den Systemtakt, insbesondere der Systemtick, und insbesondere dessen

entsprechende Interrupt Service Routine, als Koppelglied zwischen SPS-LaufzeitSystem 300 und Lokalbus 500.

Ferner wird gemäß Erfindung zweckmäßig vor Abarbeitung der SPS-Task 310 immer zunächst in einem ersten Schritt die

Funktion eines optionalen Bufferwechsels und einer hierauf in einem zweiten Schritt basierenden Ausgabe der Daten des dann aktuell benutzen Buffers auf den Lokalbus 500 aufgerufen. Ist anstelle des Vorhandenseins eines Wechselbuffers nur

lediglich ein einziger Buffer vorgesehen, wird folglich gemäß Erfindung zweckmäßig vor Abarbeitung der SPS-Task 310 immer zunächst die Funktion einer optionalen Ausgabe von Daten des Buffers auf den Lokalbus 500 aufgerufen. Anschließend wird dir SPS-Task 310 abgearbeitet und die hierauf zur Ausgabe auf den Lokalbus 500 erhaltenen Daten in einem Buffer abgelegt. So wird z.B. basierend auf Fig. 3 nach Abarbeitung der SPS-Task 310 die Einrichtung 320 aufgerufen, um in einem dritten Schritt das Prozessdatenbild zunächst in den aktuell nicht benutzten Buffer, gemäß Fig. 3 in den

Buffer 420, des Wechselbuffers der Anschalt- und

Steuereinrichtung 400 für den Lokalbus 500 zu kopieren.

Anstelle jedoch unmittelbar einen Bufferwechsel zu initiieren oder alternativ bei Vorhandensein nur eines Buffers lediglich die Ausgabe vom im Buffer enthaltenen Daten auf den Lokalbus zu initiieren, wird bevorzugt lediglich ein Flag für die Anschalt- und Steuereinrichtung 400 für den Lokalbus 500 gesetzt, zur Signalisierung, dass neue Daten vorliegen.

Der eigentliche Bufferwechsel und die hierauf basierende Ausgabe der Daten des dann aktuell benutzen Buffers auf den Lokalbus 500 oder alternativ im Falle lediglich eines einzigen Buffers die Ausgabe von Daten des Buffers auf den Lokalbus 500 wird dann durch den nächstfolgenden globalen Systemtick aufgerufen, und zwar unmittelbar vor der dann nächstfolgenden Abarbeitung der SPS-Task 310.

Fig. 4 zeigt einen zeitlichen Verlauf eines synchronen

Betriebs im Rahmen der Erfindung aufbauend auf einem Aufbau gemäß Fig. 3, am Beispiel einer mit Firmware basierenden Synchronisierung gemäß der Erfindung. Wie in Bezug auf Fig. 3 bereits beschrieben, besteht die Implementierung aus zwei ineinander greifenden Komponenten bzw. Maßnahmen, zum Einen die Kopplung des SPS- LaufzeitSystems an ein Taktgebersignal für den Systemtakt des Betriebssystems, insbesondere an den Systemtick des

Systemtakts, und zum Anderen die Kopplung der Steuerung der Ausgabe auf den Lokalbus an dasselbe Taktgebersignal für den Systemtakt des Betriebssystems und also insbesondere an den Systemtick des Systemtakts.

Wie bei Fig. 4 zu sehen, kann die Kopplung des

SPS-LaufzeitSystems an den Systemtick, wie bereits in Bezug auf Fig. 2 aufgezeigt, zweckmäßig dadurch erfolgen, dass der Aufruf des SPS LaufzeitSystem Schedulers aus einer speziell für diesen Zweck angelegten hochprioren Task, z.B. einer sogenannten Systemtick Task, erfolgt. Um jedoch, im Gegensatz zu Fig. 2, den Jitter t _d i des Aufrufs des SPS LaufzeitSystem Schedulers zu minimieren, wird vorzugsweise ferner ein

Betriebssystem-Event, auch als OS (Operating System) -Event bezeichnet, angelegt, auf welches in der Systemtick Task dann vor Aufruf des Schedulers des SPS LaufzeitSystems gewartet wird .

Das Triggern dieses OS-Events erfolgt ferner zweckmäßig direkt aus der Interrupt Service Routine (ISR) des Systemtick Interrupts heraus. Damit der Jitter des Aufrufs des SPS

LaufzeitSystem Schedulers nochmals minimiert wird, ist in besonders bevorzugter Ausführung zum Einen die Systemtick Task diejenige Task im System mit höchster Priorität und zum Anderen der Systemtick Interrupt seinerseits ebenfalls derjenige Interrupt im System, dem die höchste Priorität zugewiesen wurde.

Nach Abschluss der Abarbeitung einer SPS Task 310 werden die aktuellen Ausgangsdaten in einen Buffer der Anschalt- und

Steuereinrichtung für den Lokalbus geschrieben, z.B. in den jeweils nicht genutzten Buffer eines Wechselsbufferss der Anschalt- und Steuereinrichtung für den Lokalbus, ohne jedoch unmittelbar die Ausgabe der Daten bzw. zuvor einen

Bufferwechsel zu initiieren.

Stattdessen wird lediglich ein Flag zur Signalisierung, dass neue Daten vorliegen, gesetzt. Die eigentliche Ausgabe der Daten bzw. ein hierfür notwendiger vorheriger Bufferwechsel erfolgt dann in der oben genannten Interrupt Service Routine des Systemticks, und zwar vor dem Triggern des OS Events, durch Aufruf einer entsprechenden Schnittstellenfunktion der Anschalt- und Steuereinrichtung für den Lokalbus. In dieser Schnittstellenfunktion wird geprüft, ob das Flag zum

Signalisieren eines erforderlichen Bufferwechsels gesetzt ist. Ist dies der Fall, wird die Ausgabe der Daten im Buffer bzw. alternativ zuvor der Bufferwechsel direkt im Kontext der Interrupt Service Routine in der Anschalt- und

Steuereinrichtung für den Lokalbus, z.B. durch entsprechende Anweisung eines Bufferschalters, initiiert.

In der Interrupt Service Routine des Systemticks wird also immer zunächst die Funktion zur optionalen Ausgabe von Daten im Buffer bzw. zum optionalen vorherigen Bufferwechsel aufgerufen und anschließend die SPS-Task 310 bzw. insbesondere der SPS-LaufzeitSystems Scheduler.

Damit ist folglich das SPS-LaufzeitSystem als auch die

Steuerung der Ausgabe an ein und dasselbe Taktgebersignal für den Systemtakt des Betriebssystems, und insbesondere an den Systemtick, gekoppelt.

Bei einem typischen Intervall des Systemtick Timers von 1ms werden somit die Ausgangsdaten höchstens einmal pro

Millisekunde auf dem Lokalbus aktualisiert, dies allerdings synchron zum Taktgebersignal, insbesondere zum Systemtick, und somit mit minimiertem sowie geglättetem Jitter.

Maßgeblich für den Jitter ist gemäß Fig. 4 folglich

zusammenfassend, dass durch die Verwendung eines OS Events zum Aufrufen der SPS-Task bzw. zum Triggern des SPS

LaufzeitSystem Schedulers der Jitter von tdi nochmals

wesentlich geringer und konstanter als beim asynchronen

Betrieb gemäß Fig. 2 ist.

Der Jitter der SPS Task Ausführungsdauer t _d 2 bleibt zwar unverändert, wird jedoch durch die auf den Zeitpunkt ti synchronisierte Datenausgabe bzw. bzw. den auf diesen

Zeitpunkt synchronisierten Bufferwechsel unwirksam gemacht. Durch die Synchronisierung von ti zum Systick to kann das Delta von aufeinanderfolgenden ti, also der Jitter t _j , minimiert und geglättet und folglich ein synchroner Betrieb aufrechterhalten werden.

Die Erfindung bietet somit eine auf einem echt zeitfähigen Betriebssystem basierende und somit insbesondere eine implementierte Firmware-basierende Lösung zur Synchronisierung eines SPS LaufzeitSystems mit einem

Lokalbus .

Als SPS-LaufzeitSystem kann im Rahmen der Erfindung daher zweckmäßig ein eCLR-LaufzeitSystem eingesetzt werden. Die Synchronisierung gemäß der Erfindung bietet ferner den

Vorteil, dass sie insbesondere auch für Lokalbusse mit extrem kurzen und/oder systembedingt permanent zu fahrenden

Zyklussen anwendbar ist, so dass in bevorzugter Ausführung als Lokalbus ein Axioline-Bus bzw. Axioline-Lokalbus im

Rahmen der Erfindung an die Anschalt- und Steuereinrichtung anschaltbar ist, welcher Zykluszeiten im Mikrosekundenbereich besitzt .