Die Wertschöpfung erfolgt mehr und mehr über die Software – diese Erkenntnis dürfte mittlerweile bis in den letzten Winkel des Maschinen- und Anlagenbaus durchgedrungen sein. Da gleichzeitig die Vernetzung und Komplexität der Lösungen zunehmen, fordern die Anwender verständlicherweise bessere Möglichkeiten, diese Komplexität zu beherrschen. Dies geht unter anderem aus einer Studie des VDMA hervor, in deren Rahmen rund 300 Entwicklungs- und Konstruktionsleiter befragt wurden (siehe hierzu beifügten Artikel). Zahlreiche Gespräche mit Anwendern des IEC-61131-3-Programmiersystems Codesys untermauern diese Erkenntnisse, aus denen sich letztlich zwei Trends ableiten lassen:

■ die Integration von bewährter Funk­tionalität aus der IT-Welt in Automatisierungssysteme
■ sowie die Zusammenfassung von Komplexität in Modulen, aus denen sich komplette Maschinen oder An­lagen konfektionieren lassen.

Lernen von der IT-Welt

Methoden, Paradigmen und Tools, die sich über viele Jahre bei der Programmierung von IT-Anwendungen bewährt und zur effizienteren Programm-Erstellung geführt haben, sollen auch in der Automatisierungstechnik ihr Ziel nicht verfehlen. In der Vergangenheit scheiterten solche Übertragungen allerdings meist an der Radi­kalität ihrer Ein­führung: So lehnten „altgediente“ Steuerungsprogrammierer beispielsweise die objektorientierte Programmierung (OOP) von vornherein ab, wenn sie alternativlos eingeführt wurde und die Anwender gleichzeitig dazu zwang, für zukünftige Projekte auf allgemeine Entwicklungsumgebungen wie zum Beispiel VisualStudio umzusteigen. Was sich daraus lernen lässt: Es ist unabdingbar, Neuerungen aus der IT-Welt, die auf die Automatisierungstechnik übertragen werden sollen, unter dem Dach der etablierten Tools vorzunehmen. Schließlich geht aus einer anderen Untersuchung im Jahr 2011 hervor, dass die Anwender bei der Entwicklung von Steuerungsprogrammen mehr­heitlich auf Sprachen der IEC 61131-3 zurückgreifen (98 von 157 Nennungen) und andere Sprachen wie C+, UML, C# oder Matlab/Simulink aktuell noch eine untergeordnete Rolle spielen (siehe hierzu beigefügten Artikel).

Die Einführung „echter“ OOP als Programmieroption im Rahmen von Codesys V3 etwa schließt bereits eine große Lücke zwischen der IT- und der Steuerungsprogrammierung. Sie versetzt entsprechend ausgebildete Anwender in die Lage, Systembausteine ob­jektorientiert zu programmieren. Dabei können sie Interfaces, Methoden und Vererbung verwenden, Programmteile dynamisch linken, Methoden überladen und Properties definieren – so wie wir es von den Hochsprachen her kennen. Die Programmierer brauchen dazu jedoch nicht die IEC 61131-3 verlassen, das heißt Methoden und deren Aufrufe können in AWL, FUP, KOP oder typischerweise im Strukturierten Text programmiert werden.

Anders ausgedrückt: Anwender, die nur mit der funktionalen Programmierung vertraut sind, können wie bisher auf die Systembausteine zugreifen und müssen sich nicht mit der OOP auseinandersetzen. Auf Initiative von 3S-Smart Software Solutions wurde dieses Konzept in das Normungsgremium der IEC 61131-3 eingebracht und steht kurz vor der Freigabe im Rahmen des dritten Release dieser Norm.

UML als „Einheitssprache“

