Framework eines SPS-Programms: Schematisch dargestellt sind die üblicherweise vorhandenen Bestandteile eines SPS-Programms sowie jeweils der Aufwand für deren Erstellung.

Die modulare Software setzt sich letztlich aus vielen einzelnen Modulen zusammen, deren Gesamtheit das fertige SPS-Programm ist. Durch hinzufügen oder entfernen einzelner Module können Optionen und Varianten von Maschinen abgebildet werden. Module eines gewissen Typs sind durch kompatible Module austauschbar, ohne andere Module zu beeinflussen. Nicht zuletzt können Software-Module aus beliebig viel oder wenig Programm bestehen, sie setzen sich aber in aller Regel aus bereits vorhandenen Standardbausteinen zusammen.

Eingebettet werden die Module in ein allgemeingültiges Framework (siehe Bild 1), das für alle Steuerungen in der Anlage immer gleich ist. Sozusagen auf dem Grund des Frameworks befinden sich die SPS-Verwaltung (Diagnose, Wiederanlauf/ Neustart, Taktmerker, universeller Programmverteiler etc.) und die allgemeine Steuerungsverwaltung (Sicherungsüberwachung, Steuerspannungsüberwachung etc.). Diese sind noch sehr unabhängig von der zu steuernden Maschine und eher auf die spezielle Steuerung zugeschnitten (zum Beispiel eine S7-300 oder S7-400 mit Profibus/ Profinet-Anschluss). Auf der Steuerungsverwaltung setzen die hardwarenahen Anteile der Software auf, welche die Schnittstelle zwischen der gegebenenfalls spezifischen Hardware und der idealerweise unabhängigen Software darstellen. Die nächste Schicht bilden die maschinennahen Anteile, in denen beispielsweise Umrichter-Ansteuerungen oder Parametrierungen vorgenommen werden.

Ausprägung von Software-Modulen in einem SPS-Framework: Die Module erstrecken sich üblicherweise über mehr als eine Ebene im SPS-Programm.

Die darauf aufsetzenden funktionalen Anteile realisieren die definierten Funktionen der Maschine und interagieren – falls nötig – mit übergeordneten, prozessbezogenen Anteilen. Die individuellen Anteile bilden schließlich einen möglichen Rest ab, der, wenn auftrags- oder anlagenabhängig, immer individuell zu realisieren ist. Zur Abbildung der Maschine mit Varianten und Optionen müssen sämtliche Software-Module so gestaltet sein, dass diese alle benötigten Ebenen aus dem geschilderten formalen Aufbau abbilden. Über die Ansicht des formalen SPS-Programmaufbaus lässt sich nun eine Modul-Ansicht (siehe Bild 2) legen: Es gibt Module für den – immer gleichen – Maschinenkern, Module für Varianten und Module für Optionen. Während Module für Optionen und Varianten austauschbar sind und sich beliebig einsetzen oder entfernt lassen, sind die Module für den Maschinenkern immer vorhanden. Ein besonderes Merkmal ist, dass sich ein Modul über alle Ebenen des SPS-Programms erstrecken kann, oftmals sogar muss. Der Grund dafür ist einfach: Wird beispielsweise eine Option eingebaut, ist sie in der Regel mit entsprechender Sensorik und Aktorik ausgestattet (hardwarenahe Anteile). Diese Option ist üblicherweise standardisiert zu behandeln (maschinennahe Anteile) und hat eine festgelegte Funktionalität (funktionale Anteile), die eventuell mit einem übergeordneten Prozess interagieren muss (prozessbezogene Anteile). Kurzum: Ein komplettes Modul muss in der Lage sein, alle diese Ebenen abzudecken.

Gestaltet man die Modularisierung iterativ, kann ein Optionsmodul wiederum aus mehreren Submodulen bestehen. Im Rahmen dieser Submodule ließen sich die Ebenen auch isoliert betrachten. Allerdings ist hier eine gewisse Vorsicht geboten, denn das System wird schnell unüberschaubar.

