Programmierung von Zustandsautomaten-Logik in einer SPS für einen 3-Phasen-Motor

Um Zustandsautomaten-Logik in einer SPS zu programmieren, unterteilen Ingenieure eine Maschinensequenz in sich gegenseitig ausschließende Zustände und führen explizite Übergänge zwischen diesen durch. Für einen 3-Phasen-Motor bedeutet dies in der Regel ganzzahlige Zustände für „Aus“, „Starten“, „Betrieb“, „Stoppen“ und „Fehler“, die einfacher zu validieren, zu beheben und robuster zu gestalten sind als verschachtelte Selbsthaltungs-Logik.

Verschachtelte Selbsthaltungs-Logik ist nicht allein deshalb „gut genug“, weil sie beim ersten Test funktioniert. Bei der Ablaufsteuerung kann Boolesche Logik, die auf einem statischen Bildschirm übersichtlich aussieht, dennoch Race Conditions, mehrdeutige Wiederherstellungspfade und scan-abhängiges Verhalten erzeugen, wenn Eingänge prellen oder Fehler mitten in der Sequenz auftreten.

Während interner Tests des 3-Phasen-Motor-Presets von Ampergon Vallis in OLLA Lab reduzierte das Ersetzen verschachtelter Selbsthaltungskontakte durch einen expliziten, ganzzahligen endlichen Zustandsautomaten die beobachteten Race-Condition-Fehlerereignisse bei simulierten Not-Aus-Versuchen um 87 % [Methodik: n=30 Simulationsläufe derselben 3-Phasen-Motoraufgabe, Vergleich mit Basis-Selbsthaltungs-Logik, Testzeitraum Februar-März 2026]. Dies stützt eine begrenzte Aussage über ein internes Trainings-Preset unter simulierter Fehlerinjektion. Es begründet keine universelle Fehlerminderungsrate über alle SPS-Architekturen, Anlagen oder Motoranwendungen hinweg.

Diese Unterscheidung ist wichtig. Inbetriebnahmefehler entstehen meist in Randbedingungen, nicht im Idealfall.

Die Logik eines endlichen Zustandsautomaten (Finite State Machine, FSM) ist für die Ablaufsteuerung überlegen, da sie das Maschinenverhalten explizit, gegenseitig ausschließend und deterministisch macht. Ein korrekt aufgebauter FSM ermöglicht es der SPS, die Regeln für den aktuellen Zustand auszuwerten und nur dann überzugehen, wenn definierte Bedingungen erfüllt sind.

Verschachtelte Selbsthaltungs-Rungs bewirken das Gegenteil. Sie verteilen die Sequenzspeicherung oft auf mehrere Bits, Freigaben, Verriegelungen und Interlocks, die indirekt interagieren. Das Ergebnis ist eine Logik, die zwar funktionieren mag, aber nur so lange, bis Timing-Probleme, Rückmeldeverluste oder anormale Abschaltungen die verborgenen Abhängigkeiten offenlegen. Syntax ist nicht dasselbe wie Einsatzfähigkeit.

IEC 61131-3 schreibt kein universelles Sequenzmuster vor, aber ihr Programmorganisationsmodell unterstützt nachdrücklich strukturierte, lesbare und wartbare Steuerungslogik für zustandsbasierte Sequenzierung in SPS-Anwendungen (IEC, 2013). In der Praxis sind FSMs zu einer gängigen Architektur für Maschinensequenzen geworden, da sie einfacher zu durchdenken, zu testen und nach Fehlern wiederherzustellen sind.

Eine nützliche operative Definition lautet:

- Endlicher Zustandsautomat in Ladder-Logik: eine Steuerungsarchitektur, bei der eine Zustandsvariable den aktuellen Maschinenmodus repräsentiert, zu jedem Zeitpunkt nur ein gültiger Zustand aktiv ist und Übergänge durch explizite Bedingungen erfolgen, die den nächsten Zustand zuweisen.