In einem komplexen OOP-Projekt kann der Programmierer durchaus den Überblick über die Abhängigkeiten der Bausteine untereinander verlieren. Mit dem UML-Klassendiagramm (UML – Unified Modeling Language) als wichtigstem Struktur-Diagramm kann er sich die Abhängigkeiten zwischen Klassen, Objekten, Methoden und Interfaces grafisch darstellen lassen beziehungsweise diese Abhängigkeiten konkret planen und erstellen. Damit wird die OOP insgesamt besser beherrschbar. Die Einführung eines UML-Klassendiagramms ist somit der nächste logische Schritt nach der Einführung der OOP in ein IEC-61131-3-Tool.

Aufgrund der nahtlosen Integration im Programmiertool kann der Programmierer mit dem UML-Aktivitätsdiagramm funktionale Abläufe bequem projektieren und direkt daraus Applikationscode erzeugen.

© 3S-Smart Software Solutions

Doch damit ist UML noch lange nicht am Ende! Aus den insgesamt 14 verschiedenen definierten Diagrammen wurden im Rahmen eines Forschungsprojekts zusätzlich das Aktivitäts- und das Zustandsdiagramm als hilfreich für die Automatisierung erachtet. Beide Diagramme sind als neue Editoren ebenfalls nahtlos in Codesys implementiert. Damit können Anwender parallel zum IEC-Standard die Applikation beschreiben und sogar den Applikationscode erzeugen.

Verfahrens- oder Anwendungstechniker, die den Prozessablauf der Anlage oder Maschine beherrschen (so genannte „Technologen“), sind mit diesen Diagrammen vertraut. Deswegen beherrschen sie aber noch lange nicht die Umsetzung in Software. Im IEC-61131-3-Programmiersystem werden diese Diagramme somit zum Kommunikationsmedium beziehungsweise zur „Einheitssprache“, um die vielfach zitierte „babylonische Sprachverwirrung“ zwischen Maschinenbau und Software zu entwirren. Mit diesen Diagrammen beschreiben die Technologen dann Abläufe, Funktionen und deren Aufruf für die Applikationsprogrammierer. Mit der Integration in das SPS-Programmiersystem ersparen sich beide Seiten den Aufwand, diese Diagramme von an­deren Tools zu übertragen – nebenbei reduziert dies die Fehlerquote.

Produktivitätssteigerung durch Zusatztools

Insbesondere bei komplexen Projekten sind die Zeiten vorbei, in denen ein Applikateur allein die gesamte Maschine oder Anlage programmierte. In aller Regel verständigen sich heutzutage Applikationsteams darauf, wieder nutzbare Teile in Bibliotheken abzulegen, die dann applikationsunabhängig verwendbar sind.

Statische Code-Analyse für IEC-61131-3-Applikationen: Mit Dutzenden von Testfällen kann der SPS-Programmierer sein Projekt auf potenzielle Fehler­quellen und die Einhaltung von Programmierregeln überprüfen.

© 3S-Smart Software Solutions

Gleichgültig, ob für Bibliotheken oder für Programmbausteine, die innerhalb der Applikation erstellt werden – eine Versionsverwaltung ist in jedem Fall sinnvoll. In der IT-Welt hat sich hierfür mittlerweile Apache Subversion (SVN) etabliert. Nun könnte der Programmierer seine Programmbausteine und Bibliotheken auch mit Export-/Import-Mechanismen in SVN ablegen. Ohne eine Integration in die IEC 61131-3 würde das aber zu einer erheblichen Störung des natür­lichen Programmierablaufs führen. Daher bietet Codesys im Rahmen der so genannten „Professional Developer Edition“ mittlerweile eine nahtlos integrierte SVN-Anbindung. Diese An­bindung deckt die zentrale Daten­ablage ab, die Zugriffsverwaltung auf den Code sowie die Verwaltung von Quellcode-Versionen (Configuration Management), um zum Beispiel aus­gelieferte Versionsstände jederzeit wiederherstellen zu können.
Mit einer statischen Code-Analyse reduziert der Programmierer Entwicklungszeit, indem er logische Fehler in seinem Applikationscode erkennt und behebt, noch bevor er diese auf seine Steuerung geladen hat. Mit einigen Dutzend Testfällen deckt das Tool „Codesys Static Analysis“ genau diese Aufgabe ab. Es beinhaltet unter anderem die Überprüfung auf konkurrierenden Variablen-Zugriff, auf mehrfaches Schreiben von Ausgabe-Variablen, auf deklarierte und nicht verwendete Va­riablen sowie auf leere Programm­bausteine im Projekt. Der Anwender kann die Verwendung sämtlicher Prüfungsfälle projektweit ein- beziehungsweise abschalten und darüber hinaus mit Hilfe von Pragmas (Compiler-Direktiven) im Applikationscode fein granular beziehungsweise bis hin zur einzelnen Variablen Ausnahme-Regeln aufnehmen.

