SPS-Programmierung : Objektorientierte Programmierung und Zustandsmaschinen im TIA-Portal

Das TIA-Portal von Siemens hat sich mittlerweile als Standard für die SPS-Programmierung etabliert. Mit der Einführung der TIA-Programmierumgebung erhebt sich für viele Anwender auch die Frage: Was tun mit den alten, im Simatic-Manager verfassten Programmen? Wie fängt man am besten an, um die TIA-Eigenschaften gut auszunutzen und auch für zukünftige Entwicklungen gut gerüstet zu sein? Wie erreiche ich eine Standardisierung mit einem ausgewogenen Verhältnis von Aufwand und Wiederverwendbarkeit?

Die Antworten auf diese Fragenstellungen sind im Detail unterschiedlich – aber sie sind umso leichter zu finden, je allgemeiner und klarer der Ansatz zur Lösung ist. Dies soll an Hand eines Beispiels Schritt für Schritt veranschaulicht werden.

Objektorientierte Programmierung ist ein bewährtes und gängiges Konzept im Bereich der Hochsprachen wie z.B. C++ oder Python. Obwohl standardmäßig nicht formal im TIA-Portal enthalten können hier doch wesentliche Eigenschaften der Objektorientierung und deren Vorteile realisiert und ohne Kenntnis einer objektorientierten Hochsprache zum Einsatz gebracht werden. Ein Objekt ist definiert durch

• Objekt-Daten
• Methoden (wie die Objektdaten verarbeitet werden)
• Die Zugehörigkeit zu einer Objekt-Klasse (Objekt-Instanzen mit gleichen Eigenschaften, z.B. Motor mit einer Drehrichtung)

Zustandsmaschinen sind eine Form der Codierung die sich sehr gut für Objekt-Methoden, d.h. die Erfassung der grundlegenden Funktionen eines Objekts eignen. Grundlegende Funktionen beinhalten dabei z.B. die Signalverarbeitung, die Schnittstelle zu einer Visualisierung (HMI), Alarmierung, Software-Schnittstelle zu anderen Objekten bzw. Programmen. Als Programmiersprache kommt hier vorzugsweise SCL zum Einsatz.

Betrachten wir das ganze an Hand eines einfachen Beispiels: In einer Anlage gibt es Motore für Pumpen und für Schleusentore. Dabei handelt es sich um Asynchronmotore, der Einfachheit halber ohne Frequenzumformer oder Servo. Für die Motore gibt es für Servicezwecke einen Vor-Ort Tippbetrieb, im Handbetrieb können die Motore Vor-Ort oder über Bildschirm gestartet werden. Im Automatikbetrieb erfolgt die Ansteuerung über eine Ablaufsteuerung (diese wird im Beispiel nicht weiter behandelt, ebenso wie der sicherheitsgerichtete Teil der Steuerung). Eine weitere Forderung kommt von der Instandhaltung: Für Fehlersuche müssen relevante Programmteile in FUP- oder KOP programmiert sein.

Analysiert man eine automationstechnische Aufgabe so empfiehlt es sich zunächst die darin enthaltenen Objekte zu identifizieren. In unserem Fall ergeben sich die folgenden Objekte:

• Motor
• Betriebsarten-Wahl

Zunächst werden die Objekt-Daten typisiert, dabei können (und sollen) auch Unterteilungen vorgenommen werden. Zu beachten ist dabei dass lediglich der Typ „Motor_HMI“ und Alarm.STW für das HMI freigegeben werden muss. (Bild 1)

Falls später ein Signal hinzugefügt oder gelöscht werden muss ist das kein Problem, die Aktualisierung wird von TIA durchgeführt. Eventuelle Änderungen in Programmen müssen natürlich separat durchgeführt werden.

Zu erwähnen ist der Typ HMI: dieser bildet die Schnittstelle zu einer Visualisierung, entweder die integrierte TIA-Visualisierung oder auch ein Fremdprodukt. Diese Schnittstelle besteht lediglich aus den zwei (kostenpflichtigen!) Variablen DIS (Display) und STW (Steuerwort). DIS wird herangezogen für die Darstellung der Zustände des Objekts (z.B. Läuft, Alarm, Verriegelt etc.), STW für Kommandos wie Start, Stop, Quittieren etc. Dafür werden die Einzelbits der Word-Variable herangezogen, das ist auch vorteilhaft bei der Änderung von Bildbausteinen.

Nächster Schritt ist das Anlagen der Objekt Ordner- und Objektstruktur. Das kann unter Verwendung einer in der Bibliothek abgelegten Kopiervorlage erfolgen. (Bild 2)

Man beachte dabei die Unterteilung in Expert und User: alle Bausteine im Bereich Expert sollen eben Experten vorbehalten sein und gegebenenfalls geschützt werden. Alle Programme im Bereich User dienen etwa für die Fehlersuche für die Instandhaltung und sind entsprechend der Forderung in KOP oder FUP progarmmiert.