Dieser letzte Punkt ist entscheidend. Wenn der Übergang nicht explizit ist, verlässt sich die Maschine auf Nebeneffekte.

Onion-Logik vs. Zustandsautomaten-Architektur

| Engineering-Faktor | Verschachtelte Selbsthaltung / "Onion-Logik" | Endlicher Zustandsautomat | |---|---|---| | Aktiver Sequenzspeicher | Verteilt auf Bits und Latches | Zentralisiert in einer Zustandsvariable | | Scan-Zyklus-Verhalten | Kann reihenfolgeabhängig und mehrdeutig werden | Deterministisch bei expliziten Übergängen | | Fehlerbehebung | Oft aus mehreren Bedingungen abgeleitet | Expliziter Fehlerzustand, z. B. `99` | | Fehlersuche | Verfolgung vieler interagierender Bits | Zuerst den aktuellen Zustands-Integer lesen | | Sequenzerweiterung | Fehleranfällig bei wachsenden Verzweigungen | Einfacheres Einfügen von Zwischenzuständen | | Validierung in Simulation | Schwieriger, Fehlerpfade zu isolieren | Klare Testmöglichkeit von Übergang zu Übergang |

Erfahrene Steuerungsingenieure lehnen Onion-Logik aus demselben Grund ab, aus dem sie unbeschriftete Feldverdrahtung ablehnen: Das System mag zwar laufen, aber niemand sollte raten müssen, warum.

Eine 3-Phasen-Motorsequenz erfordert mehr als nur ein Ein- und Aus-Bit, da reale Anlagen Übergangsverhalten, Rückmelde-Timings und Fehlerbehandlung aufweisen. Selbst ein einfacher Motorstarter benötigt in der Regel eine explizite Behandlung von Freigaben, Startbestätigung, Stoppverhalten und Fehlerquittierung.

Ein praktischer FSM für einen 3-Phasen-Motor verwendet üblicherweise diese Zustände:

1. Zustand 0 — Aus / Bereit Der Motor ist spannungsfrei. Erforderliche Freigaben sind vorhanden. Die Sequenz wartet auf einen gültigen Startbefehl.
2. Zustand 10 — Starten Der Startausgang wurde ausgegeben. Die Logik wartet auf die erwartete Rückmeldung, wie z. B. Hilfskontaktprüfung, Betriebsmeldung, Drehzahlbestätigung oder ein zeitlich begrenztes Startfenster.
3. Zustand 20 — Betrieb Der Motor befindet sich im stationären Betrieb. Die Logik überwacht weiterhin Stoppbefehle, Überlastungen, Freigabeverluste und anormale Rückmeldungen.
4. Zustand 30 — Stoppen Ein Stoppbefehl oder eine kontrollierte Abschaltung wurde eingeleitet. Die Logik wartet auf die Bestätigung der Spannungsfreiheit, Stillstandsrückmeldung oder den Ablauf eines Timeouts.
5. Zustand 99 — Fehler Eine Auslösung, fehlgeschlagene Prüfung, Überlastung oder ein ungültiger Sequenzzustand ist aufgetreten. Ausgänge werden auf die definierte sichere Reaktion gesteuert und die Reset-Logik wird explizit behandelt.

Die Verwendung von 10er-Schritten ist eine praktische Gewohnheit, da sie Raum für das spätere Einfügen von Zuständen wie `15 = Start-Verifizierung` oder `25 = Auslaufbestätigung` lässt, ohne die gesamte Sequenz neu nummerieren zu müssen.

Warum Übergangszustände in der realen Motorsteuerung wichtig sind

Übergangszustände existieren, weil Motoren mit der elektrischen und mechanischen Realität interagieren, nicht nur mit Ladder-Symbolen. Je nach Anwendung muss die Steuerungssequenz Folgendes berücksichtigen:

• Anzugszeit des Schützes
• Stern-Dreieck-Umschaltzeiten
• Beschleunigungs- und Verzögerungsrampen von Frequenzumrichtern
• Rückmeldungen von Hilfskontakten
• Freigabeverlust während des Betriebs
• Auslösung von Überlastrelais
• Prozessverriegelungen nachgeschalteter Anlagen
• Stillstandsbestätigung

Hier benötigt auch der Begriff „Simulationsbereit“ eine präzise Definition.

- Simulationsbereit: Die Fähigkeit, Steuerungslogik gegen realistisches Prozessverhalten zu prüfen, zu beobachten, zu diagnostizieren und abzusichern, bevor sie einen realen Prozess erreicht.

Das bedeutet mehr, als nur einen Rung zu schreiben, der kompiliert. Es bedeutet zu validieren, ob der Ladder-Zustand, der E/A-Zustand und der simulierte Anlagenzustand unter normalen und anormalen Bedingungen konsistent bleiben.

Ein FSM auf Ladder-Basis wird erstellt, indem der aktuelle Zustand mit einem Komparator gelesen und der nächste Zustand mit einem expliziten Move-Befehl geschrieben wird. In OLLA Lab erfolgt diese Arbeit im Ladder-Editor, im Variablen-Panel und im Simulationsmodus.

OLLA Lab sollte hier als eine begrenzte Validierungs- und Übungsumgebung verstanden werden. Sie ist nützlich, weil sie es Ingenieuren ermöglicht, risikoreiche Inbetriebnahme-Verhaltensweisen wie Logikvalidierung, E/A-Beobachtung, Fehlerinjektion und Revision zu üben, ohne reale Anlagen als Lehrmittel zu verwenden.

### Schritt 1: Den Zustands-Integer definieren

Erstellen Sie ein Tag wie:

- `Motor_State` : `INT`

Dieser Integer ist die einzige Quelle der Wahrheit für den aktuellen Sequenzzustand der Maschine.

Empfohlene begleitende Tags sind:

• `Start_PB`
• `Stop_PB`
• `OL_Trip`
• `Aux_Run_Proof`
• `Reset_PB`
• `Motor_Output`
• `Start_Timer.DN`
• `Stop_Timer.DN`

### Schritt 2: Den Übergang von „Aus“ zu „Starten“ erstellen

Der erste Übergang bewegt den Motor normalerweise vom Bereit-Zustand in den Start-Zustand, wenn Freigaben und eine Startanforderung vorliegen.

Beispiel-Logikkonzept:

• Wenn `Motor_State = 0`
• und `Start_PB = TRUE`
• und keine Störung aktiv
• und erforderliche Freigaben vorhanden
• dann `MOV 10` in `Motor_State`

Dies ist das Grundmuster:

• `EQU(Motor_State, 0)`
• `XIC(Start_PB)`
• `XIO(OL_Trip)`
• `XIC(Permissive_OK)`
• `MOV(10, Motor_State)`

### Schritt 3: Den Übergang von „Starten“ zu „Betrieb“ erstellen

Der Start-Zustand sollte bestätigen, dass der Motor tatsächlich den erwarteten Zustand erreicht hat. Diese Bestätigung kann je nach Anwendung ein Hilfskontakt, eine Betriebsrückmeldung, eine Durchflussprüfung, eine Drehzahlprüfung oder eine Zeitbedingung sein.

Beispiel-Logikkonzept:

• Wenn `Motor_State = 10`
• und `Aux_Run_Proof = TRUE`
• dann `MOV 20` in `Motor_State`

Wenn die Bestätigung nicht innerhalb der zulässigen Zeit empfangen wird, stattdessen in den Fehlerzustand übergehen.

• Wenn `Motor_State = 10`
• und `Start_Timer.DN = TRUE`
• und `Aux_Run_Proof = FALSE`
• dann `MOV 99` in `Motor_State`

### Schritt 4: Den Übergang von „Betrieb“ zu „Stoppen“ erstellen

