gesponsertHerstellerunabhängige Automatisierung So geht Engineering nach IEC61499

Mit herstellerunabhängiger und softwarezentrierter Automatisierung lassen sich die Potenziale des IIoT deutlich besser nutzen. Aber wie funktioniert das konkret? Gerade in Sachen Engineering ist ein Umdenken gefragt.

In den vergangenen Jahren und Jahrzehnten hat sich die Automatisierungstechnik enorm weiterentwickelt. Selbst komplexe Tätigkeiten und Handgriffe können von Robotern ausgeführt werden und für die Planung, Überwachung und Analyse sämtlicher Prozesse stehen KI-gestützte Softwarelösungen bereit. Doch während sich einzelne Technologien rasant weiterentwickelt haben, hat sich in Sachen Automatisierungslogik wenig getan. Der grundsätzliche Modus, nach dem mechatronische Komponenten zwecks automatisierter Abläufe orchestriert werden, hat sich seit Erfindung der SPS in den 1960er Jahren kaum oder gar nicht verändert. Gleichzeitig sind über die Jahre unzählige proprietäre, sprich herstellereigene und nicht interoperable Steuerungssysteme entstanden, die eine volle Nutzung der heute dringend benötigen Industrie-4.0-Potenziale erheblich verkomplizieren. Die Grundidee des Industrial Internet of Things und das Vorhandensein geschlossener Systeme stehen sich diametral gegenüber. Kein Wunder also, dass die Forderungen nach einer herstellerunabhängigen und softwarezentrierten Automatisierung zuletzt immer lauter geworden sind. So haben sich etwa in der UniversalAutomation.Org verschiedene internationale Industrieunternehmen, Hersteller, OEMs, Systemintegratoren, Start-Ups und Universitäten zusammengetan, um eine auf IEC61499 basierende Runtime-Umgebung zur Verfügung zu stellen. Außerdem hat Tech-Konzern Schneider Electric bereits eine entsprechende Engineering-Lösung geschaffen.

Hardwareunabhängige Softwareumgebung und wiederverwendbare Objekte

Um die Umsetzung flexibler, leicht umrüstbarer und hochkomplexer Anlagen zu vereinfachen, wurde bereits im Jahr 2005 die IEC Norm 61499 definiert. Im Gegensatz zu IEC61131 ist die Steuerungslogik hier nicht allein Sache eines zentralen Controllers, sondern die für das gesamte Automatisierungsprojekt in einer hardwareunabhängigen Softwareumgebung erstellten Programmstrukturen lassen sich frei auf sämtliche mit einer CPU ausgestatteten Feldgeräte aufteilen. Gemäß IEC61499 wird dabei ein objektorientierter Automatisierungsansatz verfolgt, bei dem mit herstellerunabhängigen und für andere Projekte leicht wiederzuverwendenden Softwareobjekten gearbeitet wird. Diese Softwareobjekte, sogenannte Funktionsblöcke, bilden je nach Bedarf entweder einzelne Devices – zum Beispiel einen Motor – oder auch zusammenhängende Anwendungen – zum Beispiel eine ganze Abfüllanlage – mit ihren jeweiligen Aspekten ab. Zu diesen Aspekten gehören Steuerungslogik, Visualisierung, Ein- und Ausgänge, Test und Simulation, Dokumentation oder der Kommunikationspfad. Dass all diese Aspekte in einem Softwareobjekt gekapselt werden können, hat zur Folge, dass sich die Arbeitsschritte Programmierung und Engineering nun deutlicher voneinander unterscheiden und sich insbesondere das Engineering (für den Anwendungs- oder Projektingenieur) erheblich einfacher gestaltet.

Bildergalerie

Bildergalerie mit 5 Bildern

Engineering mit EcoStruxure Automation Expert

Gemäß IEC61499 wird die herstellerspezifische Bindung von Steuerungen und Programmierumgebungen aufgehoben. Stattdessen ist eine hardwareunabhängige Softwareebene vorgesehen, innerhalb der eine ganze Applikation (und nicht nur eine bestimmte Steuerung) völlig unabhängig von der später eingesetzten, realen Hardware modelliert werden kann. Hierzu sind auf IEC61499 zugeschnittene Engineering-Tools vonnöten, in denen sich auch komplexe Anwendungssequenzen mithilfe der einzelnen Funktionsblöcke rein grafisch zusammenfügen lassen. Ein solches Engineering-Tool ist zum Beispiel EcoStruxure Automation Expert von Schneider Electric. Dieses Tool ermöglicht nicht nur, dass vorgefertigte Funktionsblöcke aus herstellerunabhängigen Bibliotheken durch das grafische Ziehen von Linien (Single-Line-Engineering) zu komplexen Anwendungssequenzen zusammengefügt werden können, sondern stellt auch sicher, dass die Querkommunikation zwischen den mechatronischen Komponenten automatisch konfiguriert wird. Gerade, wenn es notwendig ist, einzelne Komponenten schnell auszutauschen oder Module neu anzuordnen, zahlt sich das in hohem Maße aus.

Eine weitere Vereinfachung für das Engineering ergibt sich durch die unkomplizierte Wiederverwendbarkeit der Softwareobjekte. Einmal erstellte Anwendungssequenzen können gespeichert und per Copy-and-Paste für ähnliche Projekte mit den Hardwarekomponenten anderer Hersteller genutzt werden. Anders als bei IEC61131 kommen in IEC61499 keine globalen Variablen zum Einsatz, die als implizite Schnittstelle zwischen den Funktionsblöcken fungieren und diese immer in Abhängigkeit zur Gesamtapplikation stellen würden. Objekte oder Funktionsblöcke in IEC61499 sind grundsätzlich hersteller- und verfahrensunabhängig konzipiert.

Verteilte Intelligenz und Eventorientierung

Sind alle benötigten Funktionsblöcke (bzw. Instanzen) innerhalb der Softwareumgebung korrekt zusammengeschaltet, geht es im Sinne von IEC 61499 an die Verteilung der erstellten Logik. So, wie es für die Umsetzung modularer und flexibler Anlagen angemessen ist, lassen sich die einzelnen Teile des Programmcodes völlig frei auf die jeweiligen, mit einer CPU ausgestatteten Hardwarekomponenten aufspielen. Das hat unter anderem zwei gewinnbringende Konsequenzen:

• 1. Erstens wird die Ausfallsicherheit gestärkt. Da nicht mehr alle Komponenten vom Abarbeitungsloop einer einzigen SPS abhängig sind, existiert kein Element mehr, dessen Ausfall die Abschaltung der gesamten Anlage zur Folge hätte. Fällt eine einzelne Komponente aus, kann der darauf installierte Programmteil schnell und unkompliziert auf ein neues Bauteil mit CPU aufgespielt werden.

• 2. Zweitens kommt das Konzept einer verteilten Intelligenz der für die Annäherung an IT-Systeme deutlich besser geeigneten eventbasierten Ausführungslogik entgegen. Diese ist – im Unterschied zur klassischen SPS-basierten zyklischen Ausführungslogik – explizit durch IEC 61499 vorgesehen und besagt, dass einzelne Anwendungen (etwa das Leeren eines Behälters) nicht mehr in Dauerschleife nach einem möglichen Abarbeitungsbefehl fragen, sondern solange inaktiv bleiben, bis der entsprechende Befehl sie triggert. Die CPU und Batterielast können damit erheblich gesenkt werden.

Die Vorteile eines herstellerunabhängigen und softwarezentrierten Automatisierungsansatz für das Engineering lassen sich bereits quantifizieren.

(ID:48425699)