Seite 2: Das geht auf die Pumpe – ein größeres Szenario

Inhaltsverzeichnis

Natürlich ist das obige Beispiel aus Verständnisgründen etwas einfach gehalten. Daher soll hier ein praxisnahes Beispiel mit höherer Komplexität folgen. Ein Hinweis vorab: Dieses Beispiel basiert auf einer ereignisbasierten SPS, in der die SPS aufgrund ankommender Ereignisse aufwacht. Eine ereignisgesteuerte SPS wird also über Ereignisse "getaktet", nicht wie zyklusgesteuerte SPSen über eine Zykluszeit bzw. einen zeitlichen Takt.

Das Szenario:

n Pumpen sind an einem Behälter angeschlossen. Sie lassen sich individuell ein- und ausschalten. Im Behälter befinden sich in verschiedenen Höhen Sensoren beziehungsweise Endstopps, die anzeigen, ob der Behälter schon bis zu diesem Level gefüllt ist.

• Zunächst aktiviert die SPS Pumpe 1, um Flüssigkeit 1 bis zum ersten Level zu füllen.
• Danach sorgt Pumpe 2 dafür, dass Flüssigkeit 2 solange in den Behälter fließt, bis das zweite Level erreicht ist.
• Das passiert reihum bis zu Level n und Flüssigkeit n.
• Hinweis: Die SPS oder konkret das darauf ablaufende Programm schaltet jede Pumpe <i> ab, wenn der Behälter den Flüssigkeitsstand Level <i> erreicht hat, was der entsprechende Sensor <i> meldet (Ereignis Level <i> erreicht).
• Erreicht der Flüssigkeitsstand das höchste Level n, stoppt die SPS Pumpe n,
• und aktiviert einen Mixer, der die Flüssigkeiten über eine festgelegte Zeit mischt.
• Beim Überschreiten dieser Zeitschranke (Ereignis Timer abgelaufen), stoppt die SPS den Mixer,
• und öffnet ein Ventil, sodass die Flüssigkeit komplett aus dem Behälter zur nächsten Verarbeitungsstation abfließen kann.
• Am Boden des Behälters ist dazu ein Level 0 Sensor angebracht, der erkennt, sobald der Vorgang beendet beziehungsweise der Behälter entleert ist.
• Trifft dies zu, schließt die SPS das Ventil und beginnt wieder von vorne.

Ereignisse in diesem Szenario sind also: Level <i> erreicht für alle 0 <= i <= n und Timer abgelaufen. In der Praxis kommen eventuell noch viele weitere Ereignisse hinzu, etwa Motor aktiviert, Motor gestoppt, Pumpe aktiviert, Pumpe gestoppt, Ventil geöffnet, Ventil geschlossen, Schwellenwert (des Sensors) noch nicht erreicht. Der Kürze zuliebe und um zu viel Komplexität zu vermeiden, erläutert das Beispiel nicht alle Details.

Wie sich aus dem Beispiel sehr einfach extrahieren lässt, hat eine SPS Zugang zu Eingängen, um zum Beispiel den aktuellen Stand/Wert der Level-Sensoren zu lesen. Sie schreibt auf die Ausgabe-Ports, um Pumpen, das Ventil und den Mixer zu steuern.

Würde die Anlage zusätzlich über einen Not-Stopp verfügen, müsste die SPS auch darauf reagieren und das System stante pede in einen gesicherten Zustand überführen. Sofern die SPS Interrupts anbietet, könnte man diese nutzen, um den Not-Stopp als Interrupt höchster Priorität zu signalisieren und umzusetzen.

Unter dem Regime der Zykluszeit

Was passiert, wenn eine Gesamtaktivität wie das oben beschriebene ereignisorientierte Programm auf einer (zyklusgesteuerten) SPS laufen soll? Offensichtlich benötigen manche Aktivitäten wie der Timer deutlich länger als eine "normale" Zykluszeit. Ist es nicht möglich, das gesamte Programm in einem Zyklus abzuarbeiten? Antwort: Die Beispielanwendung und der zugehörige Prozess lassen sich aus SPS-Perspektive als Folge von kleinen Schritten betrachten. Beispiele für einen solchen Schritt sind: Motor anschalten, Füllstand abfragen, Aktivieren oder Deaktivieren einer Pumpe oder eines Ventils, Addieren der Zykluszeit auf den Timerzustand. Die SPS "merkt" sich somit zyklusübergreifend den aktuellen Zustand. Sie weiß aufgrund des Prozessabbilds (jeweiliger Gesamtzustand des Systems inkl. Eingänge, Ausgänge, Variablen), was als Nächstes zu tun ist. Die CPU verarbeitet so viele Schritte, wie sie innerhalb der Zykluszeit erledigen kann. Reißt ein Programmschritt die Zykluszeit (zum Beispiel Motor anschalten dauert länger als die Zykluszeit), fällt die SPS in einen Fehlerzustand und stoppt. Stoppen ist für die SPS die einzig sinnvolle Möglichkeit, den Fehler zu behandeln. Ein Weiterlaufen trotz aus dem Takt geratener SPS und des dadurch undefinierten Zustands könnte schließlich zu größeren, unerwünschten Seiteneffekten führen. Zudem arbeiten SPSen oft mit anderen zusammen, mit denen sie sich bezüglich des Takts synchronisieren. Nach dem Anhalten bekommen Programmierer die Gelegenheit, der Ursache auf die Spur zu kommen.