In der Praxis hat sich folgende Umsetzung als zielführend herausgestellt: Standardfunktionen in Form von Programm-Bausteinen sind ein Modul im SPS-Framework, sie werden dort zentral gepflegt und stehen automatisch für alle anderen Module zur Verfügung. Ein spezielles Funktionsmodul besteht aus EA-Rangierung (falls möglich mit Festadressierung), maschinennaher Ansteuerung (durch Anwendung der bereits im Framework enthaltenen Bausteine), aus funktionalem Kern und gegebenenfalls aus der Interaktion mit dem übergeordneten Prozess. Somit ist eine Option ebenso wie ein Modul aus dem Maschinenkern sauber mit wenigen Programm-Bausteinen abgebildet. Im prozessbezogenen Anteil des Maschinenkerns wird dafür gesorgt, dass das SPS-Programm im Idealfall selbst erkennt, welche Optionen und Varianten installiert sind, und sich entsprechend zur Laufzeit selbst konfiguriert. Dies hilft, den individuellen Programmanteil zu minimieren und erhöht gleichzeitig die Effizienz der Verwendung von Modulen.

Die Verwaltung der Module

Eine Kernaufgabe bei der Umsetzung der Modularisierung ist die Verwaltung der Module. In einem modernen Engineering-Prozess reicht es nicht aus, verschiedene Module unkoordiniert auf diversen lokalen Rechnern abgelegt zu haben. Eine zentrale Datenhaltung ist unabdingbar, damit alle beteiligten Mitarbeiter Zugriff auf die Modul-Datenbasis haben. Hier bietet sich auf jeden Fall der Einsatz eines Versionsverwaltungstools an, das die Aufgaben der Datenhaltung, Versionierung und Dokumentation übernehmen kann. Allerdings gibt es ein solches Tool kaum von der Stange und auch die etablierten Systemlieferanten bieten solche, auf die Praxis zugeschnittenen Lösungen nicht an. Und wenn doch, so sind diese Tools meist zu mächtig und zu kompliziert zu bedienen oder sie genügen nicht den Anforderungen, um effizient mit ihnen umgehen zu können.

Modul-Übersicht im Verwaltungstool: Alle relevanten Modul-Informationen sind kompakt dargestellt und direkt abrufbar.

Ergo hat sich Siempelkamp dazu entschlossen, in Eigenregie ein einfaches Tool zur Modulverwaltung zu erstellen. Das Resultat ist ein kleines lokal installiertes C#-Programm, das eine Bedienoberfläche abbildet, über die dann eine SQL-Datenbank gespeist beziehungsweise abgefragt wird. Der Aufwand für die Erstellung des Tools lag bei rund 100 Mann-Stunden, wobei ein gewisses Basiswissen hinsichtlich C# und SQL vorhanden sein sollte. Die Versionsverwaltung funktioniert dabei wie folgt: Fertige Module werden in Form von komprimierten Dateien über eine entsprechende Bedienoberfläche in ein Repository geschrieben. Das Modul muss über dieses Tool beschrieben und die Version dokumentiert werden. Ist ein Modul „eingecheckt“, lassen sich alle relevanten Bestandteile des Moduls selbst nochmals einzeln versionieren, beschreiben und dokumentieren. Besteht ein Modul aus verschiedenen Programm- und Datenbausteinen, ist einmal das Modul selbst und im zweiten Schritt jeder Programm- und Datenbaustein genauestens dokumentierbar. Weil nur komprimierte Dateien verwaltet werden und das Tool keine herstellerspezifischen Formate erwartet, können alle Arten von SPS-Code, Dokumenten oder Visualisierungsapplikationen verwaltet werden. Und indem es dafür sorgt, dass alle Versionen eines Moduls verfügbar sind, lassen sich Änderungen auch nach Jahren noch nachvollziehen.

Im Rahmen der Programm-Erstellung werden die benötigten Module auf den lokalen Rechner kopiert und daraus der Code zusammengesetzt. Somit ist gewährleistet, dass jeder Programmierer immer mit dem letzten aktuellen Stand arbeitet. Über eine Rechteverwaltung lässt sich zudem gewährleisten, dass nur bestimmte Personen neue Versionen oder komplett neue Module einstellen können.

