Programmierung auf dem Prüfstand

Die SPS wird 40 Jahre alt. Im Laufe dieser Zeitspanne haben sich die Anforderungen insbesondere an die Software grundlegend geändert und es stellt sich die Frage: Ist die gängige, zyklusorientierte SPS-Programmiersprache noch zeitgemäß oder wäre eine prozessorientierte Hochsprache mit Multitasking die bessere Wahl?

Die SPS wird 40 Jahre alt. Im Laufe dieser Zeitspanne haben sich die Anforderungen insbesondere an die Software grundlegend geändert und es stellt sich die Frage: Ist die gängige, zyklusorientierte SPS-Programmiersprache noch zeitgemäß oder wäre eine prozessorientierte Hochsprache mit Multitasking die bessere Wahl?

Sprichwörtlich im Kern hat sich die Steuerungstechnik in den zurückliegenden vier Jahrzehnten nur unwesentlich verändert. Auch wenn es teilweise übergeordnete Schichten gibt, die den Schein von Parallelverarbeitung haben, oder in den tieferen Schichten der Echtzeit-Betriebssysteme Multitasking-Mechanismen aktiv sind – das zyklische Abarbeiten der Programme durch die SPS-Betriebssysteme ist immer noch Stand der Technik! Echtes ablauforientiertes und damit prozessnahes Multitasking ist in der Welt der SPS-Steuerungen hingegen selten zu finden. Dabei entsprechen die hinter diesen Prinzipien stehenden Mechanismen viel eher dem natürlichen Ablauf der Prozesse in den heutigen Maschinen und Anlagen, bei denen komplexe Disziplinen wie Regelungen, Achspositionierung, Netzwerk-Handling, Kommunikation und Datenverwaltung mit gemischten Datentypen mittels einer Steuerung zu lösen gilt. Neben den klassischen Maschinenzyklen finden sich hier eine Menge weiterer Prozesse, welche immer parallel und in den meisten Fällen völlig autark ablaufen. Häufig sind die Anlagen vernetzt und an ein SCADA-System angeschlossen, welches die Daten der verschiedenen Steuerungen in den Anlagen verarbeitet.

Angesichts dieser Entwicklung muss es vorrangiges Ziel sein, dass der Anwender für all diese Aufgaben dieselbe Programmiersprache verwenden kann. Gerade für den OEM-Anlagenbauer ist es zudem elementar, dass er kundenspezifische Anpassungen mit geringem Aufwand realisieren kann. Dafür eignet sich eine objektorientierte Vorgehensweise sehr gut – einmal angelegte Objekte lassen sich in weitere Projekte „vererben“ und auch erweitern (siehe Kasten).

Ingenieure der heutigen Generation, welche eine klassische Hochsprache wie C++ oder Java beherrschen, legen eine von der Hardware losgelöste Datenstruktur an und sind es nicht gewohnt, dass sie sich um den Aufbau des geräte-internen Speichers kümmern müssen. Auch das Anlegen von Datenstrukturen oder Arrays ist bei Hochsprachen eine Selbstverständlichkeit. Bei den aktuellen komplexeren Automatisierungslösungen ist dies ebenso ein Muss, um vernünftige und gut lesbare Programme erstellen zu können. Gerade für Positionieraufgaben sind indizierte Arrays sehr hilfreich, da mit einem einzigen Move-Befehl ganze Datensätze abgefahren werden können. Mit anderen Worten: Wo bislang lange Variablen-Zuweisungen im Deklarationsteil zu finden waren, sind es beim Arbeiten mit indizierten Arrays gerade mal ein paar Zeilen, um beispielsweise mehrere Produkte oder Werkstückträger zu definieren – egal wie viele Parameter ein Produkt bestimmt.

Wenn wir schon beim Beispiel Produkt sind: Es ist außerdem sinnvoll, eine Struktur in ein Array einzubinden, in der neben Zahlenvariablen wie Integer, Float, Real oder Bool auch Strings (Zeichenketten) zur Beschreibung des Produktnamens Verwendung finden. Doch damit nicht genug: Was nützt die beste Programmiersprache, wenn das Debugging sich schwierig bis unmöglich gestaltet? Ergo sollte ein modernes Tool diesbezüglich mit Breakpoints, Trace-Funktionen und Variablen-Setup dem Programmierer die benötigten Hilfsfunktionen bieten.