Der Betriebszustand sollte sowohl befohlene Stopps als auch anormale Bedingungen überwachen.

Beispiel-Logikkonzept:

• Wenn `Motor_State = 20`
• und `Stop_PB = TRUE`
• dann `MOV 30` in `Motor_State`

Fügen Sie auch die Störungsbehandlung hinzu:

• Wenn `Motor_State = 20`
• und `OL_Trip = TRUE`
• dann `MOV 99` in `Motor_State`

### Schritt 5: Den Übergang von „Stoppen“ zu „Aus“ erstellen

Der Stopp-Zustand sollte warten, bis der Motor den erwarteten Stillstand erreicht hat.

Beispiel-Logikkonzept:

• Wenn `Motor_State = 30`
• und Stillstandsbestätigung ist wahr
• dann `MOV 0` in `Motor_State`

Wo keine physische Stillstandsprüfung existiert, kann ein begrenzter Timer verwendet werden, aber dies sollte eine bewusste Designentscheidung sein und kein Raten, das als Gewissheit getarnt ist.

### Schritt 6: Den expliziten Fehlerzustand erstellen

Der Fehlerzustand sollte Ausgänge spannungsfrei schalten und einen definierten Reset-Pfad erfordern. In vielen Anwendungen bedeutet dies keinen automatischen Neustart nach Überlast oder fehlgeschlagener Prüfung, es sei denn, die Steuerungsphilosophie erlaubt dies explizit.

Beispiel-Logikkonzept:

• Wenn `Motor_State = 99`
• erzwinge `Motor_Output = FALSE`
• erfordere `Reset_PB = TRUE`
• erfordere, dass die Störung behoben ist
• dann `MOV 0` in `Motor_State`

Zusammenfassung des Ladder-Musters

Ein sauberes FSM-Rung-Muster in OLLA Lab folgt typischerweise dieser Sequenz:

• `EQU` zur Identifizierung des aktuellen Zustands
• eine oder mehrere `XIC` / `XIO`-Bedingungen zur Validierung des Übergangs
• `MOV` zum Schreiben des nächsten Zustands

Beispiel-Ladder-Muster:

• `EQU Motor_State 10` und `XIC Aux_Run_Proof` dann `MOV 20 -> Motor_State`
• `EQU Motor_State 10` und `XIO Aux_Run_Proof` und `XIC Start_Timer.DN` dann `MOV 99 -> Motor_State`

Bild-Alt-Text: Screenshot des OLLA Lab Ladder-Logik-Editors, der einen FSM-Rung zeigt, bei dem ein EQU-Block prüft, ob Motor_State gleich 10 ist, eine Eingangsbedingung Aux_Run_Proof verifiziert und ein MOV-Block Motor_State auf 20 setzt.

Ausgänge sollten aus dem aktiven Zustand abgeleitet werden und nicht als versteckter Speicher für die Sequenz dienen. Diese Unterscheidung ist leicht zu übersehen und teuer zu ignorieren.

Ein gängiges Muster ist:

• `Motor_Output` einschalten, wenn `Motor_State = 10` oder `Motor_State = 20`
• ausschalten in `0`, `30` und `99`, es sei denn, die Stopp-Philosophie erfordert ein kontrolliertes Halten

Dies ergibt eine direkte Beziehung zwischen Sequenzabsicht und befohlenem Ausgang. Es macht auch die Simulation und Fehlersuche sauberer, da der Ausgang zu einer Konsequenz des Zustands wird und nicht zu einem zweiten, undokumentierten Zustandsautomaten.

Beispiel-Ausgangslogik

• Wenn `Motor_State = 10` ODER `Motor_State = 20`
• dann `Motor_Output = TRUE`

• Wenn `Motor_State = 0`, `30` oder `99`
• dann `Motor_Output = FALSE`

