Multitask-Datenzugriffs-Synchronisation in der SPS

Wenn von mehreren Tasks auf dieselben Daten zugegriffen wird, kann es je nach Task‑/Echtzeitkonfiguration vorkommen, dass die Tasks gleichzeitig auf dieselben Daten zugreifen. Wenn die Daten dabei von mindestens einer der Tasks geschrieben werden, können die Daten während oder nach einer Änderung einen inkonsistenten Zustand haben. Um dies zu verhindern, müssen alle konkurrierenden Zugriffe synchronisiert werden, sodass zu einem Zeitpunkt nur von höchstens einer Task auf die gemeinsam genutzten Daten zugegriffen werden kann.

Zu diesen konkurrierenden Zugriffen aus mehreren Tasks, bei denen eine Synchronisation nötig ist, gehören beispielsweise die folgenden Fälle:

Kurz: Wenn von mehreren Tasks auf dieselben Daten zugegriffen wird und bei mindestens einem dieser Zugriffe die Daten geschrieben werden, müssen alle lesenden und schreibenden Zugriffe synchronisiert werden. Dies gilt unabhängig davon, ob die Tasks auf einem oder mehreren CPU-Kernen laufen.

WARNUNG

Verletzungsgefahr durch unvorhersehbare Achsbewegungen

Werden konkurrierende Zugriffe nicht synchronisiert, so besteht die Gefahr eines inkonsistenten oder ungültigen Datensatzes. Je nachdem wie die Daten im weiteren Programmverlauf genutzt werden, kann dies ein Fehlverhalten des Programms, eine ungewünschte Achsbewegung oder auch den plötzlichen Programmstillstand zur Folge haben. Abhängig von der gesteuerten Anlage können Schäden an Anlage und Werkstücken entstehen oder Gesundheit und Leben von Personen gefährdet werden.

  • Synchronisieren Sie konkurrierende Zugriffe.
  • Sie finden bei den Beispielprogrammen zu den MUTEX-Verfahren jeweils Funktionstests mit entsprechender Erläuterung, durch die Sie ein Gefühl für die Notwendigkeit der Zugriffs-Synchronisation erhalten.

Synchronisationsmöglichkeiten

Zur Synchronisation der Zugriffe stehen u. a. die folgenden Möglichkeiten zur Verfügung:

1) Mutex-Verfahren (TestAndSet, FB_IecCriticalSection) zum Absichern von kritischen Bereichen

  • Halten Sie die Anzahl der kritischen Bereiche immer möglichst klein.
  • Halten Sie die Länge der kritischen Bereiche kurz.
  • Verwenden Sie bei vergleichsweise kurzen kritischen Bereichen FB_IecCriticalSection.
  • Verwenden Sie bei vergleichsweise langen kritischen Bereichen TestAndSet.

2) Austausch von Daten über das SPS-Prozessabbild

  • Diese Variante ist nur möglich und empfiehlt sich, wenn nur von einer Task schreibend auf dieselben Daten zugegriffen wird.
  • Aufgrund von notwendigen internen Kopieraktionen ist die mögliche Datenmenge eingeschränkt.

3) Austausch von Daten über synchronisierte Puffer

  • Diese Variante ist nur möglich, wenn nur von einer Task schreibend auf dieselben Daten zugegriffen wird.
  • Hierbei handelt es sich um eine anwendereigene Implementierung, für die es unterschiedliche Möglichkeiten gibt.
  • Der Zugriff auf die einzelnen Puffer muss, beispielsweise mit TestAndSet(), abgesichert werden.
  • Aufgrund von durchgeführten Kopieraktionen ist die mögliche Datenmenge eingeschränkt.

Synchronisation auch bei atomarem Zugriff

Die Notwendigkeit zur Synchronisation gilt normalerweise selbst dann, wenn ein einzelner Zugriff auf eine Variable (z. B. Integer schreiben) als atomar, d. h. ununterbrechbar, bezeichnet werden könnte.

Weil die Eigenschaft des atomaren Zugriffs u. a. von der eingesetzten Prozessorarchitektur abhängig ist, sollte der Einfachheit halber sowie insbesondere zur Sicherheit jeder Zugriff als nicht-atomar betrachtet werden.

Beachten Sie, dass sich selbst vermeintlich sichere Zugriffe bei näherer Betrachtung fast immer als unsicher herausstellen. Dies wird im Folgenden mithilfe von zwei Szenarien exemplarisch dargestellt:

Weitere Informationen

Weiterführende Informationen