Bild 1. Single-Core mit Basiszeit 200 µs und Echtzeit-Limit 90 %.

© Beckhoff Automation

Bild 1 zeigt beispielhaft die Ablaufreihenfolge der Tasks einer typischen Motion-Control-Anwendung mit SPS und C++-Anteil. Der Echtzeit-Anteil ist auf 90 % der Basiszeit – hier 200 µs – begrenzt, so dass Windows (OS) immer mindestens 10 % der Rechenkapazität zugeordnet wird. Damit ist das Windows-Betriebssystem innerhalb einer Basiszeit stets für eine minimale garantierte Zeit aktiv. Motion Control (Twincat NC PTP) ist aufgeteilt in SAF-Task (Satz-Ausführungs-Task) mit einer Zykluszeit von 200 µs und einer Rechenzeit von 30 µs und die SVB-Task (Satz-Vorbereitungs-Task) mit einer Zykluszeit von 400 µs und einer Rechenzeit von 100 µs. C++- und SPS-Task werden jeweils mit 200 µs ausgeführt und benötigen eine Rechenzeit von 40 beziehungsweise 60 µs.

Zum Einhalten der Zykluszeit muss die notwendige Rechenzeit kleiner sein als die geforderte Zykluszeit, was in diesem Beispiel der Fall ist. Die Tasks werden hier entsprechend der Prioritäten 1, 2, 3 und 4 in der gezeigten Reihenfolge SAF, C++, SPS und SVB ausgeführt. Alle Tasks werden zum Zeitpunkt 0 µs aktiviert und der Twincat-Echtzeit-Scheduler arbeitet diese anhand der Prioritäten der Reihenfolge nach ab. Die Tasks SAF, SPS und C++ haben eine Zykluszeit von 200 µs und werden daher zum Zeitpunkt 400 µs erneut aktiviert. Zu diesem Zeitpunkt ist die SVB-Task noch nicht vollständig abgearbeitet.

Bild 2. Multi-Core mit Basiszeit 200 µs und Echtzeit-Limit 90 %.

© Beckhoff Automation

Die Tasks mit den kürzeren Zykluszeiten erhalten hier Vorrang, indem diesen die Prioritäten 1 bis 3 zugeordnet wurden und somit gegenüber der Priorität 4 der SVB-Task den Vorzug erhalten. Nur so ist sichergestellt, dass sie wie im vorherigen Zyklus ihre Zykluszeit einhalten und nicht durch die SVB ‚aufge­halten‘ werden. Die Abarbeitung der SVB-Task wird anschließend fortgesetzt. Sollte eine Task wiederholt ihre Aktivierung verpassen, kommt es zur Zykluszeit-Überschreitung (Exceed). Eine Task, die eine Überschreitung meldet, muss jedoch nicht zwingen­derweise dafür verantwortlich sein. In diesem Fall sollte immer ein Blick auf die Task-Laufzeiten der höher priorisierten Tasks auf dem Kern geworfen werden.

Bei diesem Beispiel ist die Rechen­kapazität des Industrie-PC vollständig ausgenutzt. Um die Anwendung zu erweitern, bietet sich eine Verteilung auf zwei Kerne an. Bild 2 zeigt eine mögliche Aufteilung. Bei dieser Konfiguration werden alle Tasks mit Ausnahme der SPS-Task einem separaten Kern zugeordnet. Man beachte, dass in der Single-Core-Konfiguration die SPS-Task nach der SAF und C++ zur Ausführung kommt. Da jeder Kern die Ablaufreihenfolge lokal für die ihm zugeordneten Tasks berechnet, startet die SPS hier pa­rallel mit der SAF-Task auf dem zweiten Kern. Durch die zusätzliche Rechenleistung wird die SVB-Task innerhalb des ersten Zyklus berechnet, und es ist weitere Rechenzeit für zusätzliche Aufgaben auf beiden Kernen vorhanden. Diese lässt sich entweder für eine Erweiterung der bisherigen Anwendung nutzen oder für weitere Module.

Bild 3. Multi-Core mit Basiszeit 100 µs, Echtzeit-Limit 80 % und Core-Isolation.

© Beckhoff Automation

Die Rechenleistung kann alternativ zur Erhöhung der Abtastrate der vorhandenen Anwendung dienen. Dazu ist die Zykluszeit einer oder mehrerer Tasks abzusenken. Ein solches Beispiel ist in Bild 3 dargestellt. Hier wird auf beiden Kernen die Basiszeit auf 100 µs halbiert und der zweite Kern wird zusätzlich isoliert. Letzteres ist am Fehlen des ‚OS‘-Anteils in der Ablaufreihenfolge zu erkennen. Auf dem ersten Kern bleibt die Länge einer einzelnen Windows-Zeit absolut unverändert bei 20 µs, das heißt das Echtzeit-Limit liegt hier bei 80 %. Dadurch steht Windows 20 % der Rechenleistung des ersten Kerns zur Verfügung. Die Zykluszeiten der SAF-, C++- und SPS-Task werden auf 100 µs gesenkt. Dadurch verdoppelt sich deren Abtastrate. Zwar kommt es hier zu einer häufigeren Unterbrechung der SVB-Task; dennoch werden alle Tasks vor ihrer nächsten Aktivierung durchgerechnet. Bei einem solchen Vorgehen muss die verfügbare Bandbreite auf dem angeschlossenen Feldbus allerdings ausreichend dimensioniert sein, denn es verdoppelt sich die Anzahl der Feldbus-Telegramme pro Zeiteinheit und damit erhöht sich die Gesamtauslastung des Feldbusses.

Eine Aufteilung auf mehrere Kerne ist zum Beispiel dann sinnvoll, wenn es viele rechenintensive Instanzen eines Modules gibt, die sich unabhängig voneinander berechnen lassen. Eine solche Anwendung wäre das Condition Monitoring. Prinzipiell muss nicht – wie im obigen Beispiel – jedem Modul eine eigene Task zugewiesen werden. Abhängig vom Rechenbedarf eines einzelnen Moduls lassen sich mehrere Module auch einer Task zuweisen. ­Dabei darf die entstehende Task-Laufzeit nicht die geforderte Zykluszeit eines Moduls überschreiten. Anderenfalls sind weitere Module einer zusätzlichen Task zuzuweisen und auf einem separaten Kern auszuführen. Das Verhalten ist stark von der jeweiligen Anwendung abhängig. Insofern empfiehlt sich hier eine schrittweise Inbetriebnahme. Sind Module mit unterschiedlichen Zykluszeiten abzuarbeiten, sollten sie immer getrennten Tasks mit passender Konfiguration zugewiesen werden.

Zusammenfassend lässt sich festhalten: Der Zugewinn an Rechenleistung durch eine höhere Anzahl an Kernen pro Prozessor anstelle einer signifikanten Steigerung des Prozessortaktes kann zur Migration bestehender Anlagen mit mehreren Industrie-PCs auf einen einzelnen genutzt werden, aber ebenso zur Erweiterung und Erhöhung der Regelgüte eines einzelnen Industrie-PC selbst. Nicht zuletzt lassen sich auf diese Weise bestehende Anlagen mit komplexen messtechnischen Anwendungen oder Bildverarbeitung ergänzen und damit letztlich besser überwachen oder auch während der Laufzeit optimieren.

Autor: Dr. Henning Zabel arbeitet im Bereich Software-Entwicklung Echtzeit bei Beckhoff.