Nächster Schritt: Die Namen der Ordner und Programmbausteine werden mit den tatsächlichen Objektnamen versehen. Im Motor-DB wird ein Array mit dem Typ Motor angelegt, ergibt sich die Notwendigkeit weiterer Variablen können diese auch im Motor-DB abgelegt werden. Hier gibt es eine Option: Die Objekte müssen nicht als Array angelegt werden, diese können auch als Einzelelemente gespeichert werden. (Bild 3)

Für die Programmierung der Methode empfiehlt sich eine Zustandsmaschine in SCL. Die Methode ist jedenfalls als Funktion auszuführen und beinhaltet alle Funktionen des Objekts (also z.B. Vorwärts-Rückwärtsbetrieb). Die Objektdaten werden in der InOut-Schnittstelle übergeben. Im Beispielobjekt Motor sind keine weiteren Variablen in der Input, Output Schnittstelle notwendig. (Bild 4)

Für die Programmierung der Struktur empfiehlt sich aus Gründen der Übersichtlichkeit, den Baustein in KOP- oder FUP anzulegen und des weiteren SCL-Netzwerke zu verwenden. Im Netzwerk 2 bis 6 werden die Einsprungmarken für außergewöhnliche Zustände gebildet – höchste Priorität zuletzt. Netzwerk 7 ist die State-Machine. (Bild 5)

Netzwerk 8, HMI-supply bezieht sich auf die Signalaufbereitung für den verwendeten Objekt-BildbausteinDer Phantasie sind hier (fast) keine Grenzen gesetzt.

In unserem Beispiel wählen wir zwei Klassen: Die Klasse Motor für eine Drehrichtung und die Klasse Motor für zwei Drehrichtungen. Die jeweilige Klasse hat im Wesentlichen die Aufgabe, nur die relevanten Signale in der Schnittstelle für den Anwender bereitzustellen, entsprechende Signale in der Datenbank zu setzen und abzufragen, die State-Machine aufzurufen und entsprechende Signale für Diagnose und Fehlersuche bereitzustellen. Die Klasse ist jedenfalls auch als Funktion auszuführen. (Bild 6)

Im User-Bereich erfolgt der Aufruf der Objekte in einem Funktionsbaustein über die Klassen. Die Klasse wird dabei unter anderem mit den notwendigen Hardware-Signalen und dem Objekt-Datensatz versorgt. Da ein Funktionsbaustein verwendet wird können gegebenenfalls auch umfangreiche Signal-Vorverarbeitungen durchgeführt werden. (Bild 7)

Es wird ein eigener OB erstellt für den zyklischen Aufruf von Motor_Call, das erleichtert das Ablegen des Motor-Objektes in einer Bibliothek.

Im vorliegenden Beispiel kann ein Bildbaustein für beide Klassen des Objekts Motor verwendet werden. Die jeweiligen spezifischen Elemente z.B. für „Vor/Zurück“ werden dabei über die Klassen ein- bzw. ausgeblendet. (Bild 8)

Die Versorgung des Bildbausteins erfolgt dabei durch eine einzige in einem Typ (beinhaltend DIS und STW) definerte Variable. (Bild 9)

Im wesentlichen wird die gleiche Struktur und die gleiche Vorgehensweise wie beim Objekt Motor verwendet. Die Datenstruktur ist jedoch wesentlich einfacher und beschränkt sich auf die HMI-Schnittstelle mit den Typen DIS und STW. Damit wird ein Objekt gebildet das sowohl über das HMI als auch programmgesteuert für eine Betriebsartenwahl verwendet wird. Diese Betriebsartenwahl kann auch kaskadiert aufgebaut sein. Die angewählte Klasse wird dann in eine Variable im Motor-DB übergeben und von dort über die jeweilige Motor-Klasse an das Motor-Objekt weiter gegeben. (Bild 10)

Das angeführte Beispiel gibt nur einen kleinen Überblick über die verwendeten Methoden und Vorgangsweisen. Diese haben sich über die Zeit weiterentwickelt und unzählige Male in der Praxis bewährt, besonders in Hinblick auf Wiederverwendbarkeit oder Aufgabenteilung Programmerstellung-Inbetriebnahme. Es können auch alle Applikationen mit Frequenzumformer, Reglern oder Servoantrieben damit abgedeckt werden. Wie auch schon erwähnt ist die HMI-Gestaltung der Bildbausteine sehr flexibel und sparsam in der Variablenanzahl. Die Objektorientierung und auch die Zustandsmaschine mag vielleicht einer kritischen akademischen Beurteilung nicht standhalten – aber wir sprechen hier von SPS-Anwendungen, und wer jemals um drei Uhr in der Früh bei der Inbetriebnahme dringend die Anlage zum Laufen bringen musste wird jeden pragmatischen Ansatz zu schätzen wissen.