Standardisierung der SPS-Software

Um das Ziel «Mehr Konfigurieren, weniger Programmieren» zu erreichen, werden standardisierte Vorlagen und Abläufe für alle Bereiche der Software vorausgesetzt. Dem entgegen steht der Grundsatz «Never Change a Running System». Dennoch stellt sich die CTE der Herausforderung sich stetig zu verbessern, um so dem Kunden ein Produkt zu liefern, das seine Anforderungen perfekt erfüllt.

In einer Welt stetig ändernder Anforderungen immer alles neu erfinden zu müssen, ist wenig effizient. Deshalb braucht es eine Grundlage, die die Mehrheit aller Anforderungen abdecken kann. Diese Vorlagen müssen so allgemein wie möglich, aber gleichzeitig so vielseitig wie nötig sein. Die CTE hat sich zum Ziel gesetzt, mit dem modularen Ansatz die Vorteile der objektorientierten Programmierung, die in anderen Softwarebereichen schon lange etabliert ist, auch auf SPS Ebene nutzen.

Obwohl bereits etliche SPS-Programme vorliegen, die seit Jahren zuverlässig produktiv im Einsatz sind, machte man bei der neuen Modularisierung vor nichts Halt. Jede Funktion, jeder Baustein, jedes Vorgehen wurde hinterfragt und auf seine Notwendigkeit sowie Tauglichkeit geprüft und beurteilt.

Das bewährte Vorgehen der CTE, eine Anlage in Grundfunktionen einzuteilen, ist perfekt für eine Modularisierung geeignet. Unabhängig von der tatsächlichen Funktion, sei es eine Druckregelung, eine Dosierung oder die Steuerung eines Heiz-/Kühlkreislaufs, sind grundlegende Eigenschaften jeder Grundfunktion immer identisch. Diese allgemeinen Signale werden hauptsächlich zur Kommunikation zwischen SPS, Visualisierung und Rezeptsteuerung eingesetzt. Die definierte Vorlage auf Seite des HMI garantiert identische Funktionalität bei unterschiedlichen SPS Typen. Da wir neuerdings vermehrt auch Kunden mit Controllern des Herstellers Allen-Bradley bedienen, floss das neue modulare System selbstverständlich auch bei dieser Softwarestruktur ein. Denn die Modularisierung ist herstellerunabhängig für alle SPS Typen gültig.

Was wurde standardisiert?

Fortschritte in den Entwicklungsumgebungen, wie beispielsweise dem TIA Portal von Siemens, bieten schon umfassendere Funktionen als ihre Vorgänger. Und da es nicht notwendig ist, das Rad neu zu erfinden, sparte man sich Aufwand und Zeit und bediente sich in den Systembibliotheken.

Für jeden Aktor und jeden Sensor wurde ein Vorlagendatentyp angelegt, der sowohl Daten als auch Funktionen beinhaltet. Beispielsweise enthält die Vorlage vom Typ Ventil Informationen zu seiner aktuellen Position, verknüpft diese mit den Steuerbefehlen aus HMI und programmierter Logik, und erzeugt mittels integrierter Intelligenz daraus ein Zustandsbild des Ventils inklusive Alarme.

Ebenso verhält sich der neu erstellte Datentyp Alarm. Er besitzt Eigenschaften wie Zugehörigkeit zur Prioritätsklasse, Zeitverzögerung und Quittierstatus. Damit lässt sich eine Anpassung wesentlich einfacher und schneller durchführen als, wenn ein Alarm nur aus der Eigenschaft aktiv/inaktiv bestehen würde. So benötigt neu eine Prioritätsänderung keinen Programmieraufwand, sondern eine Konfigurationsanpassung. Der bestehende Code muss dazu nicht angepasst, geladen und neu geprüft werden.

Immer wiederkehrende Daten wurden in einer Vorlage zusammengefasst. So beispielsweise der Zustand einer Grundfunktion (GFK) sowie deren Steuersignale vom HMI oder dem Rezepthandler. Egal, ob die Anlage eine oder zehn
GFKs hat: Wird ein zusätzlicher Wert benötigt, muss die Änderung lediglich an der Vorlage vorgenommen werden und alle Instanzen gleichen sich automatisch an.

