Funktionsweise des SPS-Scan-Zyklus: Simulation deterministischer Ausführung in OLLA Lab

Ein SPS-Scan-Zyklus ist eine deterministische Schleife, in der die Steuerung Eingänge liest, Logik sequentiell ausführt, Ausgänge schreibt und Systemaufgaben durchführt. OLLA Lab ahmt dieses Verhalten in einer browserbasierten Simulationsumgebung nach, sodass Ingenieure scan-abhängige Fehler beobachten, Logikrevisionen testen und Ursache-Wirkungs-Zusammenhänge vor der Live-Inbetriebnahme validieren können.

Ein weit verbreitetes Missverständnis ist, dass Kontaktplan-Logik (Ladder Logic) wie gewöhnliche Software reagiert, die sofort auf Ereignisse antwortet. Das tut sie nicht. Eine SPS fragt die Realität normalerweise in einem wiederkehrenden Scan ab, wertet die Logik in einer definierten Reihenfolge aus und aktualisiert die Ausgänge erst nach Abschluss dieser Auswertung. Dieser Unterschied entscheidet darüber, ob ein Code nur korrekt aussieht oder an einer Maschine tatsächlich funktioniert.

Während einer internen Evaluierung des Hochgeschwindigkeits-Sortierszenarios von OLLA Lab konnten 68 % der Junior-Anwender einen 10-ms-Impuls eines optischen Sensors nicht erfassen, wenn die simulierte Scanzeit auf 20 ms eingestellt war [Methodik: n=41 Anwender; Aufgabe = Erkennung und Speicherung eines transienten Lichtschranken-Impulses in einem Ausschleusungsszenario; Basis-Vergleichswert = erfolgreiche Impulserfassung bei 5 ms simuliertem Scan; Zeitfenster = 15. Jan. – 10. März 2026]. Dies ist ein interner Benchmark von Ampergon Vallis und kein Anspruch auf allgemeine Branchenprävalenz. Er stützt jedoch einen wichtigen Punkt: Das Scan-Timing wird oft schlecht verstanden, selbst wenn die Logik im Netzwerk syntaktisch korrekt erscheint.

Genau hier ist OLLA Lab nützlich. Es bietet eine begrenzte Software-in-the-Loop-Umgebung zur Beobachtung deterministischer Ausführung, E/A-Sichtbarkeit und scan-abhängiger Fehlermodi, bevor diese Lektion an einer echten Maschine gelernt werden muss, wo die Fehlerkosten deutlich höher sind.

Ein Standard-SPS-Scan-Zyklus ist eine wiederkehrende, deterministische Sequenz mit vier funktionalen Phasen. Die genaue Implementierung variiert je nach Hersteller und Aufgabenmodell, aber das Grundmuster ist bei konventioneller zyklischer Ausführung stabil.

Der entscheidende ingenieurtechnische Punkt ist einfach: Das Programm liest normalerweise nicht bei jedem Befehl einen frischen physischen Eingang. Es arbeitet während der Ausführung mit einem Speicherabbild und aktualisiert die Ausgänge erst danach.

1. Eingangs-Scan (Lesen) Die Steuerung liest den aktuellen Zustand der physischen Eingänge und kopiert diese Zustände in den Speicher, oft als Eingangsabbild oder Prozessabbild bezeichnet.
2. Programmausführung (Logik) Die Steuerung führt das Anwenderprogramm unter Verwendung der gespeicherten Eingangszustände aus. In der Kontaktplan-Logik wird dies typischerweise innerhalb der aktiven Aufgabe oder Routine von oben nach unten und von links nach rechts ausgewertet.
3. Ausgangs-Scan (Schreiben) Die Steuerung schreibt die final berechneten Ausgangszustände aus dem Speicher auf die physischen Ausgangsklemmen.
4. Housekeeping (Kommunikation/Diagnose) Die Steuerung führt interne Diagnosen, Kommunikation, Timer-Aktualisierungen, Messaging und andere Systemaufgaben durch.

Warum dies in der Praxis wichtig ist

Scan-basierte Ausführung erzeugt vorhersehbare, aber nicht offensichtliche Verhaltensweisen:

