Um die Komplexität heutiger Maschinen zu beherrschen und gleichzeitig die notwendigen Engineering-Aufwendungen zu reduzieren, haben viele Maschinenbauer begonnen, ihre Anlagen zu modularisieren. Einzelne Funktionalitäten, Aggregate oder Maschineneinheiten werden dabei als möglichst eigenständige Module betrachtet, die dann über einheitliche Schnittstellen in das Gesamtsystem eingebettet werden.

Im Idealfall ist eine Maschine dann hierarchisch aufgebaut, wobei die untersten Module einfachste, generell wieder verwendbare Basis-Elemente darstellen. Zusammengefügt bilden sie immer komplexere Einheiten, bis schließlich auf der obersten Ebene die gesamte Maschine entsteht.

Bei der steuerungstechnischen Umsetzung der Maschinen-Modularisierung lassen sich grob zwei unterschiedliche Ansätze unterscheiden - der zentrale und der dezentrale. Beim dezentralen Ansatz erhält jedes Maschinenmodul eine eigene Steuerung, die die SPS- und eventuell auch die Motion-Funktionalität des Moduls bestimmt.

Die modulare Steuerungsarchitektur vereint die Vorteile aus dem zentralen und dezentralen Ansatz: Softwaremodule ersetzen dezentrale Hardware und strukturieren die Automatisierungsaufgabe.

© Beckhoff

Die einzelnen Module können autark voneinander in Betrieb genommen, gewartet und relativ unabhängig skaliert werden. Die notwendigen Interaktionen zwischen den Steuerungen werden über Kommunikationsnetzwerke (Feldbusse oder Ethernet) koordiniert und über entsprechende Profile standardisiert. Demgegenüber zieht der zentrale Ansatz die Steuerungsfunktionen aller Module in der gemeinsamen Steuerung zusammen und nutzt nur sehr geringe vorverarbeitende Intelligenz in den dezentralen I/O-Geräten.

Die Interaktionen können viel direkter innerhalb der zentralen Steuerung erfolgen; dadurch werden die Kommunikationswege deutlich kürzer, Totzeiten entfallen und die gemeinsame Nutzung der Steuerungshardware senkt die Gesamtkosten. Der zentrale Weg hat jedoch den Nachteil, dass die notwendige Modularisierung der Steuerungssoftware nicht automatisch vorgegeben wird. Die Möglichkeit, in der zentralen Steuerung auf jede beliebige Information aus anderen Teilen des Programms zugreifen zu können, behindert gleichzeitig die Modulbildung und die Wiederverwendbarkeit dieser Steuerungssoftware in anderen Applikationen.

Da kein Kommunikationskanal zwischen den Steuerungseinheiten vorhanden ist, bleibt auch eine entsprechende Profilbildung und Standardisierung der Steuerungseinheiten häufig auf der Strecke.

Von beiden das Beste

Ergo nimmt die „optimale" Steuerung für modulare Maschinen Anleihen sowohl von der dezentralen als auch von der zentralen Steuerungsarchitektur. Für letztere sprechen insbesondere die geringeren Gesamtkosten und die Möglichkeit, ohne Kommunikationsverluste auf alle Informationen des Gesamtsystems zugreifen zu können. Als Steuerungshardware kommt hierbei idealerweise eine zentrale, leistungsfähige und möglichst allgemeine Rechner-Plattform zum Tragen.

Die bereits angerissenen Vorteile des dezentralen Ansatzes lassen sich durch entsprechende Modularisierung der Steuerungssoftware auch in der Zentrale verwirklichen. Statt ein großes, komplexes SPS-Programm und eine NC mit vielen Achsen laufen zu lassen, können viele kleine „Steuerungen" in einer gemeinsamen Runtime auf derselben Hardware relativ unabhängig voneinander koexistieren. Die einzelnen Steuerungsmodule werden hierbei gekapselt und bieten über standardisierte Schnittstellen ihre Funktionen nach außen an oder nutzen entsprechende Funktionen anderer Module beziehungsweise der Runtime.

Eine sinnvolle Profilbildung erfolgt durch Festlegung dieser Schnittstellen und Standardisierung der entsprechenden Parameter und Prozessdaten. Da die Ausführung der einzelnen Module innerhalb einer Runtime erfolgt, sind auch direkte Aufrufe in andere Module möglich - wiederum über entsprechende standardisierte Schnittstellen. Die Modularisierung kann somit innerhalb sinnvoller Grenzen frei erfolgen, ohne Rücksicht auf Kommunikationsverluste nehmen zu müssen.

Während der Entwicklung oder Inbetriebnahme einzelner Maschinenmodule lassen sich auf diese Weise die dazugehörigen Steuerungsmodule auf einer beliebigen Steuerungshardware mit entsprechender Runtime erstellen und testen; zudem besteht in dieser Phase die Möglichkeit, fehlende Anbindungen zu anderen Modulen zu emulieren.