Wichtig bei der SPS-Programmierung ist unter anderem, dass speziell Kommunikation und Motoransteuerung vergleichsweise hohe Zeitanforderungen besitzen. Hier gibt es potenziell Raum für Optimierung. Kann eine PLC-Anwendung trotz Optimierung die Zykluszeit nicht einhalten, kommt unter Umständen der Wechsel auf eine schnellere PLC (oder eine schnellere CPU) in Betracht.

Die SPS kann die einzelnen Zyklen entweder durch entsprechende Taktung implementieren oder mittels Interrupts, deren Auslösung jeweils am Ende der Zykluszeit erfolgt. Beispielsweise lösen Timer entsprechende Hardwareinterrupts aus.

Programmierung einer SPS

Typischerweise liegt eine SPS in einer beim Engineering vordefinierten bzw. programmierten Konfiguration vor. Unter Programmieren verstehen Informatiker in der Regel das Verwenden von Hochsprachen á la C/C++, Java oder Python. Für einen Anlageningenieur, der schließlich kein Softwarexperte sein muss, impliziert Programmieren einer SPS eher den Einsatz von speziellen Sprachen wie Ladder Diagram, Function Block Diagram, Sequential Function Charts, Structured Text oder Instruction List. Dazu später mehr.

Jedenfalls erzeugt die Ingenieurin ein Programm für die SPS in ihrer bevorzugten Sprache mit Hilfe einer Anwendung (Editor bzw. Engineering Tool) und lädt das fertige Programm von dort in die eigentliche Laufzeitumgebung (Runtime) beziehungsweise Hardware hoch. Um nicht alles im Echtbetrieb testen zu müssen, bieten die Hersteller in ihren Werkzeugen die Möglichkeit an, die Laufzeit der SPS-Anwendung visuell zu simulieren.

Eine SPS kann über ein Mensch-Maschinen-Interface (HMI) verfügen, muss aber nicht. Falls nicht, lässt sich eine solche zum Beispiel über ein SCADA-System nachträglich realisieren, was in Teil 3 der Artikelserie beschrieben wird.

Typischerweise enthält sie eine Netzwerkschnittstelle (meistens Ethernet bzw. Industrial Ethernet mit TCP/IP-Stack) oder serielle Schnittstellen, sodass sie von außen zugreifbar ist und nach außen kommunizieren kann. Moderne SPSen können dank TCP Informationen über Webbrowser übermitteln, sich mit einer Datenbank verbinden, oder Daten mittels MQTT übertragen.

Bewegen sich die Zykluszeiten in einem nicht allzu stringenten Rahmen, lassen sich diese Steuerungen auch in reine Software gießen, was Geld spart und die Wartung erleichtert. Die Software-SPS läuft dann auf eingebetteter Standard-Hardware (Arduino, ESP32, Raspberry Pi) oder unter Umständen als virtuelle Steuerung auf einem Computer oder in einem (cloud-basierten) Docker-Container.

Ob die Wunsch-Hardware in einer rauhen Industrieumgebung robust funktioniert, müssen Anwender natürlich zuvor verifizieren. Schließlich sind SPSen dort einigen Umwelteinflüssen ausgesetzt (Druck, Temperatur, Feuchtigkeit, Vibrationen, …). Aus diesem Grund gibt es beispielsweise die Arduino Pro Serie, die Arduino als Basis für genau solche Anwendungen ausgelegt hat – natürlich sollte das Arduino-Pro-Board in einem entsprechenden Industrie-tauglichen Gehäuse untergebracht sein.

SPSen lassen sich sogar auf Basis von Standardbetriebssystemen wie Linux (inkl. Raspberry OS), macOS oder Windows entwickeln und betreiben. Hier gibt es allerdings eine Einschränkung hinsichtlich der fehlenden Echtzeitfähigkeit dieser Betriebssysteme zu beachten. Da auf den genannten Standardbetriebssystemen in der Regel mehrere Prozesse laufen, kommen diese unter Umständen mit dem SPS-Prozess in Konflikt, sodass keine gesicherten Zykluszeiten mehr möglich sind. Daher sollten SPSen mit harten Echtzeitanforderungen auf Echtzeitbetriebssystemen laufen oder als Firmware auf Bare-Bones-Hardware wie Microcontroller-Boards. Industrielle SPSen bringen in der Regel ihr eigenes Betriebssystem mit.

Ein kleiner Hinweis bezüglich Linux als Basis einer echtzeitfähigen SPS: Selbstverständlich erlauben Linux-Distributionen wie Debian durch Installation/Kompilation eines Echtzeitkernels, aus dem Linux-Desktopsystem ein Echtzeitsystem zu machen. Dadurch können SPS-Implementierungen dort auch Echtzeitthreads nutzen.