Hello SPS! Teil 1: Grundlagen speicherprogrammierbarer Steuerungen
Die dreiteilige Artikelserie beleuchtet speicherprogrammierbare Steuerung SPS als wichtige Komponente der Automatisierungstechnik – zum Start deren Grundlagen.
(Bild: Stokkete/Shutterstock.com)
- Dr. Michael Stal
Die Speicherprogrammierbare Steuerung (SPS) oder auch Programmable Logic Control (PLC) hat sich in der Welt der Automatisierungssysteme zu einem unverzichtbaren Bestandteil entwickelt. Diese dreiteilige Artikelserie widmet sich ausführlich diesem Thema.
- Teil 1 der Serie führt zunächst in die Grundlagen von SPS ein.
- Der zweite Teil erklärt, wie sich die Open-Source-SPS OpenPLC praktisch einsetzen lässt.
- Teil 3 zeigt das Umfeld, in dem SPS mit anderen Automatisierungskomponenten zusammenarbeitet.
Was ist überhaupt eine SPS beziehungsweise PLC?
Bevor es losgeht, bleibt die Frage zu klären, was sich hinter den Begriffen SPS und PLC verbirgt. Eine SPS (Speicherprogrammierbare Steuerung) oder auf Englisch PLC (Programmable Logic Control) ist eine wichtige Komponente in Automatisierungssystemen.
Diese Steuerungen enthalten Code zum Einlesen von Daten (z.B. Zustand eines Schalters, Sensoren), vorprogrammierte Verarbeitungselemente (z.B. Bibliotheksbausteine wie Flip-Flops und Timer), benutzerdefinierten Code für die Verarbeitung, und Code zum Schreiben von Daten (z.B. für Motorsteuerung, Öffnen/Schließen eines Ventils). Die Eingabe umfasst also die Sensorik, während die Ausgabe für die Aktorik zuständig ist. Beides kann entweder analog oder digital erfolgen. Wichtig ist in diesem Zusammenhang, dass jede zyklusgesteuerte SPS in einer Anlage getaktet arbeitet. Das bedeutet, sie muss ihre Verarbeitung innerhalb eines vordefinierten Zeitfensters abschließen, zum Beispiel in 20 ms.
Ein einfaches Beispiel für ein SPS-Programm könnte sein:
- Status von zwei angeschlossenen Schaltern (offen, geschlossen) überprüfen
- Ist einer der beiden Schalter geschlossen (d.h. am jeweiligen Ausgang liegt Strom an), den Funktionsblock Lichtstärke aktivieren
- Liegt die Lichtstärke unter einem vordefinierten Schwellenwert, Strom durch Ausgang des Funktionsblocks leiten
- und dadurch über die Ausgabeschnittstelle die LED aktivieren
Das Beispiel in der nachfolgenden Abbildung ist in der SPS-Programmiersprache LD (Ladder Diagram) geschrieben:
Die linke Ladder in diesem Ladder Diagram lässt sich als Plus-Pol (Anode) einer Schaltung interpretieren, die rechte als Minus-Pol (Kathode). Der Strom fließt also von links nach rechts.
Nach Ablauf des Programmes fängt die SPS erneut bei der ersten Instruktion des durchgeführten Programmes an. Überschreitet das Programm einer solchen SPS die Zykluszeit, stoppt die CPU. Ein Beispiel für eine ereignisgesteuerte und damit nicht zyklusgesteuerte SPS folgt im nächsten Abschnitt.
Für diesen Zyklus findet sich oft der Begriff PLC Scan Time, der die Zeit definiert, die eine PLC benötigt, die Eingänge zu lesen, die vom Nutzer vorgegebene Logik umzusetzen, und dann auf die Ausgänge zu schreiben. In der Realität gibt es noch einen vierten Schritt, in dem die PLC ihren eigenen Zustand (Health) prüft.
Braucht eine Verarbeitung weniger als die parametrisierte Zykluszeit, verbleibt die PLC bis zum Ende des Zeitintervalls in einem Idle-Zustand. Sie hält sich also stets an den festgelegten Takt. Das ist auch deshalb wichtig, weil sich mehrere kooperierende PLCs über denselben Takt synchronisieren können. Eine PLC darf also nie aus der Reihe tanzen.
Doch warum sind SPSen eigentlich so cool? Im Jahre 1969 erschien die Modicon 084 (heute Schneider Electric) als allererste PLC – Modicon steht übrigens für Modular Digital Controller. Bevor es diese erste SPS gab, mussten Steuerungen und Regelungen über Verbindungsprogrammierung erfolgen, was unter anderem Relais und Logikbausteine erforderte. Das führt zu hohem Aufwand und wenig Flexibilität. Allein die Umstellung einer Fahrzeugfertigung von einem Modell auf ein anderes wäre mit erhöhtem Aufwand verbunden.
Dahingegen ist eine SPS flexibel einsetzbar und lässt sich wesentlich leichter für einen gewünschten Zweck konfigurieren, programmieren und anpassen. Über Bussysteme wie Profinet oder Modbus ist es zudem möglich, SPSen in übergreifende Lösungen zu integrieren oder miteinander zu verbinden. Kein Wunder, dass schon bald Unternehmen wie Siemens und Allen-Bradley (heute Rockwell) dem Vorbild der Modicon folgten.
Eine moderne SPS muss nicht unbedingt als einzelne Box – sprich als Monolith – vorliegen, sondern kann modular aufgebaut sein. Eine modulare SPS besteht im Gegensatz zu einer nicht-modularen aus unterschiedlichen Baugruppen, die kombiniert eine SPS ergeben. Das kann unter anderem eine CPU-Baugruppe sein, eine Schnittstellenbaugruppe, eine Stromversorgungs-Baugruppe, eine Eingabebaugruppe oder eine Ausgabebaugruppe. Benötigt der Anwender mehr Schnittstellen oder Funktionalitäten, fügt er weitere Komponenten hinzu. Dazu gehören auch komplexere Regelungsbaugruppen, Sensorbaugruppen, und viele weitere Module.
(Bild: siemens.com)
Der Vorteil einer modularen SPS besteht demzufolge darin, dass sie sich genau für den gewünschten Einsatzzweck ausrüsten lässt. In einer Simatic-PLC von Siemens ist dies beispielsweise möglich. PLCs wie die aus Siemens S7-Serie (Simatic) liegen überwiegend als PLCs aus modularen Hardwarekomponenten vor, etwa als Komponenten für industrielle Schaltschränke bzw. Steckschränke.
Als Stromquelle nutzt eine SPS typischerweise einen Wandler, der 220V (oder in den USA 110V) Wechselspannung in 5V Gleichspannung (für CPU, RAM, ROM) und 24V Gleichspannung (für digitale Eingabe & Ausgabe) sowie 10V für analoge I/O umwandelt.
Das geht auf die Pumpe – ein größeres Szenario
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.
Zusammenfassung
Im vorliegenden Teil standen die SPS/PLC-Grundlagen im Vordergrund. In der Praxis kommen sowohl zyklusgesteuerte SPS-Anwendungen als auch ereignisgesteuerte SPS-Anwendungen vor. Da sie sich streng an ihre Zeitvorgaben halten müssen, liegen ihnen meistens Echtzeitbetriebssysteme zugrunde. Bisher überwiegen in der Praxis eindeutig Hardware-basierte Lösungen, die entweder als monolithische Komponenten vorliegen können oder die aus mehreren Baugruppen bestehen. Zunehmend spielen aber Software-basierte SPSen eine Rolle, die entweder auf Standardhardware oder als Software in Containern oder Cloudumgebungen laufen.
Der kommende zweite Teil beschäftigt sich mit OpenPLC als Vertreter einer Software-SPS, die als Open Source sowohl auf Desktopbetriebssystemen wie macOS, Linux, Windows beziehungsweise Raspberry Pi OS, als auch auf Bare-Bone-Hardware wie Arduino, ESP32 oder Raspberry Pi Pico funktioniert.
(mdo)
