ein bezeichnendes Merkmal der objektorientierten Programmierung ist die Möglichkeit, Funktionen und die zugehörigen Daten eng zu einem Objekt zusammenfassen und kapseln zu können. So erstellte Objekte (Softwaremodule) lassen sich in übersetzter Form zur Wiederverwendung weitergeben und sind durch die Kapselung vor Manipulation geschützt. Bei der Applikationsprogrammierung von Automatisierungssystemen überwiegen nach wie vor verknüpfungsorientierte Programmiermethoden wie z.B. Kontakt- oder Funktionsplan oder prozedurale Programmiermethoden. Auch assemblernahe Programmierungen wie Anweisungsliste haben einen hohen Verbreitungsgrad. Der zunehmende Einsatz von PCs in Automatisierungsanlagen führte zu dem Wunsch nach Hochsprachenprogrammierung bei Automatisierungssystemen. Die Verfügbarkeit von Hochsprachen ist die Grundvoraussetzung für objektorientiertes Programmieren. Bis auf wenige Ausnahmen hat sich objektorientiertes Programmieren (OOP) jedoch bis heute in der Breite nicht durchgesetzt. Ein Grund dafür ist, dass die Methodik der Objektorientierung bei den Programmierern nur teilweise, vor allem aber beim Wartungspersonal nur unzureichend bekannt ist. Auch der Vorteil, dass funktionsfähige gekapselte Softwaremodule zwischen verschiedenen Steuerungssystemen ausgetauscht werden können, greift nicht, da heutige Steuerungsarchitekturen zu unterschiedlich sind. Aus diesen Gründen ergeben sich wenige Anforderungen zu OOP in Automatisierungssystemen. Das führt dazu, dass die Steuerungshersteller OOP nur zögernd vorantreiben. Objektorientierung: Vorteile Je mehr Antriebssysteme in Kombination mit Motion-Control-Steuerungen und je mehr Steuerungen im Verbund miteinander betrieben werden, desto ausführlicher muss auch die Kommunikation zwischen den Steuerungen und Antrieben programmiert werden. Dabei stößt man mit den klassischen Programmiermethoden häufig an Grenzen. Die Programme werden immer umfangreicher, und es wird immer schwieriger, den Gesamtzusammenhang im Blick zu behalten. Hier würde die objektorientierte Vorgehensweise Vorteile bringen. Allerdings müssen dazu die Sprachen und Methoden für den Anwender einfach zu erlernen und deren Ergebnisse leicht lesbar sein, damit auch die Wartung von Anlagen gewährleistet ist. Um signifikante Zeitvorteile bei der Anwendung von OOP zu erreichen, ist es notwendig, sich auf neue Denkweisen bei der Programmierung einzustellen. Hierzu ist anfangs etwas mehr Zeit in die Planung zu investieren. Steuerungshersteller müssen Programmiersprachen oder Methoden mit der Möglichkeit der Objektorientierung für ihre Automatisierungssysteme anbieten. Einen Ausweg, sprich einen vereinfachten Umgang mit komplexen Automatisierungslösungen, bietet neben der objektorientierten Programmierung eine objektorientierte Sicht auf die Elemente einer Automatisierungsanlage. Um das zu erreichen, muss die Systemsoftware so geändert werden, dass sich der Anwender auf seine eigentlichen Aufgaben konzentrieren kann. Er muss von dem Zwang befreit werden, auch die Kommunikation zwischen den Steue-rungen und zu den Antrieben aufwendig zu programmieren. Das sollte das Automatisierungssystem als Systemleistung mitbringen. Außerdem sollte das System dem Anwender ermöglichen, seine Maschinen mit ihren real existierenden Modulen in der Software abbilden zu können. Eine in diesem Sinn veränderte Systemsoftware führt zwangsläufig zu einem objektorientierten Runtime-Modell. Herkömmliche Systeme Beim herkömmlichen System werden die Funktionen als Softwaremodule in der Systemsoftware implementiert. Dabei werden in der Systemsoftware die Funktionen programmiert und die dazu gehörigen Speicherbereiche fest reserviert. In diesen werden die Daten für die jeweiligen Funktionen abgelegt (Bild 1). Bei Verwendung der jeweiligen Funktion (z.B. Achse) wird diese aktiviert und der Speicherbereich mit den jeweiligen Daten für die Achse gefüllt. Mit den Daten arbeitet das Runtime-Modell. Dabei sind jedoch immer Begrenzungen für die Anzahl der verwendbaren Funktionen vorhanden, da für alle Funktionen der notwendige Speicher für die Maximalkonfiguration fest reserviert werden muss – unabhängig davon, ob der Anwender die Funktion nutzt oder nicht. Darüber hinaus hängt die Modellierung immer von der verwendeten Hardware ab. Kommen weitere Funktionen dazu, die in der Systemsoftware realisiert werden, führt das zu einem immer größeren Speicherbedarf für die Daten der jeweiligen Funktion, der reserviert werden muss. Das macht jede Funktionserweiterung zwangsläufig aufwendig und damit teuer. Häufig müssen deshalb abgestufte Systeme entwickelt werden: Wenig Funktionalität zum günstigen Preis, mehr Funktionalität für entsprechend mehr Geld. Gerade dabei haben die Systeme oft unterschiedliche Datenstrukturen, obwohl sie einer Familie angehören. Somit ist ein Austausch der Projektierung zwischen den Systemen mit Schwierigkeiten verbunden oder unmöglich. Runtime-Modell Beim objektorientierten Runtime-Modell wird die Funktion ebenfalls als Modul in der System-Software implementiert, aber eben als objektorientiertes Modell. Erst beim Erstellen eines Objektes (beispielsweise einer Achse) entsteht eine Instanz desselben. Dabei kann dann der Datenbereich für den jeweiligen Objekttyp (z.B. Art der Kopplung zum Antrieb) durchaus unterschiedlich groß sein, was Speicherplatz spart. Werden keine Achsen (= Objekte) benötigt, entsteht auch kein Speicherplatzbedarf für die Daten. Da die Daten immer zum Objekt gehören, muss für Objekte kein Speicherbereich reserviert werden. Dadurch gibt es keine Begrenzung der Objekt-Anzahl – abgesehen vom verfügbaren Gesamtspeicher. Bei der Programmierung können die Objekte jeweils als eigenes Softwaremodul betrachtet werden, obwohl faktisch immer derselbe Programmcode in der Systemsoftware abgearbeitet wird. Das Systemverhalten kann so betrachtet werden, als wäre der Programmcode entsprechend der Objektzahl n-mal vorhanden. Weiterhin bietet das Modell die Flexibilität, dass in der jeweiligen Funktion der Systemsoftware auch die Kommunikation mit anderen Modulen implementiert werden kann. So wird die Kommunikation zur Systemleistung und muss nicht mehr durch den Anwender programmiert werden. Es ist bei diesem Runtime-Modell kein Problem, die Projektierung zwischen unterschiedlich leistungsfähigen Systemen auszutauschen und skalierbare, durchgängige Anlagenfamilien zu erzeugen, da keine Strukturen vordefiniert implementiert werden müssen. Funktionelle Erweiterungen können ohne Schwierigkeiten in existierende Projektierungen übernommen werden. Runtime-Modell in der Praxis Ein solches objektorientiertes Runtime-Modell bildet die vorhandenen Objekte einer Maschine in der Software ab. Dabei findet der Anwender im zugehörigen Engineering-System seine in der Realität vorhandenen Maschinenmodule und -komponenten wieder. Diese verknüpft er über weitere Funktionen wie z.B. Getriebe untereinander, wie er es früher mit den mechanischen Elementen getan hat. Alle Objekte besitzen eine Funktionsaufrufschnittstelle, über die der Anwender im Anwenderprogramm Kommandos an das jeweilige Objekt weiterleiten kann. Das Kommando wird dann vom Objekt selbstständig ausgeführt, und es werden entsprechende Rückmeldungen gegeben. Ein objektorientiertes Runtime-Modell muss alle Objekte wie z.B. Achsen, Gleichlaufobjekte (Getriebe), Nocken, Messtaster usw. anbieten. Über ein geeignetes Engineering wird dem Anwender die Möglichkeit geboten, die Objekte in der Software anzulegen und zu verschalten (Bild 2). Der Anwender legt z.B. alle vorhandenen Achsen der Maschine als Achsobjekte an. Sie werden über ein Gleichlaufobjekt verknüpft und sind somit gekoppelt. Die Kopplung muss abhängig vom jeweiligen Betriebszustand zu- und abschaltbar sein. Über Befehle kann jedes Objekt beeinflusst werden. Dabei ist die notwendige Kommunikation zwischen verknüpften Objekten oder mit dem jeweiligen Antrieb eine Eigenschaft des Objektes \’Achse\‘. Weitere Objekte wie z.B. Nocken, Messtaster oder weitere Geber sind dabei möglich. Alle technologischen Funktionen lassen sich so in einem objektorientierten Runtime-Modell abbilden und in der erforderlichen Art und Weise verknüpfen. Damit entsteht eine Flexibilität im System, die mit herkömmlichen starren Modellen nicht erreichbar ist. Der Anwender kann sich auf seine eigentliche Aufgabe konzentrieren und seine Maschinenapplikation programmieren. Hohe Flexibilität Das für Simotion realisierte Modell bietet dem Anwender bislang ungekannte Flexibilität. Die einzelnen Objekte lassen sich über das Engineering-System Scout anlegen, konfigurieren und verschalten. Scout unterstützt dabei mit implementierten Wizards und Masken die Erstellung der Objekte. Die integrierten Kommunikationsfunktionen zwischen Steuerung und Antrieben werden bei der Konfiguration der Achsobjekte mit festgelegt. Damit entfällt die Programmierung der Kommunikation. Durch die Objektorientierung im Runtime-System lässt sich modular zu den Objekten programmieren. Die Programme werden also zu den Objekten modular aufgebaut und ermöglichen so die Mehrfachverwendung der einzelnen Module in der Anwendersoftware. Kombiniert man das Runtime-System noch zusätzlich mit der Möglichkeit des Multitasking-Betriebs, ergibt sich daraus eine weitere Leistungssteigerung. Damit lassen sich komplette Funktionsabläufe modular aufbauen und quasi parallel abarbeiten. Selbst Maschinen mit großer Achsanzahl und synchronisierten Achsen oder interpolatorischem Achszusammenhang sind mit diesem flexiblen Automatisierungssystem vergleichsweise einfach zu realisieren. Die Vorteile lassen sich nutzen, wenn bei der gesamten Programmierung die Objektorientierung berücksichtigt wird. Dazu bedarf es nur eines einfachen Schrittes in der Denkweise. Die bisherige verknüpfungsorientierte Denkweise und Methodik der Programmierung muss verlassen werden: Ein Denken in Modulen ist erforderlich. Neue Möglichkeiten Die beim erwähnten Motion-Control-System Simotion \’im System\‘ realisierte Objektorientierung erschließt neue Möglichkeiten bei der Entwicklung und Projektierung moderner Produktionsmaschinen. Damit sind hohe Taktraten bei gleichzeitig hoher Genauigkeit ebenso einfach umzusetzen wie solche mit großen Achsmengengerüsten und verteilter Intelligenz über mehrere CPUs bei verteiltem Gleichlauf. Dabei ist keine zusätzliche Programmierung der Kommunikation für Gleichlauf notwendig. Auch spezielle Kinematiken zum Entladen oder Beladen der Maschinen mit Transformationen und Synchronisation auf den Prozess sind so mit geringem Aufwand realisierbar. Bestehende Projektierungen können in Simotion aufgrund des objektorientierten Runtime-Systems nahezu unverändert übernommen und mit zusätzlichen Funktionen kombiniert werden.
Siemens AG