• Ein kurzer Impuls kann verpasst werden, wenn er zwischen den Scans auftritt.
• Eine Spule, die zweimal in einem Scan beschrieben wird, kann unbemerkt überschrieben werden.
• Ein Ausgang, der in einem Netzwerk als "wahr" erscheint, wird physisch möglicherweise nie angesteuert, wenn ein späteres Netzwerk ihn vor der Ausgangsaktualisierungsphase zurücksetzt.
• Timing-Annahmen, die auf dem Bildschirm harmlos erscheinen, können bei realer Prozessdynamik versagen.

Deshalb ist das Beherrschen der Kontaktplan-Syntax nicht dasselbe wie Simulationsreife. Operativ gesehen kann ein simulationsreifer Ingenieur Steuerungslogik beweisen, beobachten, diagnostizieren und gegen realistisches Prozessverhalten absichern, bevor sie auf einen Live-Prozess trifft.

Allgemeine IT-Sprachen sind nicht grundsätzlich falsch für Software. Sie sind jedoch falsch, um SPS-Ausführung zu erklären, wenn das Steuerungsmodell ignoriert wird. Das Problem ist nicht das Ansehen der Sprache, sondern die Ausführungssemantik.

IT-Ausführung versus OT-Ausführung

| Merkmal | IT-Sprachen (Python/JavaScript, allgemein) | OT / SPS-Ausführung (IEC 61131-3 Kontext) | |---|---|---| | Primäres Auslösemodell | Ereignisgesteuert, Callback-gesteuert oder Scheduler-gesteuert | Zyklisches Polling und deterministische Aufgabenausführung | | Speicherbeziehung | Dynamische Zuweisung ist üblich | Vordefinierte Tags, strukturierter Speicher, direkte Prozessabbildung | | Hardware-Interaktion | Meist über Treiber/APIs abstrahiert | Direkte Beziehung zu E/A-Abbildern, Feldzuständen und Scan-Timing | | Ausführungs-Timing | Auf Anwendungsebene oft nicht deterministisch | Ausgelegt auf wiederholbare, begrenzte Steuerungsausführung | | Fehlermodus | Latenz, Race Conditions, Probleme mit der Callback-Reihenfolge | Verpasste Impulse, Überschreibungslogik, Annahmen über veraltete Abbilder | | Ingenieur-Priorität | Durchsatz, Flexibilität, Benutzerinteraktion | Determinismus, Wiederholbarkeit, sicheres Maschinenverhalten |

IEC 61131-3 definiert die Programmiersprachen und Ausführungskonzepte, die in der industriellen Steuerung verwendet werden, einschließlich Kontaktplan (LD), Funktionsbausteinsprache (FBD), Strukturierter Text (ST) und Ablaufsprache (SFC) (IEC, 2013). In der Praxis hängt die SPS-Steuerung von deterministischem Aufgabenverhalten, expliziter Zustandsbehandlung und vorhersehbarer Scan-Reihenfolge ab. Web-Software geht oft davon aus, dass die Welt auf das nächste Ereignis warten kann. Pumpen, Zylinder und Förderbänder können das meist nicht.

Der wichtige Kontrast

Der klare Kontrast lautet: Ereignisreaktion versus zyklische Steuerung.

Dieser Unterschied ist wichtig, weil es bei der physischen Automatisierung nicht nur darum geht, ein Ergebnis zu berechnen. Es geht darum, das Ergebnis zur richtigen Zeit, in der richtigen Reihenfolge und unter sich ändernden Anlagenbedingungen zu berechnen.

Sequentielle Kontaktplan-Ausführung bedeutet, dass die Steuerung die Logik in einer definierten Reihenfolge auswertet, nicht alles auf einmal. In einem konventionellen Scan wird das Programm Netzwerk für Netzwerk gelöst, von oben nach unten in der Routine und innerhalb jedes Netzwerks von links nach rechts gemäß den Ausführungsregeln der Plattform.

Beobachtbare Konsequenzen der sequentiellen Ausführung

- Die Fehlersuche muss unterscheiden zwischen:

