Wie kann man eine SPS programmieren und in Betrieb nehmen?
von SK
Eine SPS zu programmieren und in Betrieb zu nehmen bedeutet in der Praxis: Steuerungsaufgabe klären, Hardware und Sicherheitskonzept festlegen, Programm strukturiert in einer Entwicklungsumgebung nach IEC 61131-3 aufbauen, in Simulation testen, verdrahtet gegen die realen Ein- und Ausgänge prüfen und die Anlage dann schrittweise, kontrolliert in Bewegung setzen. Der eigentliche Programmiervorgang ist dabei nur ein Teil der Arbeit. Wer schon einmal eine Anlage nachts im Anlauf begleitet hat, weiß: Über Erfolg oder Frust entscheiden meist Vorarbeit, Testdisziplin und eine belastbare Dokumentation.
Ein tragfähiges SPS-Projekt entsteht in dieser Reihenfolge: erst Anforderungen und Risiken, dann Hardware, dann Software, dann Test, und erst am Ende die Anlage unter Spannung und Druck. Wer diese Reihenfolge umdreht, weil der Termin drängt, zahlt die Zeit später doppelt, üblicherweise bei der Störungssuche im laufenden Betrieb.
Nachfolgend beschreiben wir den vollständigen Weg von der Steuerungsaufgabe bis zum stabilen Serienbetrieb: mit den Entscheidungen, die man begründen können sollte, den Tests, die man nicht überspringen darf, und den Unterlagen, die spätestens beim ersten Umbau ihren Wert zeigen.
Grundlagen: SPS, Steuerungsaufgabe und Systemarchitektur
Eine speicherprogrammierbare Steuerung ist im Kern ein industrietauglicher Rechner mit Eingängen, Ausgängen, Betriebssystem (Firmware) und einem Anwenderprogramm. Sie liest zyklisch Signale ein, verarbeitet sie nach der programmierten Logik und schreibt die Ergebnisse auf die Ausgänge. Dieser Zyklus, in der Praxis die Zykluszeit, liegt bei üblichen Steuerungsaufgaben im Bereich einiger Millisekunden. Wichtig für das Verständnis: Innerhalb eines Zyklus arbeitet die Steuerung mit einem Prozessabbild, also mit dem eingelesenen Signalzustand, nicht mit dem laufend wechselnden Zustand am Klemmenpunkt.
Vor jeder Codezeile steht die Steuerungsaufgabe. Sie beschreibt, was die Anlage tun soll, unter welchen Bedingungen, in welchen Betriebsarten und was bei Abweichungen passieren muss. Ohne diese Beschreibung entsteht Software, die sich später niemand mehr erklären kann.
Typische Bausteine einer Systemarchitektur:
| Ebene | Aufgabe | Typische Elemente |
|---|---|---|
| Feldebene | Signale erfassen und Aktoren bewegen | Sensoren, Ventile, Antriebe, Not-Halt-Geräte |
| Steuerungsebene | Logik, Ablauf, Verriegelungen | CPU, digitale/analoge Baugruppen, Safety-CPU |
| Kommunikation | Daten transportieren | Profinet, EtherCAT, Modbus, IO-Link |
| Bedien- und Datenebene | Bedienen, beobachten, auswerten | HMI, SCADA, MES-Anbindung |
Wer die Steuerung von Anfang an als Datenquelle für Qualitäts- und Produktionsauswertung mitplant, spart später aufwendige Nachrüstungen. Genau an dieser Schnittstelle zwischen Automatisierung und Prozessdaten setzen unsere Digitalisierungsprojekte häufig an.
Planung: Anforderungen, Sicherheit und Hardwareauswahl
Die Planungsphase entscheidet über Aufwand, Termintreue und Nachvollziehbarkeit. Hier werden Funktionsumfang, Risiken und Komponenten festgelegt, und zwar schriftlich.
Anforderungen konkret fassen
Brauchbar ist eine Anforderungsliste, die Funktionen, Betriebsarten (Hand, Automatik, Einrichten), Signale, Grenzwerte, Zeiten und Reaktionen auf Störungen benennt. Bewährt hat sich eine Signalliste mit Symbolnamen, Adresse, Signaltyp, Bedeutung und Ruhezustand. Diese Liste wird später zur Grundlage für Verdrahtungsprüfung, Programmvariablen und Prüfprotokoll. Nicht vergessen: Schnittstellen zu Nachbaranlagen, Datenübergabe an ein MES oder CAQ-System und Anforderungen aus Kundenspezifikationen oder Normen wie ISO 9001 oder IATF 16949.
Sicherheit vor Funktion
Sicherheitsfunktionen gehören nicht in die Standardlogik. Grundlage ist eine Risikobeurteilung, aus der sich die erforderlichen Sicherheitsfunktionen und deren Performance Level nach ISO 13849 bzw. SIL nach IEC 61508 ableiten. Not-Halt, Schutztürüberwachung, Zweihandschaltung, sichere Geschwindigkeitsüberwachung: Diese Funktionen werden auf zertifizierter Safety-Hardware realisiert, mit geprüften Bausteinen und einer separaten Validierung. Ein häufiger Fehler in Nachrüstprojekten ist die Verlagerung von Verriegelungen in die Standard-CPU, weil es dort schneller geht.
Hardware passend auswählen
Die Auswahl folgt der Anforderung, nicht dem Katalog. Kriterien, die in der Praxis zählen:
- Anzahl und Art der Ein- und Ausgänge inklusive Reserve von rund 15 bis 20 Prozent
- Rechenleistung und benötigte Zykluszeit, besonders bei Regelungen und Motion Control
- Kommunikationsprotokolle der vorhandenen Feldgeräte
- Verfügbarkeit von Safety-Baugruppen im gleichen System
- Ersatzteilversorgung, Lebenszyklus und Know-how der eigenen Instandhaltung
- Umgebungsbedingungen: Temperatur, Schwingung, Schutzart, EMV-Situation
Entwicklungsumgebung und IEC-61131-3-Sprachen
Die Entwicklungsumgebung bestimmt den Arbeitsalltag: Projektverwaltung, Hardwarekonfiguration, Bibliotheken, Online-Diagnose und Simulation kommen aus einem Werkzeug. Verbreitet sind das TIA Portal für Siemens-Steuerungen, CODESYS als herstellerübergreifende Plattform, TwinCAT bei Beckhoff und Studio 5000 bei Rockwell. Für erste Übungen genügt eine Soft-SPS auf dem PC, etwa CODESYS Control Win, oder die Simulation im jeweiligen Tool. Damit lassen sich Schrittketten und Verriegelungen ohne Hardware und ohne Risiko durchspielen, ein Punkt, den wir Einsteigern immer empfehlen.
Die IEC 61131-3 definiert die Programmiersprachen, die alle gängigen Systeme unterstützen, und legt zugleich einen Architekturrahmen mit Programmen, Funktionen und Funktionsbausteinen fest.
| Sprache | Siemens-Bezeichnung | Stärke in der Praxis |
|---|---|---|
| LD (Ladder Diagram) | KOP, Kontaktplan | Verriegelungen, einfache Verknüpfungen, gut lesbar für Elektrofachkräfte |
| FBD (Function Block Diagram) | FUP, Funktionsplan | Signalverarbeitung, Bausteinaufrufe, Analogwerte |
| ST (Structured Text) | SCL | Berechnungen, Rezepturen, Datenhandling, Schleifen |
| SFC (Sequential Function Chart) | GRAPH | Ablaufsteuerungen mit Schritten und Weiterschaltbedingungen |
| IL (Instruction List) | AWL | historisch verbreitet, für Neuprojekte abgekündigt |
In gemischten Projekten hat sich eine Aufteilung bewährt: Ablauf in SFC, Sicherheits- und Verriegelungslogik in KOP oder FUP, Rechen- und Datenaufgaben in ST. Bibliotheken und geprüfte Bausteine sollten versioniert und geschützt sein; eine Benutzerverwaltung im Projekt verhindert unkontrollierte Änderungen an Kernfunktionen.
Programmablauf erstellen: Struktur, Logik und Fehlermanagement
Guter SPS-Code ist nicht der kürzeste, sondern der, den ein Instandhalter um drei Uhr morgens versteht. Die Struktur bildet daher die Anlage ab: pro Station, Achse oder Aggregat ein Funktionsbaustein mit klarer Schnittstelle, aufgerufen von einem übergeordneten Organisationsbaustein.
Bewährte Vorgehensweise beim Aufbau:
- Namenskonvention festlegen und konsequent nutzen, etwa Präfixe für Sensoren, Ventile, Motoren und Zustandsbits. Ein Symbolname wie
S_ZY01_Ausgefahrensagt mehr alsE0.3. - Betriebsarten sauber trennen: Automatik, Hand, Einrichten, Störung, Grundstellung. Jeder Ausgang wird an genau einer Stelle geschrieben, sonst entstehen Doppelzuweisungen, die im Onlinebetrieb kaum zu finden sind.
- Ablauf als Schrittkette umsetzen: Initialschritt, definierte Weiterschaltbedingungen, Endschritt, Rückkehr in Grundstellung. Jeder Schritt kennt seine Aktion und seine Freigabebedingung.
- Verriegelungen zentral halten, nicht über das Programm verstreut. Eine Freigabelogik pro Aktor mit allen Bedingungen ist übersichtlicher als verschachtelte Abfragen.
- Zeitüberwachung einbauen: Jede Bewegung erhält eine Überwachungszeit. Kommt die erwartete Rückmeldung nicht, wird eine Fehlermeldung, also ein eindeutiger Störungshinweis mit Nummer und Klartext, gesetzt.
Beim Fehlermanagement zahlt sich Systematik direkt aus. Sinnvoll sind eine durchnummerierte Störliste, Unterscheidung zwischen Warnung, Störung und Not-Halt, ein Erstwertspeicher für die auslösende Meldung und eine definierte Quittierlogik. Wichtig ist außerdem das Verhalten nach Spannungswiederkehr: Die Anlage darf nicht unkontrolliert weiterlaufen, sondern muss in einen definierten Zustand gehen. Wer diese Punkte im Programmkonzept festhält, verkürzt später jede Fehlersuche erheblich.
Verdrahtung, Tests und schrittweise Inbetriebnahme
Vor dem ersten Einschalten steht die Kontrolle des Schaltschranks: Klemmen nachziehen, Beschriftung gegen den Stromlaufplan prüfen, Schirmung und Potentialausgleich sichten, Trennung von Last- und Signalleitungen kontrollieren, Sicherungen und Netzteilauslegung prüfen. Erfahrungsgemäß stecken die meisten Anlaufprobleme nicht im Programm, sondern in vertauschten Adern und falsch parametrierten Analogkanälen.
Die Inbetriebnahme läuft in Stufen ab, jede mit eigenem Prüfnachweis:
- Spannung ohne Aktoren: Steuerspannung zuschalten, Leistungsteil und Ventile noch getrennt, CPU-Diagnose und Busteilnehmer kontrollieren.
- Hardwarekonfiguration laden und Bus prüfen: Alle Teilnehmer erreichbar, Firmware-Stände passend, keine Diagnosemeldungen.
- Signalprüfung Eingänge: Jeden Sensor einzeln betätigen und im Programmvariablen-Monitor gegen die Signalliste abhaken. Ruhezustand und Wirkrichtung ausdrücklich mitprüfen.
- Signalprüfung Ausgänge: Im Handbetrieb einzeln ansteuern, zuerst mit abgesteckten Aktoren, dann drucklos oder mit reduzierter Geschwindigkeit.
- Sicherheitsfunktionen prüfen: Not-Halt aus jeder Position, Schutztüren, Wiederanlaufsperre. Jeder Test wird protokolliert, nicht nur beobachtet.
- Einzelfunktionen und Handbetrieb: Bewegungen mit reduzierter Geschwindigkeit, Endlagen und Überwachungszeiten kontrollieren.
- Automatikbetrieb im Leerlauf, dann mit Material, anschließend Taktzeit und Übergaben zu Nachbaranlagen.
Nützlich ist ein Notizbuch oder eine digitale Punkteliste direkt am Schrank: offene Punkte, geänderte Parameter, angepasste Zeiten. Ohne diese Mitschrift geht am zweiten Tag verloren, warum eine Überwachungszeit von 2 auf 3,5 Sekunden gesetzt wurde.
Validierung, Dokumentation und stabiler Betrieb
Die Abnahme prüft nicht nur, ob die Anlage läuft, sondern ob sie die vereinbarten Anforderungen erfüllt. Grundlage ist die Anforderungsliste aus der Planung: Jede Funktion wird gegen ein Prüfkriterium abgefahren, inklusive Störfällen, Grenzwerten und Wiederanlauf. In regulierten Bereichen wie Medizintechnik oder Pharma kommen Qualifizierungsschritte mit dokumentierten Testfällen und Nachweisen hinzu; sicherheitsgerichtete Programmteile werden separat validiert und freigegeben.
Zur vollständigen Anlagendokumentation gehören:
- Kommentierter Programmstand mit Versionsnummer, Datum und Änderungsgrund
- Signal- und Störmeldungsliste im Ist-Stand
- Stromlaufplan und Klemmenplan nach Rot-Korrektur
- Parameterlisten für Antriebe, Analogkanäle und Zeitwerte
- Prüf- und Abnahmeprotokolle inklusive Sicherheitsvalidierung
- Backup von SPS-Projekt, Safety-Programm, HMI und Antriebsparametern auf einem definierten Ablageort
Für den dauerhaften Betrieb entscheidet das Änderungsmanagement. Jede Programmänderung braucht einen Auslöser, eine Freigabe, einen Test und einen dokumentierten neuen Stand. Undokumentierte Onlineänderungen sind die häufigste Ursache dafür, dass ein Backup nach zwei Jahren nicht mehr zum realen Anlagenzustand passt. Sinnvoll sind zusätzlich regelmäßige Diagnoseauswertungen, eine Auswertung der häufigsten Störmeldungen und daraus abgeleitete technische Verbesserungen. Genau hier verbinden sich Automatisierungstechnik und Qualitätsmanagement: Störungsdaten aus der Steuerung liefern belastbare Grundlagen für Ursachenanalysen, FMEA-Aktualisierungen und kontinuierliche Verbesserung. Unsere Projekterfahrung aus Fertigung, Automotive und Pharma zeigt, dass gepflegte Steuerungsdokumentation den Aufwand bei Audits und Umbauten deutlich senkt.