Daneben werden in absehbarer Zeit weitere Tools, die in der IT-Welt bereits lange etabliert sind, bei der SPS-Programmierung Einzug halten; etwa ein „Profiler“ für Laufzeit-Berechnungen und -Optimierungen des Applikationscodes oder ein „Testmanager“, mit dem automatisierte Applikationstests direkt in der IEC-61131-3-Oberfläche vorgenommen werden können.

Die Applikationscode-Generierung

Gerade in Maschinen mit einem immer wiederkehrenden Software-Anteil steckt einerseits ein gewaltiges Rationalisierungspotenzial für die Projektierung. Andererseits bergen sie aber auch ein hohes Fehlerpotenzial. Ziel muss es daher sein, die Komplexität der Maschinen oder Anlagen in Modulen zusammenzufassen und daraus automatisiert Applikationscode zu erzeugen. Was dies in der Praxis bedeutet, sei im Folgenden am Beispiel des „Codesys Application Composer“ veranschaulicht. Das vertraute SPS-Programmiertool wird dabei um ein Modulkonzept erweitert, auf dessen Basis sich die Applikation „konfektionieren“ lässt.

Ablaufsteuerung mit Programmsequenzen: Ist es erforderlich, einen zeitlichen Ablauf für Module festzulegen, so kann das wiederum im Modulbaum erfolgen, oder aber mit einem Ablaufeditor.

© 3S-Smart Software Solutions

Der Begriff „Konfektionierung“ deutet bereits darauf hin, dass die Applikationsprogrammierung nicht mehr durch einen Software-Entwickler erfolgen muss. Vielmehr kann ein Technologe, ein Projektierer oder sogar ein Kundenberater die Projektierung vornehmen. Dazu muss er die Maschine und seine Funktion überblicken und verstehen – nicht aber gleichzeitig ein Software-Entwickler sein. Um das zu ermöglichen, werden die eingangs erwähnten Funktionseinheiten zu Modulen zusammengefasst, welche wiederum die Maschinen- und Anlagen­teile implementieren. Solche Module können einerseits mechatronische Komponenten sein, wie etwa Pneumatikzylinder, Werkzeugwechsler, Temperaturregler oder Zuführeinheiten. Andererseits aber auch Software-Funktionen wie Teileverwaltung, User Management oder Ablaufsteuerung. Das Entscheidende: Die Module enthalten alle Engineering-Aspekte von Codesys. Hierzu zählen:

■ IEC-61131-3-Programmcode für die Einheit in Form von Bibliotheken,
■ physikalische Ein- und Ausgänge, mit denen die Einheit kommuniziert,
■ Parametrierbarkeit von Werten, die abhängig vom Einsatz sind,
■ Visualisierungsmasken für die Inbetriebnahme oder Bedienung.