An der kompletten Maschine werden sie dann gemeinsam auf der zentralen Runtime instanziiert. Diese Laufzeitumgebung muss nur so dimensioniert sein, dass sie die Anforderungen aller instanziierten Module hinsichtlich Speicher, Tasks und Rechenleistung erfüllt.

Modularisierung à la Twincat

Was bedeutet dies nun konkret auf Twincat 3 herunter gebrochen? Ein Twincat- Modul besteht aus einer Reihe von formal definierten Eigenschaften, die teilweise vorgeschrieben und teilweise optional sind. Die Eigenschaften sind insoweit formalisiert, dass eine allgemeine Nutzung sowohl untereinander als auch von außen möglich ist. Für die Konfiguration der Module und deren Beziehungen untereinander bringt jedes Modul eine Modulbeschreibungsdatei im XML-Format mit.

Wird ein Modul in der Twincat-Runtime instanziiert, dann meldet es sich bei einer zentralen System-Instanz - dem Modul- Manager - an. Dadurch wird es für andere Module und auch für allgemeine Tools erreichbar und parametrierbar. Die Module lassen sich unabhängig voneinander compilieren und daher ebenfalls unabhängig voneinander entwickeln, testen und pflegen.

Beispiel für ein allgemeines Twincat- Modul mit seinen wesentlichen Eigenschaften: Die roten Blöcke definieren die vorgeschriebenen, die blauen Blöcke die optionalen Eigenschaften.

© Beckhoff

Sie können sehr einfach aufgebaut sein und nur eine kleine Funktion wie etwa einen Tiefpassfilter enthalten; intern können sie aber auch sehr komplex sein und zum Beispiel die komplette Steuerung eines Maschinenaggregates beinhalten.

Da sich sämtliche Aufgaben eines Automatisierungssystems in Module verpacken lassen, findet dabei keine Unterscheidung statt, ob die Module primär Basisfunktionalitäten eines Automatisierungssystems darstellen (Echtzeit-Tasks/Feldbus-Treiber/SPSLaufzeitsystem) oder eher anwender- und applikationsspezifische Algorithmen zur Steuerung oder Regelung eines Maschinenaggregats. Neben einer Modulbeschreibung, die für die Konfiguration der Module untereinander wichtig ist, besitzt jedes Modul eine allgemeine State-Machine, über die die Initialisierung, Parametrierung und Verlinkung der Module gesteuert wird.

Das vorgeschriebene Interface „ITCom- Object" regelt den Zugriff auf die State- Machine und die Parameter der Module. Die eigentliche Funktion des Moduls wird über weitere Interfaces genutzt. Hierfür existieren bereits vordefinierte Interfaces, die allgemeine Funktionen beschreiben - zum Beispiel den zyklischen Aufruf der internen Modul-Logik. Weitere standardisierte, aber auch applikationsspezifische Interfaces lassen sich hinzufügen und über Interface-Pointer ist darüber hinaus der Zugriff auf Interfaces anderer Module möglich.

Die „Data-Areas" beschreiben Datenbereiche, die ein Modul für andere Module zur Verfügung stellt. Hierdurch können Module auf standardisiertem Wege über die Data-Area-Pointer effizient auf gemeinsame Daten zugreifen.

Modul-Erstellung wahlweise in C++ oder IEC 61131-3

Die Twincat-Runtime stellt eine Reihe so genannter System-Module zur Verfügung, die ihrerseits Basisdienste der Laufzeitumgebung für andere Module bereitstellen. Diese System-Module besitzen eine feste, konstante Object-ID und sind dadurch von anderen Modulen erreichbar. Ein Beispiel für ein System-Modul ist das Echtzeit-System, welches über sein ITcRTime-Interface die Basisdienste des Echtzeit-Systems zur Verfügung stellt - etwa das Erzeugen von Echtzeit-Tasks.

Der ADS-Router (Automation Device Specification - allgemeines Kommunikationssystem in Twincat) ist ebenfalls als System-Modul implementiert, sodass andere Module ihren ADS-Port dort anmelden können. Die Erstellung von Modulen kann sowohl in C++ als auch in IEC 61131-3 erfolgen. Dazu werden die objektorientierten Erweiterungen der integrierten SPS genutzt. Module aus beiden Welten können über Interfaces genauso interagieren, wie reine C++-Module untereinander. Auch die SPS-Module melden sich beim Modul-Manager an und sind darüber entsprechend erreichbar.

