Im Jahr 1969 kamen die ersten SPSen auf den Markt. Deren Programme wurden anfänglich mit speziellen Tools erstellt, die der speziellen Herangehensweise der Hersteller beziehungsweise der ihrer Kunden entsprach. Zu diesem Zweck gab es eigenständige Programmiergeräte mit ganz unterschiedlichen Sprachen, angelehnt an Assembler-Dialekte oder die grafische Abbildung von diskreten Verschaltungen. Spätestens in den 1990er Jahren haben sich PCs als Plattform für diese Tools durchgesetzt.

Mit der Festlegung und der sukzessiven Einführung der IEC 61131-3 als übergreifender Norm im Jahr 1992 begann ein neues Zeitalter. Durch die standardisiere SPS-Programmierung konnten Firmen wie 3S-Smart Software Solutions herstellerunabhängige Tools entwickeln. Mit der Anbindung dieser Software-Systeme an ihre Geräte lagern die SPS-Hersteller die Verantwortung für die Programmier-Software aus und partizipieren an der Weiterentwicklung der Tools. So ist es nicht verwunderlich, dass die meisten Steuerungshersteller mittlerweile solche Tools einsetzen und sich auf die Geräte-Entwicklung konzentrieren.

Auch für die Anwender der Programmiersysteme wurde durch die IEC 61131-3 die Arbeit einfacher. Die Syntax und Semantik der fünf in der Norm de­finierten Programmiersprachen ist vereinheitlicht – egal ob es sich um An­weisungsliste (AWL), Funktionsplan-Diagramm (FUP), Kontaktplan (KOP), Ablaufsprache (AS) oder Strukturierter Text (ST) handelt. Wichtigster Vorteil für die Anwender: Beherrscht ein SPS-Programmierer die IEC 61131-3, dann wird er sich in jedem kompatiblen System schnell zurechtfinden. Natürlich gibt es Unterschiede im Handling und Funktionsumfang der Tools. So muss nicht jede Sprache implementiert sein, um IEC-61131-3-konform zu sein. Weitere, im Rahmen einer „Compliance List“ dokumentierte Abweichungen vom Standard sind zugelassen. Der Austausch und die Wiederverwendung von Programmcode zwischen den Tools verschiedener Hersteller zumindest in den textuellen Sprachen sind vergleichsweise einfach. Abhängigkeiten von einem einzigen Gerätehersteller sind damit aufgebrochen. Und das ist ein weiterer großer Vorteil für die Anwender.

Einen Wunsch der Anwender konnte die Norm jedoch nicht erfüllen: die Programmierbarkeit jeder kompatiblen Steuerung mit jedem verfügbaren IEC-61131-3-Tool. Bei genauerer Betrachtung wird klar, dass dieses hehre Ziel aus technischen und politischen Gründen kaum zu erreichen ist. Mit der Verbreitung etwa von Codesys als Programmier-Software für mittlerweile viele Hundert unterschiedliche programmierbare Automatisierungsgeräte kommt man der Erfüllung dieses Wunsches aber recht nahe.

Integrierte Automatisierung

Codesys war eines der ersten SPS-Entwicklungssysteme, das neben der reinen Programmierung auch weitere Aspekte der Automatisierung in einer Oberfläche abdeckt. Schließlich muss jede Maschine oder Anlage nicht nur gesteuert, sondern auch bedient werden – mit Bedienpanels oder Visualisierungen auf Industrie-PCs. Und jede SPS hat Eingänge und Ausgänge, die entweder diskret oder via Feldbus eingebunden sind. Weiterhin haben Greifer oder Fräser in Maschinen oft komplexe Kurven abzufahren. Und nicht zuletzt führen aufgrund der gesetzlichen Vorschriften Sicherheitsbetrachtungen zum Einsatz von sicheren Sensoren und Aktoren, deren Logik heute ebenfalls zunehmend durch intelligente Geräte abgearbeitet wird.

Integrierte Automatisierung: SPS-Programm, E/A-Mapping der Feldbus-Konfiguration, Visualisierung und CNC-Editor teilen sich einen einheitlichen Variablenraum – der Zugriff erfolgt jeweils in der gleichen Infrastruktur.

© 3S Smart Software Solutions

Für SPS-Hersteller und Anwender ist es ein deutliches Plus, wenn das eingesetzte SPS-Entwicklungssystem durchgängige Arbeitsabläufe für typische Aufgabenstellungen mit einer Oberfläche ermöglicht. – Ein Anwendungsszenario:

Eine Sondermaschine wird mit einer SPS gesteuert, deren Ein- und Ausgänge über Ethercat angebunden sind. Der Maschinenführer bedient und überwacht den Betrieb über ein an die SPS angeschlossenes Bedienpanel. Früher waren zur Realisierung dieser Aufgabenstellung ganz unterschiedliche Tools erforderlich: zunächst ein Feldbus-Konfigurator für die Bus-Parameter und zur Definition der verfügbaren Ein- und Ausgänge. Dann natürlich das SPS-Programmiersystem zur Projektierung der Steuerungsapplikation und die Entwicklungsumgebung für die Bedienoberfläche.

Mit einem integrierten IEC-61131-3-Entwicklungssystem wie Codesys ist heute die gesamte Aufgabenstellung unter einer Oberfläche realisierbar. So enthält das Tool neben den Programmier-Editoren auch einen Visualisierungseditor und Ethercat-Konfigurator. Aufgrund der Leistungsfähigkeit aktueller Prozessoren können Steuerung und Visualisierung auf einem einzigen Gerät erfolgen. Der Anwender ersetzt SPS und Bedienpanel durch solch eine Panelsteuerung und reduziert Engineering-Aufwand und Hardware-Kosten für seine Maschine.

Nach der Integration eines Portalsystems kann auch noch die Projektierung dafür in der gleichen Oberfläche erfolgen. Und ergibt eine Risikoanalyse, dass die neuen, bewegten Teile der Maschine den Einbau von Sicherheitskomponenten erfordern, so kann die Projektierung ebenfalls integriert im SPS-Programmiersystem geschehen. Hardwareseitig muss dazu lediglich ein nach IEC 61508/ SIL3 zertifiziertes Safety-Modul mit sicheren E/A-Modulen im Ethercat-Netzwerk verbaut und verdrahtet werden.

Kurzum: Der Gerätehersteller der Panelsteuerung profitiert durch die einfache Erweiterbarkeit seines Systems und der Anwender von der Konfiguration und Programmierung der Funktions- und Sicherheitsapplikation innerhalb einer Oberfläche.

Aus SPS-Programmierung wird Software-Entwicklung

Das beschriebene Szenario macht deutlich, dass in der Automatisierung immer der gesamte Prozess im Mittelpunkt steht. Aufgrund der Vernetzung und der zunehmenden Komplexität der Maschinen- und Anlagenteile ähnelt die Arbeit des SPS-Programmierers immer mehr der Software-Entwicklung von Desktop-Anwendungen. Der Schwerpunkt bei den Programmiersprachen hat sich dabei eindeutig von AWL oder FUP zu ST verschoben. Und mit der Aufnahme der objektorientierten Programmierung (OOP) in die IEC 61131-3 im Frühjahr 2013 wurde der Weg für diese mächtige Erweiterung bereitet. Angesichts der Tatsache, dass nahezu alle angehenden Ingenieure, Informatiker und Techniker heute OOP in ihrer Ausbildung lernen, war dies ein naheliegender Schritt.

Erweiterbarkeit der IEC-61131-3-Plattform mit Plug-Ins, Beispielen und Modulen aus einer integrierten App-Shop-Plattform.

© 3S Smart Software Solutions

Ein weiterer Blick über den Tellerrand auf die Arbeit von Entwicklern für PC-Software zeigt, dass hier weitere Hilfsmittel zum Einsatz kommen, die auch für den Entwickler von Automatisierungsapplikationen sehr hilfreich sein können. So ist die Erstellung von größeren Software-Projekten kaum noch allein und ohne Versionsverwaltung zu bewerkstelligen. Zusätzliche Softwaretools wie Apache Subversion sind weit verbreitet und ihr Nutzen hat sich mittlerweile auch unter Automatisierern herumgesprochen. Was also liegt näher, als die Anbindung direkt in der Oberfläche eines IEC-61131-3-Entwicklungssystems vorzunehmen? Mit Codesys SVN ist genau das möglich: Das Projekt wird objektweise in der Versionsverwaltung hinterlegt; mehrere SPS-Programmierer können somit auf ein und demselben Projekt an unterschiedlichen Objekten arbeiten, ohne sich in die Quere zu kommen. Zusätzlich lassen sich Versionsstände des Gesamtprojektes definieren, kommentieren und jederzeit wieder abrufen.