Der Anwender erstellt – respektive „konfektioniert“ – auf Basis dieser Module einen Modulbaum, der letztlich die Maschine abbildet. Dabei kennen die Module ihre eigenen Schnittstellen und wissen daher, an welcher Stelle im Baum sie einsetzbar sind. Mit anderen Worten: welche „Vater-Module“ beziehungsweise „Kinder“ sie haben können. Weil die Module ihre Beziehungen im Modulbaum kennen, ist auch die Konfiguration der Parameter auf das Nötigste reduziert und erfolgt direkt im Modulbaum-Editor. Mit einem grafischen Mapping-Tool kann der Anwender dann die von den eingesetzten Modulen „angeforderten“ Eingangs- und Ausgangsknoten komfortabel mit dem realen Prozessabbild verbinden. Erfordern Maschinen oder Anlagen für ihren Modulbaum eine zeitliche Ablaufsteuerung, so wird dieser Ablauf mit den „Programmsequenz-Modulen“ erstellt. Zur besseren Übersichtlichkeit steht dafür ein grafischer Sequenz-Editor zur Verfügung, der sich an DIN 66001/ISO 5807 orientiert.

Applikation auf Knopfdruck

Mit dem integrierten Mapping-Editor lassen sich die benötigten E/A-Variablen (links) komfortabel den im Prozessabbild bereitgestellten E/A-Kanälen (rechts) zuordnen.

© 3S-Smart Software Solutions

Per Kommando erzeugt ein integrierter Generator aus dem Modulbaum eine vollständige, strukturierte IEC-61131-3-Applikation inklusive Visualisierung. Diese Applikation kann von Codesys sofort übersetzt und auf die Steuerung geladen werden. Das bedeutet, dass der Anwender keine einzige Zeile Code selbst schreiben muss – sämtliche Informationen werden aus den Modulen und den dahinterliegenden Bibliotheken herangezogen und korrekt in die Projektstruktur eingebettet. Dabei ist der generierte Quellcode einsehbar, so dass bei Bedarf auch direkt im erzeugten Code editiert werden könnte.

Anwender haben auf diese Weise die Möglichkeit, das objektorientierte Code-Generierungskonzept nachzuvollziehen. Mit Start der Steuerung kommt die Applikation ohne weitere Schritte zur Ausführung.
Dieser Komfort setzt entsprechende Module voraus. Abgesehen von applikationsunabhängigen Modulen, die 3S standardmäßig zur Verfügung stellt (zum Beispiel für Zustandsmaschinen, zur Verwaltung persistenter Daten, für das Rezept-/Teileprogramm-Management oder auch das Alarm- und Fehlermanagement), werden Maschinen- und Anlagenbauer spezifische Module in aller Regel selbst erstellen – und zwar maßgeschneidert auf die jeweilige Applikation. Darüber hinaus werden Komponentenanbieter passende Module für ihre Produkte mitliefern, um ihren Kunden einen Teil des Aufwands ab­zunehmen.

Mit dem entsprechenden Application Composer Toolkit lassen sich solche spezifischen Modulbeschreibungen erzeugen. Mehr noch: Sogar der Generator, der aus den Modulen den Applika­tionscode im Strukturierten Text automatisiert erzeugt, kann den eigenen Bedürfnissen angepasst beziehungsweise erweitert werden. Das ist sinnvoll, wenn beispielsweise beim Generatorlauf zusätzliche Zusammenstellungen generiert werden sollen, wie etwa Informationen für das ERP-System oder eine Visualisierung außerhalb der SPS-Programmierumgebung.

Wird der Programmierer arbeitslos?

Damit stellt sich zwangsläufig die Frage, ob gut ausgebildete Applikationsprogrammierer durch Konzepte wie den Application Composer künftig arbeitslos werden. Mitnichten! Für Programmierer, die mit der bisherigen Programmierung der Serienmaschinen unterfordert waren, steigt sogar der Anspruch: Sie können sich auf die Entwicklung von Modulen und Systembausteinen konzentrieren und dabei ihr Potenzial voll ausschöpfen. In jedem Fall wird die Applikations­entwicklung effizienter, weil jeder im Projektierungsprozess eingebundene Entwickler sich auf seinen Bereich konzentrieren kann. Last but not least werden Fehler, die durch „copy&paste“ entstehen könnten, konzeptionell unter­bunden.

Autor: Roland Wagner ist Marketing-Manager bei der Firma 3S-Smart Software Solutions, Kempten.