Parallelverarbeitung mit Transfer Tray

Der folgende Abschnitt behandelt die thread-sichere und mehrkernfähige Datenübermittlung, welche die TwinCAT 3 Condition Monitoring Library bietet.

Asynchrone Kommunikation und parallele Ausführung rechenintensiver Schritte

Condition-Monitoring-Anwendungen erfordern häufig mehrere Megabyte große Datensätze, welche die Anforderungen an Rechenzeit und Rechenleistung erhöhen. Die maximal zulässige Rechenzeit orientiert sich an der Zykluszeit, die bspw. für Antriebssteuerungen niemals überschritten werden darf. Aufgrund dessen werden im Falle von rechenintensiven Algorithmen Multitask-Software-Architekturen für TwinCAT 3 Condition-Monitoring-Anwendungen empfohlen. Siehe Kapitel “Task Einstellungen“.

Idee des Transfer Tray

Hierzu sind thread-sichere Implementierungen der Algorithmen erforderlich. Die TwinCAT 3 Condition Monitoring Library bietet einen sehr effizienten und einfach zu verwendenden Kommunikationsmechanismus, der die typischen Probleme mit Sperren und Entsperren von Daten so weit wie möglich beseitigt. Die Bibliothek bietet einen sehr effizienten Mechanismus zur Parallelverarbeitung von Daten z.B. mit unterschiedlichen Datenraten. Damit können Array-Daten fehlerfrei zwischen mehreren Tasks für exklusiven synchronisierten Zugriff übermittelt werden - unter Verwendung von Warteschlangen (queues) mittels des Transfer Tray. Dies ermöglicht auch die Verwendung von Mehrkern-CPUs ohne Synchronisationsprobleme und verhindert schwer zu diagnostizierende Fehler wie Blockaden und Inkonsistenzen, die von nicht synchronisierten Überschreibungen numerischer Daten verursacht werden.

Die Bibliotheksfunktionsbausteine dürfen nicht als globale Instanzen in der Liste der globalen Variablen deklariert werden, weil paralleler Schreibzugriff auf MultiArray Puffer (vgl. Abschnitt Umgang mit MultiArray) und die parallele Ausführung der gleichen Funktionsbausteine ausdrücklich verboten sind.

Beispiel für die Notwendigkeit von Zykluszeit-Transitionen

Unter manchen Umständen ist ein sequentielles Konzept nicht ausreichend. Das ist immer dann der Fall, wenn die Verarbeitung eines Datensatzes mehr Zeit in Anspruch nimmt, als die Zykluszeit einer Steuerungstask zulässt.

Die Steuerungstask hat z.B. eine Zykluszeit von 1 Millisekunde und ein Oversampling von Daten von 20 Abtastungen pro Zyklus (entspricht einer Abtastrate von 20 kHz). Es wird für die Signalverarbeitung eine Frequenzauflösung von 0,16 Hz gefordert, was z.B. für die Analyse von großen Rollenlagern erforderlich sein könnte, damit zwischen Mängeln am Innen- und Außenlaufring, die mit nur geringfügig verschiedenen Geschwindigkeiten laufen, unterschieden werden kann.

Die Beziehung zwischen FFT-Länge N, Frequenzauflösung Δf und Abtastrate f_s ist: N = f_s / Δf (zur Vereinfachung sei hier ein Rechteckfenster angenommen). Es ergibt sich eine FFT-Länge von
N = 125000. Darüber hinaus muss die FFT-Länge N' eine Potenz von zwei sein, daraus folgt mit log₂(125000) = 16.93, dass das Signal der Länge N auf N' = 2¹⁷ = 131072 mit Nullen aufgefüllt wird.

Die erforderliche Rechenzeit hängt von der Leistung der CPU ab, aber die Berechnung in der Steuerungstask ist definitiv nicht möglich. Die erforderliche Eingangsdatenmenge entspricht einem Signalabschnitt von mehreren Sekunden, so dass die Berechnung infolgedessen nur selten durchzuführen ist.

Lösungskonzept mit dem Transfer Tray

Die von der Condition Monitoring Library bereitgestellte hochleistungsfähige Lösung wird in untenstehender Abbildung gezeigt. Die Steuerungstask (Control Task) sammelt Daten in "Paketen“ von 20 Samples über die Oversampling-Klemme (in Abbildung blau dargestellt). Diese werden in einen Puffer gespeichert, dessen Größe der Länge des Eingangspuffers des Magnituden Spektrum Funktionsbausteins entspricht (125000 / 20 = 6250, in Abbildung grün dargestellt). Sobald der Puffer gefüllt ist, also nach 3125 Zyklen der Steuerungstask, wird dieser, genauer gesagt, dessen Objektreferenz, mit Hilfe eines asynchronen Kommunikationsmechanismus an eine zweite Task (Processing Task) übergeben (FIFO Prinzip), die mit 20 Millisekunden eine viel größere Zykluszeit aufweist. Nach der in Task Einstellung beschriebenen Daumenregel ist eine Zykluszeit für die berechnende Task von maximal 1562,5 ms zulässig. Mit den 20 ms wird diese Forderung deutlich erfüllt.

