Die Frage, ob die klassische SPS-Programmierung ausgedient hat, ist auch eine Frage, die uns immer wieder beschäftigt. Es ist noch nicht so lange her, dass ich bei einer Podiumsdiskussion genau damit konfrontiert wurde. Auch wenn heute mehr Softwarearchitekten im Maschinen- und Anlagenbau von ihrer Ausbildung her die Vorteile der Hochsprachen sowie der objektorientierten Programmierung (OOP) kennen und nutzen, so müssen wir auch die andere Seite berücksichtigen: Da sind Maschinenbauer, Anwendungsexperten und Technologen, die ihren Prozess im Blick haben. Damit kennen sie sich aus!
Die Software-Applikation, um den gewünschten Ablauf zu realisieren, ist für sie ein Vehikel, um ihre Ziele zu erfüllen. Für solche Experten ist es wichtig, dass sie Tools an die Hand bekommen, mit denen sie ihr Ziel möglichst schnell und einfach realisieren können. Die IEC 61131-3 als Basisnorm für solche Anforderungen hat sich etabliert, weil sie diese Anforderungen umsetzt und gleichzeitig die Abhängigkeit von Einzelanbietern aufbricht. Nicht jeder Maschinenbauer oder Automatisierer muss ein begnadeter Programmierer sein. Natürlich wird auch nicht mehr jeder Technologe selbst programmieren, sondern die Aufgabe teilweise an erfahrene Applikationsentwickler weitergeben, die dann auch über Hochsprachenerfahrung verfügen. Aber hierbei ist es wichtig, eine Kommunikationsgrundlage zu bieten, die beide Seiten verstehen. UML (Unified Modeling Language) integriert im SPS-Programmiertool könnte so eine Grundlage darstellen.
Und dann sind da nicht zuletzt die Inbetriebnehmer und Servicetechniker, die vor Ort in der Lage sein müssen, eine Maschine so zu konfigurieren, dass sie den Anforderungen des Kunden entspricht. Tools wie Lasal oder Codesys machen es ihnen leicht. Eine Hochsprachen-Entwicklungsumgebung ist da ungleich schwerer zu verwenden und zu warten; auch kann man damit im Worst Case viel mehr Schaden anrichten. Für diese Gruppe sind grafische Programmiersprachen, wie beispielsweise der Kontaktplan, die Ablaufsprache oder verschiedene Dialekte des Funktionsplan ein Segen, weil sie ihnen Ablauf oder Logik sehr übersichtlich darstellen.
Für uns als Hersteller von Codesys und damit einer geräteunabhängigen Programmierumgebung besteht die Herausforderung darin, beide Seiten gleichermaßen gut zu bedienen: Einerseits die erfahrenen Hochsprachenprogrammierer, die mit ST (Structured Text) innerhalb der IEC 61131-3 gut klarkommen, die OOP schätzen und damit unter anderem Systemfunktionen realisieren. Diese Funktionen können sie komfortabel vererben oder in Bibliotheken kapseln. Gerade für die Anforderungen durch Industrie 4.0 wird man diese Denke auch brauchen. Andererseits gibt es eben die Anwendungsspezialisten, denen Begriffen wie „Polymorphie“, „dynamisches Linken“ oder „Casts“ fremd sind. Viele Codesys-Anwender nutzen heute die OOP, ohne das zu wissen oder zu merken: Die entsprechende Funktionalität wurde von der ersten Gruppe so in Bibliotheken gekapselt, dass die Anwender funktional, also „klassisch“ darauf zugreifen und sie verwenden. Und zwar in jeder der IEC 61131-3 Programmiersprachen!
In jedem Fall brauchen wir eine Weiterentwicklung der „klassischen“ Programmierumgebungen. Einerseits um den Anforderungen an Flexibilität, Erweiterbarkeit und Mächtigkeit beim Engineering gerecht zu werden. Andererseits werden aber zukünftig Softwareentwickler nur mit modernen Tools auch gerne in der Automatisierungstechnik arbeiten. Schließlich werden Maschinen und Anlagen immer komplexer - die größte Wertschöpfung liegt in der Software! Mit modernen Tools, die beide Seiten der Automatisierung gleichermaßen abdecken, können wir junge Leute motivieren, ihr Software-Knowhow einzubringen und damit dem Fortschritt zu gewährleisten. Dazu gehören integrierte Zusatztools, um wiederkehrende Aufgaben wie die Überprüfung des Applikationscodes nach dem Vier-Augen-Prinzip oder das Testen von Routinen automatisieren zu können – bis hin zu Continous Integration Prozessen, wie man sie in der Hochsprachenprogrammierung kennt.