Für komplexere Motorsysteme, wie Wendestarter, Stern-Dreieck-Übergänge oder Frequenzumrichter-Bypass-Anordnungen, sollte jeder Aktor-Befehl dennoch zustandsbasiert bleiben und explizit verriegelt sein.

Der häufigste FSM-Fehler ist ein hängender Zustand. Ein hängender Zustand tritt auf, wenn die Maschine in einen gültigen Zustand eintritt, aber niemals die Bedingungen erfüllt, die erforderlich sind, um ihn zu verlassen.

Deshalb ist Simulation wichtig. Sie lässt Sie Kausalität beobachten, bevor Hardware, Mechanik und Zeitdruck die Diagnose erschweren.

In OLLA Lab sollte die Fehlersuche bei einem FSM einer einfachen Sequenz folgen:

1. Zuerst den aktuellen Zustands-Integer lesen Überprüfen Sie `Motor_State` im Variablen-Panel. Beginnen Sie nicht damit, zu raten, welcher Rung falsch aussieht.
2. Die erwartete Übergangsbedingung verifizieren Wenn sich der Motor im `Zustand 10` befindet, bestätigen Sie, ob `Aux_Run_Proof` tatsächlich wechselt, ob der Timer läuft und ob Freigaben wahr bleiben.
3. Ladder-Zustand gegen simulierten Anlagenzustand prüfen Die Ladder mag einen Motorausgang befehlen, aber die simulierte Anlage zeigt möglicherweise weiterhin eine fehlgeschlagene Prüfung, verzögerte Reaktion oder fehlerhaftes Verhalten.
4. Einen Fehler gezielt injizieren Schalten Sie `OL_Trip` während `Zustand 20` um und bestätigen Sie, dass die Sequenz sofort in `Zustand 99` übergeht.
5. Sichere Reaktion verifizieren Bestätigen Sie, dass Motorausgänge wie erforderlich abschalten und dass die Maschine den Betrieb nicht wieder aufnehmen kann, bis die Reset-Bedingungen erfüllt sind.

Hier wird OLLA Lab operativ nützlich. Es ermöglicht dem Lernenden, den Steuerungszustands-Integer, E/A-Bedingungen und das Anlagenverhalten an einem Ort zu vergleichen, was die Arbeit widerspiegelt, die Inbetriebsetzungsingenieure unter Druck leisten.

Ein praktischer Fehlerinjektionstest

Verwenden Sie diesen begrenzten Testfall:

• Starten ab `Zustand 0`
• Einen gültigen Startbefehl ausgeben
• Übergang zu `Zustand 10` bestätigen
• Rückmeldung und Übergang zu `Zustand 20` bestätigen
• `OL_Trip = TRUE` erzwingen
• Sofortigen Übergang zu `Zustand 99` verifizieren
• `Motor_Output = FALSE` verifizieren
• Störung löschen und Reset ausgeben
• Übergang zurück zu `Zustand 0` verifizieren

Wenn einer dieser Schritte fehlschlägt, ist das Problem nicht mehr abstrakt. Sie haben nun einen reproduzierbaren Fehlerfall.

Digital Twin Validierung bedeutet in diesem Artikel das Testen von Ladder-Logik gegen ein realistisches simuliertes Maschinenmodell, sodass das Sequenzverhalten unter normalen und anormalen Bedingungen vor der Bereitstellung beobachtet werden kann. Es bedeutet nicht, dass die Simulation ein rechtlicher Ersatz für die Abnahme vor Ort, die funktionale Sicherheitsverifizierung oder die Inbetriebnahme-Freigabe ist.

Diese Grenze ist wichtig. Ein digitaler Zwilling kann die Sequenzvalidierung, das Trainings-Realismus und die Fehlerübung verbessern, aber er eliminiert nicht die Notwendigkeit für anlagenspezifische Überprüfungen, Geräteverifizierung und formale Sicherheitslebenszyklus-Aktivitäten gemäß Normen wie IEC 61508, wo anwendbar (IEC, 2010; exida, 2024).

