Relevanz für SPS-Programmierer
Die klassische Art der SPS-Programmierung ist heute immer noch gängig: Einige Hundert Zeilen Code, z. B. in AWL, 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 Maschine laden. Wenn Applikationsprogrammierer so arbeiten, dann benötigen sie die objektorientierte Programmierung (OOP) 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 bzw. Anpassungen wären aufwendiger als bisher. Auch für kleine Projekte und Teams kann die Objektorientierung ihre Vorteile kaum entfalten.
OOP fließt heute zunehmend in die Ausbildung von Automatisierungstechnikern ein. 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.
Mit der OOP in der SPS steigt die Attraktivität der Applikationsentwicklung – sie verliert den Ruf als reine „Klapperlogik“. Insofern garantiert die OOP, dass auch künftig sehr gut ausgebildete Programmierer Spaß daran haben, die technologische Weiterentwicklung des Maschinen- und Anlagenbaus in Applikationscode umzusetzen. Schließlich ist die Software verantwortlich für große Teile der Wertschöpfung – effiziente Werkzeuge, Methoden und entsprechend ausgebildete Programmierer sind dafür unerlässlich.
Komplexität beherrschen
Komplexere Maschinen führen ganz von selbst zu komplexeren Projekten. Das Zerlegen der Applikation in eine überschaubare Objektstruktur erfordert zwar erst einmal einen beträchtlichen Initialaufwand. Er lohnt sich aber, 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. So können die Anwender mit dem Sprachmittel der Schnittstelle Methodensätze vordefinieren, die dann in unterschiedlichen Einheiten ähnlichen Typs zum Einsatz kommen, d. h. „implementiert“ werden.
Setzt ein Sondermaschinenbauer 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 z. B. Heizung an/aus, Heizprofil durchfahren, Kühlung ein/aus oder ähnliches. In der OOP definiert er 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 - das Tool erinnert ihn daran. Zum anderen muss er lediglich an einer zentralen Stelle festlegen, welches spezielle Aggregat denn an der Maschine wirklich zum Einsatz kommt. Der Aufruf der speziellen Methoden kann direkt über die Schnittstelle erfolgen – gleichgültig, in welchem FB für das eingesetzte Aggregat die entsprechende Methode definiert wurde. Und daraus folgt: Wie komplex die Maschine auch sein mag, welche untergeordneten Einheiten konkret eingesetzt werden: Der Aufruf von spezifischen Softwareteilen kann 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 Väter der IEC 61131-3 bereits Möglichkeiten zur sinnvollen Datenstrukturierung geschaffen. Der Anwender legt 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 viel weiter: Daten können einerseits in Methoden angelegt und dann nur von diesen verwendet werden. Andererseits bietet die OOP den Objekttyp „Eigenschaft“ („Property“) als Kindobjekt eines FBs, 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 z. B. Strukturen oder abgeleitete Datentypen. Der Nutzen solcher Konstrukte steigt mit der Komplexität eines SPS-Programms.
Wiederverwendung von existierendem Code
IEC 61131-3-Entwicklungssystemen wie CODESYS verfügen über eine komfortable Bibliotheksverwaltung. So kann der Anwender FBs oder Funktionen zur späteren Verwendung in einer Bibliothek abspeichern und diese in anderen Projekten einbinden. Was ist aber mit Code, der nicht vollständig in einen FB ausgelagert und in eine Bibliothek verpackt 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 z. B. den „Prototyp“ eines Aggregats in Form eines Funktionsbausteins mit sämtlichen Funktionen bzw. Methoden codieren, die in allen real verwendeten Aggregaten verfügbar sind. Er erstellt damit eine Basisklasse. Ausgehend von solch einer Klasse kann er jetzt mittels des neuen Keywords „EXTENDS“ ein komplexeres Aggregat definieren und mit Methoden ausprogrammieren, welche die Basisfunktionalität 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“, d. h. um Funktionen erweitern, die in der Basisklasse so nicht implementiert waren. Der ursprüngliche Code des Basistyps kann über den Super^-Operator bequem zusätzlich aufgerufen werden – auch er wird an die erweiterte Klasse vererbt. Anhand von FBs, die auf andere FBs bzw. auf Schnittstellen zugreifen („Aggregation“), kann der Anwender jetzt 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. Oft kann das gesamte Projekt dann durch Aufruf weniger Bausteine komplett beschrieben werden. Diese Bausteine verzweigen ihrerseits in die Tiefe und führen die codierten bzw. vererbten Funktionen aus. Die weite Verbreitung der OOP in anderen Bereichen der Software-Entwicklung beweist eindrucksvoll, dass ihre Vorteile überwiegen. Eine Umstellung von Applikationen darf aber nicht „mit der Brechstange“ erfolgen, sondern im Takt der natürlichen Weiterentwicklung von Anwendung 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. Letztlich ermöglicht erst die OOP eine nahtlose, „geschmeidige“ Integration vieler mächtiger Funktionen wie Visualisierung, Motion Control oder Feldbusunterstützung in die IEC 61131-3 Oberfläche. Viele Anwender nutzen selbst die Möglichkeiten der OOP für ein effizienteres Engineering, andere profitieren nur implizit davon – letztlich haben jedoch alle einen Mehrwert.
Mechatronik 1-2/2018