Die SPS-Programmierung gilt zwar als etabliert und zuverlässig, allerdings aufgrund ihrer Struktur auch als antiquiert. Inwieweit lässt sie sich da überhaupt sinnvoll und praktikabel mit moderner Software verknüpfen?
Barth: Aus unserer Erfahrung ist eine sinnvolle und praktikable Verknüpfung von SPS-Programmierung und moderner Software durchaus möglich – vorausgesetzt, die jeweiligen Aufgabenbereiche der beiden Programmierwelten sind voneinander abgegrenzt und die Schnittstellen sind klar definiert. Die Stärken der SPS liegen vor allem in der Nachbildung von Schaltlogiken sowie in der Ansteuerung von Aktorik und der Auslesung von Sensoren – insbesondere bei Aufgaben mit Echtzeitanforderungen. Ein weiterer Vorteil ist die Verfügbarkeit bewährter, standardisierter Bibliotheken, wie die der PLCopen, auf diesen aufgebaut werden kann.
Sidorenko: Ein gutes Beispiel für die Synergie zwischen klassischer SPS-Software und modernen Programmiersprachen ist die skillbasierte Produktion, auf der unsere Demonstratorökosystem für flexible Fertigung basiert. In unseren Demonstratoren nutzen wir die SPS-Programmierung, um die Grundfunktionen einzelner Maschinenkomponenten zu realisieren. Dabei analysieren wir die Produktionsmaschine hinsichtlich ihrer elementaren, voneinander unabhängigen Fähigkeiten welche wir als Atomic Skills bezeichnen. Diese können beispielsweise das Befördern eines Bauteils innerhalb der Maschine, das Drehen einer Werkzeugkassette oder das Öffnen und Schließen eines Greifers sein.
Barth: Die so beschriebenen Maschinenfähigkeiten, die mittels SPS implementiert werden, lassen sich anschließend flexibel von moderner Software – z.B. in C++, Python oder Java – über OPC UA aufrufen, parametrisieren und ansteuern. Diese Herangehensweise eröffnet uns neue skalierbare Möglichkeiten, Maschinen flexibler anzusteuern, insbesondere im Hinblick auf die Konvergenz von OT- und IT-Welt.
Deckt IEC61131-3 diese Möglichkeiten überhaupt ab?
Sidorenko: Das Standardsoftwaremodell sowie die Sprachen der IEC61131-3 werden dafür kritisiert, dass sie den Anforderungen moderner Steuerungssoftware nicht gerecht werden. Jedoch hat die Aufnahme von objektorientierten (OOP) Funktionen in die dritte Ausgabe der Norm die Modularität und Struktur des SPS-Codes verbessert. Die OOP-Version der Strukturierten Textsprache (ST) bietet alle wichtigen Merkmale der modernen OO-Sprache, wie Klassen, Schnittstellen, Methoden und Eigenschaften. Einige Features, die in Hochsprachen üblich sind, werden aus gutem Grund nicht unterstützt, da sie die Echtzeit- und Sicherheitsanforderungen gefährden sowie die Effizienz behindern, die für die Entwicklung von Software für kritische Systeme unerlässlich sind.
Barth: Obwohl solche IEC61131-Sprachen wie AWL und KOP in der Tat antik erscheinen, bietet die FUP einige Vorteile für den Softwareentwurf. Ein komponentenbasierter Entwurf (CBD) ist ein beliebter Ansatz in der Softwareentwicklung, der darauf abzielt, die Modularität und Wiederverwendung von Software zu verbessern. Dabei wird eine Softwarekomponente als Black-Box betrachtet, die über vordefinierte Schnittstellen mit anderen Komponenten interagiert. Das übliche Muster von CBD besteht darin, die Funktionsblöcke auf der niedrigsten Abstraktionsebene an den Geräten auszurichten und sie dann zu zusammengesetzten Funktionsblöcken zu komponieren, die komplexere, aggregierte Komponenten darstellen, und so weiter. So entsteht eine natürliche Hierarchie, wie sie für Produktionsumgebungen typisch ist. Nach CBD können Steuerungsexptern den Low-Level-Code in ST oder C++ schreiben und als Bibliotheken von Funktionsblöcken bereitstellen, welche die Anwendungsingenieure dann in grafischen Entwicklungsumgebungen verwenden können. Dieser Ansatz verbessert die Trennung von Anliegen und Rollen bei der Softwareentwicklung, verkürzt die Gesamtentwicklungs- und Anlaufzeiten der Produktionslinien und verbessert die Wartung und Wiederverwendbarkeit der industriellen Steuerungssoftware.
Und wie sieht es mit der IEC61499 aus, die ja schon seit vielen Jahren die IEC61131-3 ablösen sollte.
Sidorenko: Die Norm IEC61499 sollte die Einschränkungen der IEC61131 überwinden. Sie konzentriert sich auf die Entwicklung von verteilter Automatisierungsintelligenz. Sie hat die Kapselung von Daten und Funktionen in den Funktionsblöcken erheblich verbessert und fortschrittliche verteilte Steuerungssysteme durch die Einführung eines ereignisbasierten Berechnungsmodells in die SPS-basierte Steuerung ermöglicht. Die IEC61499 folgt dem CBD. Die Steuerungsalgorithmen in den Funktionsbausteinen können nicht nur mit IEC61131-Sprachen, sondern auch mit den gängigen Hochsprachen implementiert werden. Das Netzwerk der Funktionsblöcke dient dabei der nahtlosen Integration von Softwarekomponenten, die in verschiedenen Sprachen geschrieben wurden, und gewährleistet die deterministische Ausführung der Steuerungsanwendung, die auf verschiedene Automatisierungsgeräte verteilt werden kann.
Barth: Die Norm ist in der Wissenschaft anerkannt, hat aber in der Industrie keine große Beachtung gefunden. Das liegt primär an ihrer Komplexität und den Unterschieden zur IEC61131, die damals bereits weit verbreitet war. Die Situation scheint sich in letzter Zeit zu ändern, da einige große Automatisierungsanbieter ihre kommerziellen Produkte auf der Grundlage der Norm IEC61499 entwickelt haben.
Inwieweit passen moderne Programmierkonzepte wie Container und Docker in die SPS-Welt?
Sidorenko: Ist die SPS-Programmierung bereit für eine moderne Programmierung mit Apps und Containern? Unserer Auffassung nach: Ja. Einige Automatisierungshersteller haben bereits gute Lösungen entwickelt, die zeigen, wie sich die Vernetzung einer klassischen SPS mit moderner Software verbessern lässt. Der zentrale Punkt ist dabei eine effiziente und performante Schnittstelle zur SPS bzw. eine Middleware, an die die SPS angebunden ist und die vor allem die Interoperabilität zu Domainfremder Software ermöglicht. Dadurch ist beispielsweise eine Maschinensteuerung um Funktionen erweiterbar, die mit der SPS eigenen Sprache nur schwer oder gar nicht umsetzbar wären.
Barth: Ein weiterer entscheidender Aspekt ist die Virtualisierung von Steuerungen in Form von Software-Containern. Diese trägt wesentlich zur Effizienz und Performance der Vernetzung zwischen verschiedenen Softwareeinheiten bei. In klassischen industriellen Steuerungssystemen ist eine Software meist an eine bestimmte Hardware gebunden. Daher erfolgt die Kommunikation zwischen Softwareinstanzen traditionell über das Netzwerk (Host-to-Host), da diese physisch voneinander getrennt sind.
Die zunehmende Virtualisierung von Automatisierungssoftware und die damit verbundene Entkopplung von Hardware leiten jedoch einen Paradigmenwechsel ein. Dieser ermöglicht es beispielsweise, eine SPS auf demselben Hostsystem zu betreiben wie eine Applikation in einer beliebigen Programmiersprache. Dadurch lässt sich eine effiziente Intra-Host-Kommunikation realisieren, die den bisher netzwerkbasierten Datenaustausch ersetzen kann. Dies wiederum eröffnet neue Ansätze, wie den Einsatz von Microservice-Konzepten in Kombination mit einer transparenten Middleware für Automatisierungssoftware.
Wie läuft das in der Praxis ab?
Sidorenko: In der Praxis setzen wir solche Steuerungsarchitekturen in unseren Demonstratoren ein, um verschiedene Softwaresysteme miteinander zu verknüpfen, von der Ansteuerung eines IO-Link-Greifers über Python bis hin zur Synchronisation eines Roboters mit einer Linearachse. In letzterem Fall haben wir eine C++-Applikation entwickelt, die über die herstellerspezifische App2App-Middleware die Position der Linearachse in Echtzeit aus dem Ethercat-Master ausliest und diese über ROS2 zur Verfügung stellt. Diese Applikation wurde dann auf dem Antriebsregler deployt, auf dem gleichzeitig die virtuelle SPS betrieben wurde.
Darüber hinaus ermöglicht dieses Konzept die Auslagerung von Steuerungslogik in beliebige Programmiersprachen. Dies lässt sich beispielsweise gut mit dem Skill-Konzept (Maschinenfähigkeiten) kombinieren. Man unterscheidet dabei zwischen Atomic Skills und Composite Skills:
- Atomic Skills sind grundlegende Funktionen, wie z. B. das lineare Bewegen eines Roboters oder das Öffnen und Schließen eines Greifers.
- Composite Skills setzen mehrere Atomic Skills zu einer höherwertigen Fähigkeit zusammen – beispielsweise eine Pick&Place-Funktion, die Bewegung und Greifvorgang kombiniert.
Barth: Übertragen auf eine Produktionsmaschine bedeutet dies, dass deren Fähigkeiten über ein einheitliches Informationsmodell auf einem OPC UA-Server bereitgestellt werden. Dadurch ist es möglich die Maschine flexibel von einem Drittsystem, beispielsweise einem MES, je nach Auftragseingang anzusteuern.
Das Anbieten atomarer Skills über einen OPC UA-Server ist jedoch aufgrund von Performance-Einschränkungen oft nicht sinnvoll, da die einzelnen Funktionsaufrufe zu hohen Latenzen führen können. Anders verhält es sich bei einer performanten Intra-Host-Middleware, die eine schnelle Kommunikation innerhalb eines Systems ermöglicht. Eine SPS könnte dabei atomare Funktionalitäten einer Maschine bereitstellen, wie MoveLinearAxis oder MoveLinearAxisToWaypoint. Diese lassen sich flexibel von einem externen Programm, z.B. in Python, kombinieren oder um zusätzliche Funktionen erweitern, etwa durch die Interaktion mit IT-Systemen.
Der Vorteil dieses Ansatzes liegt in der klaren Trennung der Logikebenen:
- Die SPS-Sprache bleibt auf jene Logik beschränkt, für die sie optimiert ist – wie die digitale Umsetzung von Verschaltungslogiken. Hochsprachen wie Python eignen sich hingegen für „High-Level“-Logiken, etwa die flexible Koordination von Maschinenfunktionen auf Basis komplexerer Entscheidungskriterien und Informationsquellen.