Die Komplexität der Module ist bei den SPS-Modulen variabel: Ob nur ein kleines Filter-Modul erzeugt wird oder ein komplettes SPS-Programm in ein Modul verpackt wird, ist unerheblich. In Twincat 3 ist sogar jedes SPS-Programm per Automatismus ein Modul im Sinne der Twincat-Module. Jedes klassische SPS-Programm wird automatisch in ein Modul verpackt und meldet sich beim Modul-Manager sowie bei einem oder mehreren Task-Modulen an. Der Zugriff auf die Prozessdaten eines SPS-Moduls - zum Beispiel das Mappen zu einem Feldbus- Treiber - wird ebenfalls über die definierten Data-Areas geregelt.

Für den SPS-Programmierer bleibt dieses Verhalten solange unsichtbar, bis er sich entschließt, explizit Teile des SPSProgramms als Twincat-Module zu definieren, um sie entsprechend flexibel einsetzen zu können.

Die Laufzeitumgebung

Bei der Twincat-3-Runtime - auch eXtended Automation Runtime (XAR) genannt - kommt die bewährte Twincat-Echtzeit- Erweiterung für Microsoft-Betriebssysteme zur Anwendung, welche eine Bearbeitung der Tasks mit einer minimalen Zykluszeit von 50 μs und sehr kleinem Jitter erlaubt. Erweitert wurde die Echtzeit um die Möglichkeit, bestimmte Tasks auf unterschiedlichen Kernen einer Multicore- CPU auszulagern. Dabei ist das Zeitverhalten für jeden Kern separat einstellbar. Damit lässt sich die Performance der PC-Steuerung deutlich steigern.

Die neue Runtime bietet eine Software- Umgebung, in der Module geladen, ausgeführt und verwaltet werden. Zusätzlich stehen hier Basisfunktionen zur Verfügung, um Ressourcen des Systems nutzen zu können (Speicher, Tasks, Feldbus- und Hardware-Zugriffe etc.). Die einzelnen Module müssen nicht in einem Compilier-Zusammenhang stehen, können daher unabhängig voneinander sein und zudem von unterschiedlichen Herstellern stammen. Eine Reihe von System-Modulen wird beim Start der Runtime automatisch geladen, sodass deren Eigenschaften anderen Modulen zur Verfügung stehen.

Die Twincat-3-Runtime bildet die Laufzeitumgebung unterschiedlicher Module: Echtzeit, Multicore-Unterstützung, Debugging-Schnittstelle und Hardware-Anbindung für die moderne Automatisierungstechnik.

© Beckhoff

Der Zugriff auf Eigenschaften der System-Module findet aber auf die gleiche Weise statt, wie auf Eigenschaften normaler Module. Für die Module ist es somit unwichtig, ob die jeweilige Eigenschaft von einem System- Modul oder einem normalen Modul bereitgestellt wird. Selbst die Entwicklung von Twincat 3 intern erfolgte in Form von Modulen. Eigenschaften wie Feldbus-Treiber oder Motion-Funktionen wurden nach den gleichen Regeln und Konventionen erstellt, wie sie für eher anwendungsorientierte Module gelten. Neue Funktionen, Algorithmen sowie die Unterstützung weiterer Kommunikationsprotokolle lassen sich damit leicht anbinden.

Die Unterstützung eigener Hardware (Feldbus-Karte, Frame- Grabber etc.) ist über entsprechende Treibermodule realisierbar und steht gleichberechtigt mit den in Twincat 3 vorhandenen Treibern zur Verfügung. Zusammenfassend kann festgehalten werden: Durch die Interaktion der Steuerungsmodule gemeinsam auf einer Steuerungsplattform über definierte Schnittstellen lässt sich die volle Performance eines Industrie- beziehungsweise Embedded-PC ohne Kommunikations- oder Synchronisierungsverluste nutzen.

Der modulare Aufbau der erweiterten Runtime und die für viele Anwendungsfälle bereits vordefinierten Schnittstellen erlauben es dem Anwender, die unterschiedlichen Steuerungen der Maschinen-Aggregate gemeinsam auf der zentralen Steuerungshardware der Maschine zu instanziieren und ermöglichen dadurch den Einsatz kostengünstiger Hardware.

Mit anderen Worten: Auf unterlagerte, dezentrale Steuerungshardware kann verzichtet werden. Dabei kann Twincat 3 alle Cores moderner CPUs nutzen und ist auch auf 64-Bit- Systemen einsatzfähig. Was die Entwicklung und den Test neuer Steuerungsmodule angeht, so können diese unabhängig von der spezifischen Gesamtlösung erfolgen.

Der Entwickler kann dabei auf eine Vielzahl vorhandener Module zurückgreifen und sie in einer auf Microsoft-Visual-Studio basierenden Entwicklungsumgebung zu neuen Modulen oder ganzen Steuerungsprogrammen zusammenstellen. Zur Erzeugung der Module sind zudem zusätzliche Entwicklungswerkzeuge wie beispielsweise Matlab/Simulink einsetzbar.

Autor: Dr. Dirk Janssen ist Leiter Software- Entwicklung System, CNC und I/O bei Beckhoff Automation.