• Frühere Logik kann ein internes Bit setzen, das spätere Logik sofort verwendet.
• Spätere Logik kann ein Ergebnis überschreiben, das früher im selben Scan festgelegt wurde.
• Zwischenzustände können während der Ausführung im Speicher existieren, obwohl sich der physische Ausgang noch nicht geändert hat.
• Tag-Zustand im Speicher
• Physischer Ausgangszustand an der Klemme

Diese Unterscheidung ist im Klassenzimmer leicht zu übersehen und bei der Inbetriebnahme schwer zu ignorieren.

IEC-Grundlagen

IEC 61131-3 bietet den Sprachrahmen, aber die Herstellerdokumentation und die Laufzeitarchitektur bestimmen die genauen Details der Aufgabenplanung und Aktualisierung. Die sichere Aussage lautet: Sequentielle Auswertung und zyklische Ausführung sind grundlegende Verhaltensweisen in gängigen SPS-Steuerungssystemen, auch wenn sich die Implementierungsdetails je nach Steuerungsfamilie unterscheiden.

Das Doppelspulen-Syndrom tritt auf, wenn derselbe Ausgang oder dieselbe interne Spule an mehr als einer Stelle beschrieben wird, wodurch eine spätere Anweisung eine frühere während desselben Scans überschreiben kann. Der letzte Zustand, der bei der Logikausführung geschrieben wird, ist derjenige, der bis zur Ausgangsaktualisierungsphase überlebt.

Hier ist das klassische Muster:

NETZWERK 1: Startbefehl setzt Motor_Run im Speicher auf wahr. |---[ Start_Taster ]-------------------------------------( Motor_Run )---|

NETZWERK 2: Eine spätere Bedingung schreibt auf dieselbe Spule. Wenn dieses Netzwerk falsch ausgewertet wird und das Ziel deaktiviert, wird der frühere Zustand effektiv überschrieben, bevor die Ausgänge geschrieben werden. |---[ Andere_Bedingung ]---------------------------------( Motor_Run )---|

Was tatsächlich passiert

- Ergebnis: Der Motor läuft möglicherweise nie an, obwohl ein früheres Netzwerk korrekt aussah.

• Das erste Netzwerk schreibt `Motor_Run = TRUE` in den Speicher.
• Ein späteres Netzwerk schreibt auf dasselbe Ziel.
• Der letzte Schreibvorgang bestimmt den finalen Speicherzustand am Ende der Ausführung.
• Die physische Ausgangsaktualisierung erfolgt danach.

Dies ist deterministische Ausführung, die genau das tut, was die Logik vorgibt, unabhängig von der Absicht.

Warum dieser Fehler für das Training nützlich ist

Doppelspulen-Fehler verdeutlichen schnell drei Kernideen:

• Die Reihenfolge ist wichtig
• Speicherzustand ist nicht dasselbe wie Klemmenzustand
• Visuelle Korrektheit eines Netzwerks reicht nicht aus

In OLLA Lab wird dies beobachtbar statt theoretisch, da Anwender die Logik ausführen, Variablen inspizieren und den Kontaktplan-Zustand mit dem simulierten Anlagenverhalten vergleichen können.

Ein kurzer Impuls kann verpasst werden, wenn seine Dauer kürzer ist als die effektive Möglichkeit der Steuerung, ihn abzutasten. Wenn ein Eingang zwischen den Eingangs-Scans ein- und ausschaltet, registriert die CPU das Ereignis möglicherweise nie im Eingangsabbild.

### Beispiel: Impulsbreite versus Scan-Zeit

Wenn:

• ein Lichtschranken-Impuls 10 ms dauert und
• die Steuerung die Eingänge alle 20 ms abtastet,

dann kann der Impuls vollständig zwischen den Scans auftreten und aus der Perspektive des Programms verschwinden.

Dies ist ein Abtastproblem. In der Steuerungstechnik erscheint es oft als: „Der Sensor hat definitiv ausgelöst, aber die SPS hat es nie gesehen.“ Beide Aussagen können wahr sein.

Warum Ingenieure darauf achten sollten

Verpasste Impulse betreffen:

• Hochgeschwindigkeits-Sortierung
• Geber-nahe Logik
• Ausschleusungsbestätigung
• Flaschen- oder Kartonzählung
• intermittierende Prüfsignale
• flankengetriggerte Alarme

