Maschinenbau: Mehrwert durch Objektorientierung

Welche Vor- und Nachteile bringt die Umstellung auf eine objektorientierte SPS-Programmierung? Die Automatisierer im Maschinenbau sind sich zu Recht nicht einig. Dabei nutzen alle bereits einige der Möglichkeiten – teils sogar ohne es zu wissen. › von Roland Wagner

Einige Hundert Zeilen Code, etwa in AWL (Anweisungsliste), von der vorherigen Maschine übernehmen, diejenigen Codestellen suchen, finden und editieren, die gemäß Maschinenänderungen anzupassen sind, eventuell noch neue Applikationsteile hinzufügen und dann die gesamte Applikation auf die neue Maschine laden. Fertig.

Wenn Applikationsprogrammierer noch auf diese Weise recht effizient arbeiten, dann benötigen sie die objektorientierte Programmierung (OOP) scheinbar nicht. Mit einem Umstieg auf OOP würden Inbetriebnahmen für sie erst einmal länger dauern. Auch könnten sie ihren Code weniger überblicken und Änderungen wären aufwendiger als bis dato. Auch für kleine Projekte und Teams kann die Objektorientierung ihre Vorteile kaum entfalten.

OOP fließt heute jedoch zunehmend in die Ausbildung von Automatisierungstechnikern ein. Auch Ingenieure und Informatiker, die bereits im Studium OOP gelernt haben, erstellen immer öfter den Applikationscode für modulare oder komplexe Maschinen. Für sie ist eine Zerlegung der Applikation in relevante „Objekte“ ganz natürlich. Auch deren vereinheitlichte Definition durch Schnittstellen, sowie die Vererbung von Programmcode für andere Bausteine, erscheint ihnen als nur allzu logisch.

Mit der OOP in der SPS steigt die Attraktivität der Applikationsentwicklung für diese Generation der Entwickler. Insofern könnte OOP seinen Teil dazu beitragen, dass auch künftig sehr gut ausgebildete Programmierer motiviert an der technologischen Weiterentwicklung des Maschinen- und Anlagenbaus mittels Applikationscode mitwirken. Schließlich ist die Software mittlerweile verantwortlich für große Teile der Wertschöpfung.

Komplexität beherrschen

Komplexere Maschinen führen ganz von selbst zu komplexeren Projekten. Wie erwähnt erfordert das Zerlegen der Applikation in eine überschaubare Objektstruktur erst einmal einen beträchtlichen Initialaufwand. Dieser lohnt sich jedoch dann, wenn das Projekt laufend weiterentwickelt wird, vielleicht sogar von verschiedenen Applikateuren. Insbesondere für die Projektierung von Serienmaschinen, die aus ähnlichen Modulen in Varianten gefertigt werden, bietet die OOP unschätzbare Vorteile bei der Beherrschung der Komplexität.

Setzt ein Maschinenbauer zum Beispiel Heizaggregate verschiedener Hersteller und Bauart in seiner Maschine ein, so müsste er in der funktionalen Programmierung die Softwarebausteine für jedes einzelne Aggregat separat erstellen und aufrufen. Eine Aggregatsänderung führte damit zwangsläufig zum Editieren des gesamten relevanten Softwareteils. Und das, obwohl alle Aggregate ähnliche oder sogar identische Funktionen bereitstellen, wie Heizung an/aus, Heizprofil durchfahren, Kühlung ein/aus oder ähnliches.

In der OOP hingegen definiert er einfach eine einheitliche Schnittstelle für solche Basisfunktionen, die für sich zunächst leere Methoden enthalten. Codiert der Anwender dann Funktionsbausteine für das jeweilige Aggregat und implementiert die Schnittstelle mit den Methoden, so gewinnt er zweierlei.

Zum einen kann und wird er nicht vergessen, alle definierten Methoden der Schnittstelle für dieses Aggregat auch auszucodieren – denn das Programmiertool erinnert ihn daran. Zum anderen muss er lediglich an einer zentralen Stelle festlegen, welches spezielle Aggregat an der aktuellen Maschine zum Einsatz kommt. Der Aufruf der speziellen Methoden kann direkt über die Schnittstelle erfolgen – gleichgültig, in welchem Funktionsbaustein die entsprechende Methode für das eingesetzte Aggregat definiert wurde.

Daraus folgt: Wie komplex die Maschine auch sein mag und welche untergeordneten Einheiten konkret eingesetzt werden – der Aufruf von spezifischen Softwareteilen wird zentral festgelegt und muss nicht jedes Mal neu durchdacht werden.

Kapselung von Daten