Die Grenzen der Modularisierung

Bei Siempelkamp hat sich der Aufwand für die Modularisierung klar gerechnet. Es gibt aber auch Branchen und Bereiche, wo ein solches Konzept schnell an die Grenzen stößt und kaum Vorteile bringt:

Pures Individual-Engineering

Wer im Rahmen der SPS-Programmierung mit ständig wechselnden Aufgaben betraut ist – also nicht an bestimmte Maschinen oder Anlagentypen gebunden ist –, kann die Modularisierung auf einem nur sehr niedrigen Niveau betreiben.

Mangelnder Wiederholungsgrad

Dokumentation von Elementen innerhalb eines Moduls: Jedes Element in einem Modul wird einzeln aufgeführt, dokumentiert und versioniert. Elemente können beliebig benannt und somit auch hersteller- und systemunabhängig gepflegt werden.

Bei zu geringer Wiederholungsfrequenz ist kein vernünftiger ROI zu erzielen. Die vorbereitenden Maßnahmen stehen dann in keiner Relation zum Nutzen. Für die MDF-Streumaschine kann man in Summe von rund 1000 Mann-Stunden für die vorbereitenden Schritte ausgehen; weitere 500 Stunden wurden in das Redesign der Software investiert. Angesichts solcher Zahlen war in diesem konkreten Beispiel erst ab der fünften Anlage ein Erfolg spürbar.

Ständig wechselnde Kunden-Anforderungen

SPS-Code-Customizing erfordert ständiges Redesign. Dies ist konträr zum Gedanken modularisierter Software. Zudem erfordert funktionierende Modularisierung eine entsprechende Abbildung in Code und Daten, welche eher selten in Kunden-Anforderungen zu finden ist.

Eher praktische Grenzen setzen die aktuellen Entwicklungssysteme und Programmier-Plattformen der Systemhersteller. Bei einigen Herstellern ist ein partieller Import oder Export von Programmcode nur eingeschränkt oder gar nicht möglich, bei anderen kann unter Umständen das fertige Programm nicht mehr konsistent sein. Bibliotheken werden zurzeit von keinem Hersteller wirklich unterstützt. Beispielsweise lässt sich Programmcode in einer Bibliothek oft aus Konsistenzgründen nicht editieren, die Konsistenz ergibt sich erst später im fertigen Programm.

Eine Übernahme des modularen Ansatzes für die Bedien- und Beobachtungssysteme wäre konsequent, scheitert aber gleichermaßen daran, dass ein programmgestützter, modularer Aufbau von Visualisierungsbildern aus separaten grafischen Objekten nicht hinreichend unterstützt wird.

Die nächsten Schritte

Das Konzept der Modularisierung und Standardisierung der SPS-Software hat Siempelkamp zunächst an einem bestimmten Maschinentyp – der besagten Faser-Streumaschine – entwickelt und erprobt. Oberstes Ziel für die Zukunft ist, diesen Ansatz auch in allen anderen Anlagenbereichen umzusetzen. Frei nach der „80/20-Regel“ sollten dann rund 80 % aller Anlagen oder aber 80 % jeder Anlage durch modulare Software abbildbar sein. Mit den restlichen 20 % wird man leben müssen, da hier der Aufwand schlichtweg in keiner Relation mehr zum Nutzen steht.

Weiteres Potential verspricht die Nutzung moderner Engineering-Tools (zum Beispiel ePlan eec), um aus vorhandenen Modulen automatisiert die richtige Software – und selbstverständlich auch die Hardware – zu erstellen. Nicht zuletzt besteht ein langfristiges Ziel in der automatisierten Erstellung der passenden, modularen HMI-Applikationen. Allerdings mangelt es heutzutage insbesondere an den Möglichkeiten der Systemlieferanten, denn noch lange nicht ist es mit jedem System machbar, einzelne Bilder und Daten isoliert aber konsistent zu extrahieren oder diese über entsprechende Beschreibungssprachen zu generieren.

Autor

Jörg Jaschke ist Leiter Prototyping, Standardisierung und Entwicklung Automatisierungstechnik bei der Firma Siempelkamp, Krefeld.