Die Lösung kann schnellere Aufgaben, Hardware-Speicherung, Impulsverlängerung, Monoflops, schnelle Zähler oder ein überarbeitetes Sequenzdesign erfordern. Die richtige Antwort hängt vom Prozess und der Architektur der Steuerung ab.

OLLA Lab ahmt das physische CPU-Scannen nach, indem es eine strukturierte Simulationsumgebung bereitstellt, in der Kontaktplan-Logik als deterministische Schleife ausgeführt wird und nicht als lose Browser-Ereignisreaktionen. Einfacher ausgedrückt: Es wurde entwickelt, damit Anwender scan-abhängiges Steuerungsverhalten beobachten können, anstatt nur Netzwerke zu zeichnen.

Was OLLA Lab in begrenztem Rahmen tut

Innerhalb der Plattform können Anwender:

• Kontaktplan-Logik in einem webbasierten Editor erstellen
• Logik im Simulationsmodus ausführen
• Eingänge, Ausgänge und Variablen umschalten und inspizieren
• realistische industrielle Szenarien durcharbeiten
• das Kontaktplan-Verhalten mit 3D/WebXR/VR-Anlagenansichten vergleichen (sofern verfügbar)
• GeniAI, den KI-Laborassistenten, für geführte Unterstützung nutzen

Für den Umfang dieses Artikels ist der wichtige Produktfakt enger gefasst: OLLA Lab bietet eine softwarebasierte Umgebung zum Trainieren deterministischer Logikausführung und zur Beobachtung, wie sich das Scan-Timing auf das Maschinenverhalten auswirkt.

Beobachtbare Verhaltensweisen, die die Plattform demonstrieren kann

• Doppelspulen-Überschreibungsverhalten
• Verpasste transiente Impulse
• Ursache-Wirkungs-Verfolgung über E/A
• Sequenzfehler durch veraltete Annahmen über Zustände
• Unterschiede zwischen Kontaktplan-Zustand und simuliertem Anlagenzustand

Das macht es nützlich als Software-in-the-Loop-Trainingsumgebung für risikoreiche Inbetriebnahmeaufgaben. Es ersetzt nicht die Hardware-Abnahmeprüfung, Sicherheitsvalidierung oder standortspezifische Inbetriebnahme. Diese gehören weiterhin zum realen System, mit der realen Steuerung, unter den realen Bedingungen.

Warum die Browser-Bereitstellung wichtig ist

Eine browserbasierte Umgebung senkt die Einstiegshürden für Lernen und Überprüfung. Noch wichtiger ist, dass sie wiederholte, risikoarme Fehlerinjektionen ermöglicht, ohne einen physischen Trainer oder produktionsnahe Hardware zu binden.

In diesem Kontext bedeutet Digital Twin Validation das Testen von Kontaktplan-Logik gegen ein simuliertes Maschinen- oder Prozessmodell und die Überprüfung, ob das erwartete Anlagenverhalten unter normalen und anormalen Bedingungen mit der Steuerungsphilosophie übereinstimmt.

Diese Definition muss geerdet bleiben. Sie bedeutet nicht, dass die Simulation ein rechtlich ausreichender Ersatz für die Standortabnahme (SAT), SIL-Verifizierung oder Anlageninbetriebnahme ist.

### Operativ umfasst die Digital Twin Validation:

• Vergleich von Befehlszuständen mit der simulierten Anlagenreaktion
• Überprüfung der Sequenzreihenfolge und Freigabebedingungen
• Überprüfung des Alarm- und Abschaltverhaltens
• Beobachtung von analogen oder PID-gesteuerten Zustandsänderungen (sofern modelliert)
• Injizieren von Fehlern und Bestätigung der Logikreaktion
• Überarbeitung des Programms und erneutes Testen

Hier wird OLLA Lab operativ nützlich. Es ermöglicht Ingenieuren zu testen, ob eine Sequenz an einem realistischen Modell funktioniert, bevor sie diese an Anlagen testen, die klemmen, überlaufen, überfahren oder auf andere Weise kostspielig ausfallen können.

Ingenieure sollten scan-abhängige Fehlerbehandlung üben, indem sie Szenarien erstellen, in denen die Logik aus Timing-Gründen zum Scheitern gezwungen wird, und dann das Design überarbeiten, bis der Fehlermodus kontrolliert und erklärbar ist.