Um die Durchgängigkeit von der Spezifikation über die Implementation bis zur Verifikation zu gewährleisten, bilden die Datenvorlagen die Struktur der spezifizierenden Projektunterlagen ab. Die Unterteilung der Parameter einer Grundfunktion in globale, fixe, maschinenspezifische oder variable Parameter aus der Software Design Spezifikation findet man Eins-zu-Eins auch in der Datenstruktur des Programms wieder. Sensoren, Aktoren und Alarme, die gemäss Dokumentation einer Grundfunktion zugeordnet sind, finden wir in der Datenstruktur der GFK.

Was hat der Kunde davon?

Durch die Standardisierung aller zusammengehörenden Elemente im Code wird das gesamte Programm für Menschen lesbarer, übersichtlicher und einfacher zu verstehen. Dies führt dazu, dass sich Programmierer ohne Vorkenntnisse der Anlage schneller im Code zurechtfinden. Dieser Vorteil zeichnet sich nicht nur einmalig während der Entwicklungsphase aus, sondern trägt auch im laufenden Betrieb dazu bei, neue Beteiligte schneller einzuführen und weniger Missverständnisse aufkommen zu lassen.

Die Wiederverwendbarkeit ermöglicht dem Kunden sowohl in der Neuerstellung als auch bei Anpassungen im späteren Betrieb eine Zeiteinsparung, da der Aufwand einer Konfigurationsänderung geringer ist, als der einer Programmieränderung. Ausserdem muss bei Erweiterungen nichts neu entwickelt und programmiert werden. Mit den bestehenden Vorlagen und Bibliotheksbausteinen sind bereits alle Grundlagen vorhanden.

Anpassungen sind aufgrund der funktionellen Vielfalt der Vorlagen oftmals eine Konfigurationsfrage. Da dazu kein Eingriff in den Code notwendig ist, sind Änderungen am produktiven System unkritischer und damit für den Kunden besser planbar.

Bei einem Wechsel des zuständigen Programmierers erfährt der Kunde nicht automatisch einen Wechsel des Programmierstils. Die Rahmenbedingungen garantieren eine personenunabhängige Struktur.

Da die modulare Struktur in der SPS nicht an eine bestimmte Programmierumgebung gebunden ist, bleibt für den Kunden die freie Wahl der Hardware. Die von der CTE eingesetzte Bedienoberfläche Zenon von Copa-Data bietet unabhängig der vom Kunden verwendeten SPS eine einheitliche Interaktionsebene für den Betreiber.

Was hat die CTE davon?

Jeder Vorteil für den Kunden ist ein Pluspunkt für die CTE. Wir sind immer nur so gut, wie das Produkt den Kunden zufriedenstellt. Neben dem grossen Mehrwert für den Kunden vereinfacht die Modularisierung auch die internen Arbeiten. Anstelle der aufwendig zu pflegenden Richtlinien und Anweisungen sprechen die Vorlagen und Bibliotheken für sich selbst. Startet ein neues Projekt, muss nicht erst in der Richtlinie nachgelesen werden, welche Datenbereiche, wofür angelegt werden müssen. Die Bibliothek stellt alles Notwendige zur Verfügung und erleichtert die Entwicklung von null an.

Optimierte Abläufe in der Programmierung und beim Testen garantieren weniger Fehler und damit weniger Aufwand in der Nachbearbeitung oder verhindern schlimmstenfalls sogar Reklamationen. Da sich die Datenstruktur der Spezifikation in der Software widerspiegelt, ist die Prüfung der Korrektheit schneller und zuverlässiger durchgeführt. Die Dokumentation der Tests führt den Prüfer automatisch an den richtigen Ort in der Software, langes Suchen oder Unsicherheit durch mehrfaches Auftreten von Parametern gehören der Vergangenheit an.

Wie geht es weiter?

Die positiven internen Rückmeldungen bei der Durchführung erster Projekte mittels des neuen Systems geben uns die Gewissheit, dass wir auf dem richtigen Weg sind. Unser Antrieb ist der Wille, uns stetig zu verbessern. Darum wird die Modularisierung sowohl auf SPS als auch auf HMI Ebene weiter vorangetrieben. Potenzial zur vereinfachten Programmierung und ebenso wichtig, komfortableres und zuverlässigeres Testen, ist noch immer vorhanden. Die Verifizierung der Korrektheit durch Code-Review ist eine weitere Möglichkeit, den Projektablauf zu optimieren. Doch dafür ist ein durchgängig modularer Aufbau Voraussetzung.

Ein erster Schritt ist getan, weitere werden folgen. Wichtig ist, dass die Richtung stimmt.