Eine weitere Funktionalität der Software-Entwicklung, von der heute SPS-Programmierer profitieren möchten, ist die statische Analyse des Programmcodes auf potenzielle Fehler. Auch wenn das Programm syntaktisch korrekt ist, können während der Programmierung Fehler oder Unsauberkeiten eingeflossen sein, die bei der Inbetriebnahme der Maschine oder Anlage zu Problemen führen. Das kann zum Beispiel Programmcode sein, der nie durchlaufen wird, ein mehrfacher Schreibzugriff auf Ausgänge des E/A-Systems oder aber deklarierte Variablen, die nie verwendet werden. Solche und viele weitere Fehlerquellen müssen zwar nicht zwangsläufig Programmierfehler sein; sie könnten aber zu unerwünschtem Verhalten der Maschine führen. Mit einem integrierten Zusatztool wie Codesys Static Analysis sind derartige Prüfungen innerhalb des IEC-61131-3-Programms durchführbar und können damit zur Sicherung der ausgelieferten Qualität beitragen.

Apropos Qualitätssicherung: Zur Entwicklung nach dem V-Modell verwenden Hochsprachenprogrammierer Softwaretools zum automatisierten Testen des Codes. Den SPS-Programmierern steht heute mit dem Codesys Test Manager ein vergleichbares integriertes Zusatztool zur Durchführung von Inte­grations-, System- und Regressionstests zur Verfügung. Damit werden Testabläufe von der Oberfläche automatisiert abgearbeitet. Darüber hinaus können Anwender oder Gerätehersteller einzelne Programmbausteine mit speziellem IEC-61131-3-Testcode als so genannte Unit Tests prüfen.

Von der Programmierung zur modulbasierten Entwicklung

Mit der steigenden Komplexität der Automatisierungssysteme und der erforderlichen Software zur Realisierung steigen die Schwierigkeiten, diese Abläufe zwischen Technologen und Programmierern auszutauschen. Überspitzt gesagt: Der Technologe denkt in seinem Prozess, der Programmierer in seinen Algorithmen. Als Kommunikationsmedium, das mittlerweile beide Seiten beherrschen, hat sich UML etabliert. So bildet ein Maschinenbauer die Prozessschritte seiner Maschine in einem UML-Zustandsdiagramm ab, das wiederum der Programmierer für die Codierung der SPS-Ap­plikation verwendet. Wenn das Zustandsdiagramm selbst bereits zum Programmbaustein wird, entfällt sogar das Nach-Codieren. Das Zustandsdiagramm sollte dazu direkt im SPS-Programmiersystem integriert sein. Im konkreten Fall von Codesys UML unterstützt das entsprechende Werkzeug nicht nur die modellbasierte Entwicklung von Abläufen, sondern auch die Beherrschung der Applikationskomplexität mit Hilfe des UML-Klassendiagramms. Insbesondere für objektorientiert programmierte Bausteine und Projekte erhöht es die Übersichtlichkeit der Abhängigkeiten ganz enorm. 

Im UML-Klassendiagramm kann der Anwender die Aufrufhierarchie seiner Programmbausteine grafisch planen beziehungsweise darstellen.

© 3S Smart Software Solutions

Man könnte nun fälschlicherweise zu dem Schluss gelangen, dass die Programmierung zukünftig für SPS-Spezialisten zu komplex und kaum noch durchführbar ist. Jedoch zeichnen sich bereits eine Reihe von Lösungen ab, die solche Komplexität in Modulen zusammenfassen und dann vom Anwender deutlich einfacher verwendet werden können. Die Idee ist, dass diese Module ihre Funktion kapseln: Sie enthalten neben dem komplexen Programmcode sämtliche erforderlichen Informationen für mechatronische oder logische Einheiten. Diese Module werden typischerweise von Software-Entwicklern mit den genannten Hilfsmitteln erstellt und als Baukasten bereitgestellt. Daraus erstellen die Anwender ihre gesamte Applikationen, ohne selbst wirklich zu programmieren.

Aus der komplexen Software-Entwicklung wird somit eine modulbasierte Applikationsentwicklung, die wieder überschaubarer und auch für Technologen beherrschbarer wird. Integriert in der IEC-61131-3-Oberfläche, zeigt ein Tool wie der Application Composer den da­raus erzeugten, komplexen Applikationscode sogar transparent an. Dabei ist vorstellbar, dass die modulbasierte Zusammenstellung der Applikation rein grafisch erfolgen kann. Eventuell sogar mit Modulen, die online verfügbar sind – zum Beispiel in App-Shops für solche Automatisierungssysteme. Das „Internet der Dinge“ ist somit bereits in die Automatisierungstechnik eingezogen.

Autor: Roland Wagner ist Leiter Produkt-Marketing bei 3S-Smart Software Solutions, Kempten.