Dieser Kommunikationsmechanismus garantiert mit Hilfe von hardware-gesicherten, sogenannten atomaren Operationen, dass nur eine der Tasks Zugriff auf den entsprechenden Puffer (im folgenden auch MultiArray gennant) zur gleichen Zeit hat. Dies ist vergleichbar mit einer Übergabeschublade (transfer tray) am Bankschalter, die sicherstellt, dass entweder der Kunde oder der Kassierer auf deren Inhalt zugreifen kann.

Reaktionslatenz Für die Warteschlangen gilt das Prinzip des FIFO. Deswegen und wegen der asynchronen Kommunikation ist das Ergebnis nicht sofort verfügbar. Reaktionen mit variabler Latenz sind möglich.

Das Rechenergebnis (das Magnituden Spektrum) wird über eine weitere Warteschlange mit dem gleichen Kommunikationsmechanismus an die Steuerungstask zurückgegeben, die dieses dann weiter auswerten kann, natürlich ist auch die Kommunikation an eine andere dritte Task sowie die Bereitstellung des Ergebnisses in der berechnenden Task selbst möglich.

Im Allgemeinen sind der berechnenden Task, im Vergleich zu Motion-Anwendungen, keine harten Echtzeit-Bedingungen auferlegt und sie kann demzufolge mit einer geringeren Priorität ausgeführt werden, als die Steuerungstask. Das Taskmanagement des TwinCAT 3 Systems sorgt dafür, dass die Task mit der höchsten Priorität immer zuerst ausgeführt wird, so dass diese echtzeitlichen Bedingungen selbst mit komplexen Berechnungen erfüllt werden können.

Das vorgestellte Konzept kann sowohl auf Einkern-, als auch auf Mehrkern-CPUs verwendet werden. Die Verteilung auf vielen Kernen, ohne die zentralen Sperren, die Engpässe verursachen, ist möglich.

Timeout Die internen Kommunikationsbefehle zum Transfer Tray können in seltenen Fällen fehlschlagen, z.B. in Abhängigkeit der Eigenschaften der Hardware. Es befindet sich z.B. ein leerer Puffer in der Warteschlange, der trotzdem nicht herausgenommen werden kann, weil eine andere Task gerade auf ihn zugreift. Ein synchrones Timeout ist spezifiziert und es kann infolge ein Timeout-Fehler auftreten. Das Programm muss also stets auf den möglichen Fehlerzustand, dass ein für die Stetigkeit der Signaldaten erforderlicher Puffer nicht verfügbar ist, gefasst sein. Folgefehler wie Datenüberlauf und Diskontinuitäten von analysierten Zeitserien müssen auf konsistente Weise aufgearbeitet werden. So lange die Eingangssignaldaten einer Analysekette fehlerfrei gesammelt werden können, treten keine Diskontinuitäten auf. Wenn ein einzelnes Timeout bei einem folgenden Algorithmenbaustein auftrat oder für den folgenden Algorithmenbaustein kein Ergebnis-MultiArray-Puffer verfügbar war, gehen weder Eingangsdaten noch Ergebnisdaten verloren. Sie werden beim nächsten Aufruf übergeben.

Funktionsweise des Transfer Tray

Der Transfer Tray selber wird mit Hilfe eines von der Tc3_CM Bibliothek bereitgestellten internen Funktionsbausteins dargestellt. Dieser Baustein wird mit Anfangsparametern initialisiert, die in der globalen Strukturinstanz definiert sind.

Die typische Verwendung von Warteschlangen geschieht so, dass Puffer von genau einer Task der Warteschlange mit einer festen Datenstromkennung hinzugefügt werden und dass diese Puffer im Gegenzug von einer bestimmten anderen Task zwecks Verarbeitung entfernt werden. Diese Puffer werden dann über eine weitere Warteschlange mit einer anderen Datenflusskennung zurückgeschickt und erneut verwendet. Allerdings stellt es auch kein Problem dar, wenn mehrere Tasks Lese- oder Schreibzugriff auf die gleichen Warteschlangen haben, wenn z.B. statistische Daten analysiert werden.

Die MultiArray Puffer

Um Daten über das Transfer Tray von einer Task zur nächsten zu kommunizieren werden sogenannte MultiArray Puffer verwendet. Diese werden im Kapitel "Umgang mit MultiArray" erläutert.