Einleitung
Die Methode, klassische Automatisierungsgeräte wie speicherprogrammierbare Steuerungen (SPS) und numerische Steuerungen (NC) als Software auf leistungsstarker Standard-Hardware nachzubilden, ist seit vielen Jahren der Stand der Technik und wird nun von vielen Herstellern praktiziert.
Es gibt viele Vorteile, aber der wichtigste ist sicher, dass die Software weitgehend hardwareunabhängig ist. Das heißt zum Einen, dass die Leistungsfähigkeit der Hardware speziell an die Anwendung angepasst werden kann und zum Anderen, dass man automatisch von ihrer Weiterentwicklung profitieren kann.
Dies gilt insbesondere für PC-Hardware, deren Leistung noch immer dramatisch schnell ansteigt. Die relative Unabhängigkeit von einem Lieferanten, die aus dieser Trennung von Software und Hardware resultiert, ist für den Nutzer auch sehr wichtig.
Da SPS und Bewegungssteuerung - und möglicherweise andere Automatisierungskomponenten - bei dieser Methode unabhängige Logikbausteine bleiben, gibt es im Vergleich zur klassischen Automatisierungstechnologie nur wenige Änderungen in der Anwendungsarchitektur.
Die SPS bestimmt die logischen Abläufe der Maschine und überträgt der Bewegungssteuerung die Implementierung bestimmter Achsfunktionen. Dank der verbesserten Leistung der Steuerungen und der Möglichkeit, höhere Programmiersprachen (IEC 61131-3) zu verwenden, können auf diese Weise auch komplexe Maschinen automatisiert werden.
Modularisierung
Um die Komplexität moderner Maschinen zu meistern und gleichzeitig den dafür nötigen Engineering-Aufwand zu senken, haben viele Hersteller begonnen, ihre Maschinen zu modularisieren. Individuelle Funktionen, Baugruppen oder Maschineneinheiten werden dabei als Module betrachtet, die untereinander so unabhängig wie möglich sind und über einheitliche Schnittstellen in das Gesamtsystem eingebettet werden.
Eine Maschine ist danach idealerweise hierarchisch strukturiert, wobei Module der niedrigsten Ebene einfachste, ständig wiederverwendbare Grundelemente repräsentieren. Miteinander verbunden bilden sie immer komplexere Maschineneinheiten, bis auf höchster Ebene die gesamte Maschine entsteht. Für Steuerungssysteme bei Maschinenmodularisierung gibt es unterschiedliche Herangehensweisen. Sie können grob in eine dezentralisierte und eine zentralisierte Vorgehensweise unterteilt werden.
Beim lokalen Ansatz hat jede Maschine ihre eigene Steuerung, die die SPS- und möglicherweise auch die Bewegungsfunktionen des Moduls übernimmt.
Die individuellen Module können getrennt voneinander in Betrieb genommen und gewartet werden. Sie können relativ unabhängig voneinander skaliert werden. Die notwendigen Interaktionen zwischen den Steuerungen werden über Kommunikationsnetzwerke (Feldbusse oder Ethernet) koordiniert und über geeignete Profile standardisiert.
Der zentralisierte Ansatz konzentriert die Steuerungsfunktionen aller Module in einer gemeinsamen Steuerung und nutzt die Rechenintelligenz der lokalen I/O-Geräte nur sehr wenig. Interaktionen können in der zentralen Steuerungseinheit viel direkter ausgeführt werden, da die Kommunikationswege viel kürzer sind. Es treten keine Totzeiten auf und die Steuerungshardware wird viel besser ausgenutzt, was die Gesamtkosten senkt.
Allerdings hat die zentralisierte Methode auch den Nachteil, dass eine Modularisierung der Steuerungssoftware nicht automatisch notwendig ist. Die Möglichkeit, auf alle Informationen anderer Programmteile in der zentralen Steuerung zugreifen zu können, bietet keinen Anreiz zum Aufbau der Steuerungssoftware aus Modulen, die in anderen Anwendungen wiederverwendet werden können. Da es zwischen den Steuerungseinheiten keinen Kommunikationskanal gibt, bleiben die Entwicklung eines geeigneten Profils und die Standardisierung der Steuerungseinheiten häufig auf der Strecke.
Das Beste aus beiden Welten
Die ideale Steuerung für modulare Maschinen nutzt Elemente aus dezentralisierter und zentralisierter Steuerungsarchitektur. Eine zentrale, leistungsstarke und möglichst allgemeine Computerplattform dient „wie üblich“ als Steuerungshardware.
Die Vorteile einer zentralisierten Steuerungstechnologie:
- geringe Gesamtkosten
- verfügbar
- schnelles, modulares Feldbussystem (Stichwort EtherCAT)
- und die Möglichkeit, auf alle Informationen im System ohne Kommunikationsverlust zugreifen zu können
sind entscheidende Argumente.
Die oben aufgeführten Vorteile einer dezentralisierten Herangehensweise können in der zentralisierten Steuerung durch geeignete Modularisierung der Steuerungssoftware umgesetzt werden.
Anstelle ein großes, komplexes SPS-Programm und eine NC mit vielen Achsen ablaufen zu lassen, können viele kleine „Steuerungen“ in einer gemeinsamen Laufzeit nebeneinander auf der gleichen Hardware relativ unabhängig voneinander koexistieren. Die einzelnen Steuerungsmodule sind in sich abgeschlossen und stellen der Umgebung ihre Funktionen über Standard-Schnittstellen zur Verfügung oder nutzen entsprechende Funktionen anderer Module oder der Laufzeit.
Durch die Definition dieser Schnittstellen und die Standardisierung der entsprechenden Parameter und Prozessdaten entsteht ein signifikantes Profil. Da die einzelnen Module in eine Laufzeit implementiert sind, sind auch direkte Aufrufe anderer Module möglich - wiederum über entsprechende Standardschnittstellen. Die Modularisierung kann so in sinnvollen Grenzen stattfinden, ohne dass Kommunikationsverluste auftreten.
Während der Entwicklung oder Inbetriebnahme einzelner Maschinenmodule können die entsprechenden Steuerungsmodule erstellt und auf beliebiger Steuerungshardware mit geeigneter Laufzeit getestet werden. Fehlende Anbindungen an andere Module können in dieser Phase emuliert werden. Bei der kompletten Maschine werden sie dann zusammen auf der zentralen Laufzeit instanziiert, die lediglich so dimensioniert sein muss, dass der Bedarf an Ressourcen für alle instanziierten Module (Speicher, Tasks und Rechenleistung) erfüllt wird.
TwinCAT 3 Runtime
TwinCAT Runtime bietet eine Softwareumgebung in der die TwinCAT Module geladen, implementiert und verwaltet werden. Sie bietet weitere Basisfunktionen, sodass die Systemressourcen (Speicher, Tasks, Feldbus und Hardwarezugang, usw.) genutzt werden können. Die einzelnen Module müssen nicht mit demselben Compiler erstellt worden sein. Damit können sie voneinander unabhängig sein und von unterschiedlichen Anbietern stammen.
Beim Start der Laufzeit werden automatisch einige Systemmodule geladen, sodass ihre Eigenschaften anderen Modulen zur Verfügung stehen. Allerdings erfolgt der Zugriff auf die Eigenschaften der Systemmodule auf die gleiche Weise wie auf die Eigenschaften normaler Module, sodass es für die Module keine Rolle spielt, ob die jeweilige Eigenschaft von einem Systemmodul oder einem normalen Modul zur Verfügung gestellt wird.
Im Gegensatz zur SPS, wo das benutzerdefinierte Programm in einer Laufzeitumgebung ausgeführt wird, sind TwinCAT C++ Module nicht in so einer gehosteten Umgebung. Dadurch werden TwinCAT C++ Module (.tmx) als Kernel-Module ausgeführt, die von TwinCAT geladen werden.