Mit den verschiedenen Gültigkeitsbereichen VAR_INPUT, VAR_OUTPUT, VAR_INOUT und VAR für die Deklaration von Steuerungsvariablen haben die Entwickler der Norm IEC 61131-3 zur generellen Programmierung von SPSen, bereits Möglichkeiten zur sinnvollen Datenstrukturierung geschaffen. Der Anwender legt seit jeher damit fest, auf welche dieser Variablen innerhalb eines Bausteins zugegriffen werden darf. Einen versehentlichen Zugriff und potenzielle Fehlerquellen kann er so vermeiden.

In der OOP geht die Datenkapselung jedoch noch viel weiter: Daten können in Methoden angelegt und dann nur von diesen verwendet werden. Darüber hinaus steht aber auch der Objekttyp „Eigenschaft“ („Property“) als Kindobjekt eines Funktionsbausteins zur Verfügung, in dem Daten sauber gekapselt und lediglich über zugehörige Set- und Get-Methoden verwendet werden können. Referenzen auf bestehende Objekte und eine Datentyp-Abfrage ermöglichen dabei einen definierten Umgang mit diesen Daten – auch für komplexere Variablen, wie beispielsweise Strukturen oder abgeleitete Datentypen. Der Nutzen solcher Konstrukte steigt mit der Komplexität des SPS-Programms.

Wiederverwendung von Code

IEC-61131-3-Entwicklungssysteme wie Codesys verfügen über eine komfortable Bibliotheksverwaltung. So kann der Anwender Funktionsbausteine und Funktionen zur späteren Verwendung in einer Bibliothek speichern und diese in andere Projekte einbinden. Was ist aber mit Code, der nicht vollständig in einen Funktionsbaustein ausgelagert und in eine Bibliothek gepackt werden kann? Zum Beispiel, weil er sich auf spezifische Teile der Applikation bezieht, aber dennoch wiederverwendet werden könnte?

Für solche Fälle bietet die OOP wiederum ein mächtiges Mittel: die Vererbung. Im oben genannten Beispiel von den unterschiedlichen Heizaggregaten könnte der Anwender den „Prototyp“ eines Aggregats in Form eines Funktionsbausteins mit sämtlichen Funktionen und Methoden codieren, die in allen real verwendeten Aggregaten verfügbar sind. Er erstellt damit eine sogenannte Basisklasse. Ausgehend von solch einer Klasse kann er jetzt mittels des Keywords „EXTENDS“ ein komplexeres Aggregat definieren und mit zusätzlichen Methoden ausprogrammieren, um die Basisfunktionalität zu erweitern.

Dabei stehen ihm ohne weiteres Zutun die in der Basisklasse erstellten Methoden zur Verfügung. Reicht die Funktion einzelner Methoden jedoch nicht, so kann er sie „überladen“, also um Funktionen erweitern, die in der Basisklasse so nicht implementiert waren. Der ursprüngliche Code des Basistyps kann über den sogenannten „SUPER^“-Operator bequem zusätzlich aufgerufen werden – auch er wird an die erweiterte Klasse vererbt. Anhand von Funktionsbausteinen, die auf andere Funktionsbausteine und auf Schnittstellen zugreifen („Aggregation“), kann der Anwender nun die gesamte Applikation hierarchisch aufbauen und dabei bereits codierte Funktionen weiterverwenden.

Effizienz beim Engineering

Mit ein wenig Übung und Erfahrung bei der OOP gewinnt eine komplexe Applikation an Übersichtlichkeit und wird deutlich besser beherrschbar. Ist die OOP etabliert, reicht oft der Aufruf weniger Bausteine, um ein neues Projekt komplett zu beschreiben. Diese Bausteine verzweigen ihrerseits in die Tiefe und führen die codierten beziehungsweise vererbten Funktionen aus. Die weite Verbreitung der OOP in anderen Bereichen der Software-Entwicklung beweist eindrucksvoll, welche Vorteile dieses Vorgehen bietet.

Eine Umstellung von Applikationen darf aber nicht „mit der Brechstange“ erfolgen, sondern im Takt der natürlichen Weiterentwicklung von Anwendungen und Programmierern. Codesys wird dieser Forderung gerecht: Objektorientiert programmierte Bausteine werden bereitgestellt, vom Anwender jedoch funktional aufgerufen, ohne dass er von der OOP etwas merkt. Die OOP ermöglicht eine nahtlose Integration vieler mächtiger Funktionen wie Visualisierung, Motion Control oder Feldbusunterstützung in die IEC-61131-3-Oberfläche. Viele Anwender nutzen selbst bewusst diese Möglichkeiten für ein effizienteres Engineering, andere profitieren aktuell lediglich implizit davon – letztlich haben jedoch alle einen Mehrwert. jbi ‹

Autor: Dipl.-Ing. (FH) Roland Wagner ist Head of Product Marketing bei 3S-Smart Software Solutions in Kempten.