In OLLA Lab ist die Digital Twin Validierung operativ nützlich, wenn der Ingenieur all das Folgende tun kann:

• Ladder-Zustand mit simuliertem Anlagenverhalten vergleichen
• beobachten, ob E/A-Übergänge wie beabsichtigt erfolgen
• Fehler injizieren und die Reaktion auf den sicheren Zustand verifizieren
• Logik nach einem Fehler überarbeiten
• dasselbe Szenario erneut ausführen, um die Korrektur zu bestätigen

Das ist der Unterschied zwischen Syntax-Übung und Inbetriebnahme-Probe.

Eine Screenshot-Galerie ist kein Engineering-Nachweis. Sie ist nur eine unvollständige Aufzeichnung.

Wenn Sie echte Steuerungskompetenz demonstrieren wollen, bauen Sie einen kompakten Nachweis mit dieser Struktur auf:

1. Systembeschreibung Definieren Sie die Maschine oder Prozesseinheit, ihr Ziel und die relevanten E/A.
2. Operative Definition des korrekten Verhaltens Geben Sie an, was die Sequenz tun muss, welche Rückmeldungen sie erhalten muss und was eine gültige sichere Reaktion darstellt.
3. Ladder-Logik und simulierter Anlagenzustand Zeigen Sie die Zustandslogik, Ausgangslogik und das entsprechende simulierte Verhalten.
4. Der injizierte Fehlerfall Dokumentieren Sie die anormale Bedingung, die Sie eingeführt haben, wie Überlastauslösung, fehlgeschlagene Startprüfung oder Freigabeverlust.
5. Die vorgenommene Überarbeitung Erklären Sie, welche Logik sich geändert hat und warum.
6. Gelernte Lektionen Notieren Sie, was der Fehler über das Sequenzdesign, Annahmen oder fehlende Verriegelungen offenbart hat.

Diese Struktur ist glaubwürdiger, da sie Argumentation, Fehlerbehandlung und Revisionsdisziplin zeigt. Ein sauberer Rung allein zeigt nicht, ob die Logik realistischen Bedingungen standhält.

Strukturierte Ablaufsteuerung, simulationsbasierte Validierung und fehlerbewusstes Testen sind gut auf etablierte Ingenieurpraxis abgestimmt, obwohl die genaue Umsetzung je nach Sektor und Risikoklasse variiert.

Relevante Grundlagen sind:

• IEC 61131-3 für SPS-Programmiersprachen und Prinzipien der strukturierten Steuerungsimplementierung (IEC, 2013)
• IEC 61508 für das Denken im funktionalen Sicherheitslebenszyklus, insbesondere dort, wo anormale Bedingungen und das Verhalten im sicheren Zustand wichtig sind (IEC, 2010)
• exida-Leitlinien zur Disziplin des Sicherheitslebenszyklus, Verifizierungsstrenge und dem Unterschied zwischen Logikabsicht und validiertem Verhalten in industriellen Systemen (exida, 2024)
• Forschungsliteratur zu industrieller Simulation, digitalen Zwillingen und immersiven Trainingsumgebungen, die zeigt, dass simulierte Umgebungen das prozedurale Verständnis, die Fehlerübung und das systemweite Lernen verbessern können, wenn sie an beobachtbare Aufgabenleistung gebunden sind und nicht nur an Neuheit (Tao et al., 2019; Jones et al., 2023; Villalonga et al., 2021)

Die vorsichtige Schlussfolgerung ist nicht, dass Simulation die Arbeit vor Ort ersetzt. Es ist, dass Simulation teures Lernen nach vorne verlagern kann, wo Fehler billiger und sichtbarer sind.

- IEC 61131-3: Programmierbare Steuerungen — Teil 3 - IEC 61508 Übersicht zum Standard für funktionale Sicherheit - NIST Smart Manufacturing Profile - IEEE Access: Digital twin enabling technologies (DOI)