### Eine praktische Übung: Impulserfassung in einem Förderszenario

Verwenden Sie ein Szenario im Stil einer Förder- oder Sortieranlage und definieren Sie ein transientes Sensorereignis, das kürzer ist als das simulierte Scan-Intervall.

#### Schritt 1: Erstellen der anfänglichen Logik

Erstellen Sie eine Logik, die direkt von einem Lichtschranken-Impuls abhängt, um eine Aktion wie Ausschleusen, Zählen oder Umleiten auszulösen.

#### Schritt 2: Festlegen der simulierten Bedingungen

Verwenden Sie ein Scan-Intervall, das länger ist als die Impulsdauer. Führen Sie dann das Szenario aus und beobachten Sie, ob das Ereignis zuverlässig erfasst wird.

#### Schritt 3: Inspizieren von Variablen und Anlagenzustand

Verwenden Sie das Variablen-Panel, um Folgendes zu vergleichen:

• Eingangszustand
• interne Speicherbits
• Ausgangsbefehle
• simulierte Anlagenreaktion

#### Schritt 4: Injizieren des Fehlerfalls

Erzwingen Sie einen Impuls, der für die aktuellen Scan-Annahmen zu schnell auftritt. Bestätigen Sie, dass die Logik ihn verpasst.

#### Schritt 5: Überarbeiten der Logik

Mögliche Überarbeitungen umfassen:

• Hinzufügen eines Speichers oder einer Selbsthaltung
• Verwendung von Flankenerkennung, wo angebracht
• Verlängerung des Impulses in der Logik
• Neugestaltung der Sequenz, um die Abhängigkeit von einem schmalen Transienten zu vermeiden
• Dokumentation, wann Hardware-Funktionen in einer echten Steuerung erforderlich wären

#### Schritt 6: Erneutes Ausführen und Verifizieren

Validieren Sie, dass die überarbeitete Logik das Ereignis unter den definierten Bedingungen erfasst und keine Fehlalarme oder unsichere Persistenz erzeugt.

Eine Screenshot-Galerie beweist nur, dass Software geöffnet wurde. Sie beweist kein ingenieurtechnisches Urteilsvermögen. Wenn ein Lernender echtes Steuerungsverständnis demonstrieren möchte, sollte das Artefakt Argumentation, Fehlerbehandlung und Revisionsdisziplin zeigen.

Verwenden Sie diese Struktur:

Geben Sie genau an, was korrektes Verhalten bedeutet. Beispiel: „Ein 10-ms-Produkterkennungsimpuls muss erfasst und gespeichert werden, damit die Ausschleusungssequenz genau einmal ausgeführt wird.“

Dokumentieren Sie den scan-abhängigen Fehler. Beispiel: „Impuls wurde verpasst, als die Scan-Zeit die Impulsbreite überschritt.“

1. Systembeschreibung Definieren Sie die Maschine oder den Prozessabschnitt, das Steuerungsziel und die relevanten E/A.
2. Operative Definition des korrekten Verhaltens
3. Kontaktplan-Logik und simulierter Anlagenzustand Zeigen Sie die relevanten Netzwerke, Tags und das entsprechende simulierte Maschinenverhalten.
4. Der injizierte Fehlerfall
5. Die vorgenommene Überarbeitung Erklären Sie, was sich in der Logik geändert hat und warum.
6. Gelernte Lektionen Fassen Sie das Steuerungsprinzip zusammen, wie z. B. Timing des Abbildspeichers, Überschreibungsverhalten oder warum Impulserfassung explizites Design erfordert.

Das ist die Art von Nachweis, die ein Prüfer hinterfragen kann. Es ist auch die Art, die in einer technischen Überprüfung tendenziell besser besteht als ein Screenshot allein.

Scan-Zyklus-Simulation ist wertvoll, weil sie unsichtbares Steuerungsverhalten beobachtbar macht. Ihre Grenzen sind genauso wichtig.

Eine begrenzte Aussage darüber, was Simulation kann und was nicht

Simulation kann Ingenieuren helfen:

• deterministische Ausführung zu verstehen
• Sequenzlogik zu testen
• Timing-bezogene Fehler zu beobachten
• Fehlersuche zu trainieren
• erwartetes und simuliertes Anlagenverhalten zu vergleichen

Simulation kann nicht allein:

• Standortkompetenz zertifizieren
• hardwarespezifische Validierung ersetzen
• funktionale Sicherheitskonformität herstellen
• finales Feldbus-Timing-Verhalten beweisen
• FAT, SAT, Loop-Checks oder Live-Inbetriebnahme ersetzen

Diese Grenze ist keine Schwäche. Sie ist Teil dessen, was das Werkzeug glaubwürdig macht.

Simulationsbasiertes Training und digitale Modelle sind in der Industrie etabliert, insbesondere dort, wo direkte Experimente an Live-Anlagen kostspielig oder unsicher sind. Die Literatur unterstützt Simulation im Allgemeinen als Weg, das Verständnis für dynamisches Verhalten, Fehlerreaktion und die Vorbereitung von Bedienern oder Ingenieuren zu verbessern, betont jedoch gleichzeitig, dass Modelltreue und Aufgabendesign die Nützlichkeit bestimmen.

Relevante Standards und technische Grundlagen

• IEC 61131-3 definiert Rahmenwerke für SPS-Programmiersprachen und Ausführungskonzepte, die für das Verhalten von Kontaktplan-Logik relevant sind (IEC, 2013).
• IEC 61508 etabliert den breiteren Rahmen für funktionale Sicherheit und bekräftigt, dass Sicherheitsansprüche disziplinierte Nachweise über den Lebenszyklus erfordern, nicht allein informelles Simulationsvertrauen (IEC, 2010).
• exida und verwandte Leitfäden zur funktionalen Sicherheit betonen Verifizierung, Validierung und Lebenszyklus-Strenge bei sicherheitsbezogenen Automatisierungsarbeiten.
• Forschung im Bereich industrielle Simulation, digitale Zwillinge und Trainingsumgebungen hat den Wert bei der Fehlerrehearsal, der Vorbereitung auf die Inbetriebnahme und dem menschlichen Verständnis dynamischer Systeme gezeigt, insbesondere wenn die Simulation an beobachtbares Prozessverhalten gebunden ist und nicht nur an abstrakte Anweisungen.

Das vorsichtige Fazit lautet: Simulation ist am stärksten, wenn sie dazu verwendet wird, Verhalten aufzudecken, Annahmen zu testen und das Urteilsvermögen vor der Bereitstellung zu verbessern. Sie ist am schwächsten, wenn sie als Abkürzung für ingenieurtechnische Nachweise behandelt wird.

Scan-Zyklus-Kompetenz ist wichtig, weil deterministische Steuerung für Menschen, die auf ereignisgesteuerte Software oder statische Kontaktplan-Beispiele trainiert sind, nicht intuitiv ist. Eine SPS bemerkt nicht alles in dem Moment, in dem es passiert. Sie tastet ab, löst, schreibt und wiederholt.

Deshalb hat OLLA Lab einen legitimen Platz im Workflow. Es gibt Ingenieuren eine begrenzte Umgebung, um die Scan-Reihenfolge zu beobachten, den E/A-Zustand zu inspizieren, Fehler zu injizieren und Logik zu überarbeiten, bevor dieselben Fehler einen Live-Prozess erreichen. Es geht nicht darum, Simulation beeindruckend aussehen zu lassen. Es geht darum, Fehler sichtbar zu machen, solange die Kosten für einen Irrtum noch tolerierbar sind.

In praktischen Begriffen ist das der Schritt von der Syntax zur Einsatzfähigkeit.

- IEC 61131-3: Programmable controllers — Part 3 - IEC 61508 functional safety standard overview - NIST Smart Manufacturing Profile - IEEE Access: Digital twin enabling technologies (DOI)

Das Team von Ampergon Vallis Lab entwickelt Werkzeuge zur Verbesserung der industriellen Ausbildung und zur Validierung von Steuerungslogik.

Dieser Artikel wurde auf technische Genauigkeit bezüglich der IEC 61131-3 Ausführungsmodelle und der deterministischen SPS-Scan-Logik geprüft.