So erstellen Sie ein Portfolio für die SPS-Inbetriebnahme mit Digital-Twin-Validierung in OLLA Lab

Ein glaubwürdiges Portfolio für die SPS-Inbetriebnahme demonstriert validiertes Verhalten, nicht nur Kontaktplan-Syntax. In OLLA Lab bedeutet dies, Logik nach IEC 61131-3, simulierte Anlagenreaktionen, E/A-Kausalität, injizierte Fehlerfälle sowie die Revisionen zu dokumentieren, die nach der Beobachtung abnormaler Zustände in einer risikoisolierten Umgebung vorgenommen wurden.

Statische Screenshots von Kontaktplänen beweisen keine Inbetriebnahme-Kompetenz. Sie zeigen lediglich, dass jemand eine plausibel aussehende Logik zeichnen kann – eine deutlich niedrigere Hürde.

Arbeitgeber interessieren sich dafür, ob ein Kandidat Sequenzverhalten beobachten, E/A-Kausalitäten nachverfolgen, abnormale Zustände handhaben und Logik überarbeiten kann, bevor diese einen realen Prozess beeinflusst. Das ist die operative Bedeutung von "Simulation-Ready": ein Ingenieur, der Steuerungslogik vor dem Einsatz beweisen, beobachten, diagnostizieren und gegen realistisches Prozessverhalten absichern kann.

Eine häufig zitierte Zahl von Aberdeen zu Produktionsausfällen – etwa 260.000 US-Dollar pro Stunde – sollte als grobe Branchenschätzung und nicht als universelle Anlagenkonstante betrachtet werden. Sie unterstreicht jedoch die grundlegende Realität bei der Einstellung: Junior-Ingenieuren wird selten erlaubt, Inbetriebnahme durch "Trial and Error" an laufenden Anlagen zu erlernen.

Ampergon Vallis Metrik: Bei internen Benchmarks über 12 OLLA Lab-Szenariodurchläufe aus der industriellen Preset-Bibliothek der Plattform erforderte die Einführung einer analogen Sensordrift oder eines diskreten Rückmeldefehlers in 9 von 12 Fällen zusätzliche Fehlerbehandlungs- oder Wiederherstellungslogik, bevor der simulierte Prozess in einen akzeptablen Zustand zurückkehrte. Methodik: Stichprobengröße = 12 Szenario-Validierungsläufe; Aufgabenstellung = Vergleich der ursprünglichen "Happy Path"-Logik mit der nach induzierten abnormalen Bedingungen überarbeiteten Logik; Basis-Vergleichswert = Logik des ersten Durchlaufs, die nur die nominale Sequenz erfüllte; Zeitfenster = Ampergon Vallis internes Benchmark-Fenster, Q1 2026. Dies stützt eine eingeschränkte Aussage: Nominale Logik ist oft unzureichend, sobald Fehler eingeführt werden. Es stützt keine allgemeine Fehlerrate der Industrie.

Die Digital-Twin-Validierung zeigt beobachtbares Verhalten unter Bedingungen, die statischer Code nicht abbilden kann. Ein Netzwerk kann korrekt aussehen und dennoch versagen, wenn Zykluszeiten, Sequenzabhängigkeiten, verrauschte Eingänge oder fehlende Freigaben auftreten.

Dies ist der "Sieht-korrekt-aus"-Trugschluss. In der Steuerungstechnik ist visuelle Plausibilität kein Beweis für deterministisches Verhalten. Ein Junior-Ingenieur kann einen Schließer, eine Zuweisung, einen Timer und eine Selbsthaltung korrekt genug platzieren, um im Unterricht zu beeindrucken. Das zeigt jedoch nicht, ob die Sequenz sicher von einem gestauten Förderband, einem defekten Rückmeldeschalter oder einem driftenden Füllstandstransmitter wiederhergestellt werden kann.

Operativ bedeutet Digital-Twin-Validierung den Vergleich einer schriftlichen Steuerungsbeschreibung mit der beobachteten Reaktion der simulierten Anlage unter normalen und abnormalen Bedingungen. Der Test lautet nicht: "Kompiliert das Netzwerk?" Der Test lautet: "Folgt der Maschinenzustand der beabsichtigten Sequenz und schaltet sie sicher ab, wenn sich der Prozess fehlerhaft verhält?"

Dies ist wichtig, da das Risiko bei der Inbetriebnahme asymmetrisch ist. Ein Logikfehler auf dem Papier ist unproblematisch. Ein Logikfehler während der Inbetriebnahme ist meist weniger unproblematisch und manchmal teuer.

In OLLA Lab ist der relevante Arbeitsablauf begrenzt und praxisorientiert:

• Erstellen von Kontaktplan-Logik im webbasierten Editor unter Verwendung von Standard-Befehlstypen
• Ausführen der Logik im Simulationsmodus
• Umschalten von Eingängen und Beobachten von Ausgängen und Variablen in Echtzeit
• Vergleich des Logikzustands mit dem 3D- oder WebXR-Anlagenverhalten
• Überarbeitung der Logik nach induzierten Fehlern oder Sequenzfehlern
• Erneutes Ausführen des Szenarios, bis das beobachtete Verhalten der beabsichtigten Steuerungsphilosophie entspricht

Das macht OLLA Lab nützlich als risikoisolierte Übungsumgebung für Inbetriebnahmeaufgaben. Es zertifiziert keine Standortkompetenz, funktionale Sicherheit oder die Einsatzbereitschaft für unbeaufsichtigtes Arbeiten an realen Anlagen. Es gibt Arbeitgebern jedoch etwas Nützlicheres als einen statischen Screenshot: den Nachweis von technischem Urteilsvermögen unter kontrollierten Bedingungen.

Ein Inbetriebnahme-Portfolio sollte ein exportierbares Entscheidungspaket sein, keine bloße Codesammlung. Personalverantwortliche, Einstellungsmanager und technische Interviewer müssen sehen, was das System tun sollte, was es tatsächlich getan hat, was fehlte und wie die Logik überarbeitet wurde.

Verwenden Sie für jedes Portfolio-Artefakt diese sechsteilige Struktur:

Definieren Sie Erfolg in beobachtbaren Begriffen: Startsequenz, Freigaben, Verriegelungen, Alarmverhalten, Zeitvorgaben, analoge Schwellenwerte und Verhalten im sicheren Zustand.

Führen Sie bewusst eine abnormale Bedingung ein: fehlende Rückmeldung, Sensordrift, klemmender Eingang, Stau, Zeitüberschreitung, verrauschtes Signal oder Skalierungsfehler.

Dokumentieren Sie die exakte Logikänderung: Entprellung, Zeitüberwachung, Erstwert-Speicherung, Umstrukturierung von Freigaben, Alarmkomparator, Wiederholungsbegrenzung oder PID-Anpassung.

1. Systembeschreibung Definieren Sie die Prozesseinheit oder Maschinenzelle. Geben Sie an, was das System ist, welche Ein- und Ausgänge wichtig sind und welcher Betriebskontext gilt.
2. Operative Definition von "korrekt"
3. Kontaktplan-Logik und simulierter Anlagenzustand Zeigen Sie die Kontaktplan-Logik zusammen mit dem simulierten Maschinen- oder Prozesszustand. Hier werden der Kontaktplan-Editor, das Variablen-Panel und die 3D-Simulation von OLLA Lab operativ nützlich.
4. Der injizierte Fehlerfall
5. Die vorgenommene Revision
6. Gelernte Lektionen Geben Sie an, was die ursprüngliche Logik übersehen hat, warum die Revision das Verhalten verbessert hat und welche Annahmen sich geändert haben.

Diese Struktur ist kompakt genug für eine Überprüfung und ernsthaft genug, um relevant zu sein. Ein Ordner voller unbeschrifteter Screenshots ist kein Portfolio.

Ein starkes Portfolio reduziert sich meist auf drei Artefakte, die schnell überprüft und technisch verteidigt werden können.

1. Die Steuerungsbeschreibung

Die Steuerungsbeschreibung definiert das beabsichtigte Verhalten, bevor die Logik bewertet wird. Ohne sie wird "korrekt" zur Geschmackssache, was keine zuverlässige Inbetriebnahme-Methode ist.

Ihre Beschreibung sollte enthalten:

• Operationssequenz
• Start- und Stoppbedingungen
• Freigaben und Verriegelungen
• Alarm- und Abschaltbedingungen
• Erwartungen an die Fehlerbehebung
• Verhalten im manuellen versus automatischen Modus
• Analoge Schwellenwerte, Totzonen oder PID-bezogene Erwartungen

In OLLA Lab können die geführten Bauanleitungen, Szenarioziele, E/A-Zuordnungen und Notizen zur Steuerungsphilosophie helfen, dieses Artefakt zu strukturieren. Der wichtige Punkt ist nicht die Eleganz der Formatierung, sondern die Rückverfolgbarkeit zwischen Absicht und Verhalten.

2. Das Logikpaket nach IEC 61131-3

IEC 61131-3 ist wichtig, da sie die gemeinsame Sprache für Programmiermodelle von speicherprogrammierbaren Steuerungen über verschiedene Hersteller hinweg bietet, auch wenn sich die Implementierungsdetails je nach Plattform unterscheiden. Eine browserbasierte Kontaktplan-Umgebung ist nicht dasselbe wie Studio 5000, TIA Portal oder TwinCAT, aber die zugrunde liegenden Logikstrukturen sind in diesem Ökosystem verständlich.

Für Portfolio-Zwecke sollten Sie Folgendes einbeziehen:

• Kontaktpläne mit klarem Zweck für jedes Netzwerk
• Tag-Verzeichnis mit aussagekräftigen Namen
• E/A-Zuordnung
• Verwendung von Timern, Zählern, Komparatoren, mathematischen Funktionen und PID, wo relevant
• Kommentare, die die Absicht der Sequenz erklären, nicht die offensichtliche Syntax
• Versionierte Revisionen nach Fehlertests

Seien Sie vorsichtig mit Behauptungen zur Hersteller-Portabilität. IEC 61131-3 unterstützt die konzeptionelle Portabilität von Logikstrukturen und Programmiermodellen; sie garantiert keinen reibungslosen Import in jede Herstellerumgebung.

3. Die Validierungsaufzeichnung

Die Validierungsaufzeichnung ist meist das überzeugendste Artefakt, da sie die Sequenz zeigt, wie sie in beobachtbarer Zeit ausgeführt wird und fehlschlägt.

Eine nützliche Aufzeichnung sollte zeigen:

• Die zu testende Kontaktplan-Logik
• Das Variablen-Panel mit relevanten Tags
• Den simulierten Anlagenzustand
• Den Moment der Fehlerinjektion
• Das resultierende Alarm-, Abschalt- oder Sicherheitsverhalten
• Den erneuten Durchlauf nach der Revision

In OLLA Lab ist eine geteilte Ansicht von Kontaktplan-Editor, Variablen-Panel und 3D-Simulation besonders effektiv, da sie den Logikzustand mit dem Anlagenzustand verknüpft. Das ist der Unterschied, der für Einstellungsteams zählt: Syntax versus Einsatzfähigkeit.

Sequenzverifizierung wird glaubwürdig, wenn "korrekt" vor dem Test definiert und mit abnormalen Bedingungen herausgefordert wird. Wenn der einzige Beweis, den Sie zeigen, der nominale Start ist, haben Sie Optimismus dokumentiert, nicht Robustheit.

Arbeitgeber interessieren sich meist mehr für die Fehlerbehandlung als für den "Happy Path". Die meisten Systeme laufen akzeptabel, wenn nichts schiefgeht.

Dokumentieren Sie mindestens diese Verhaltenskategorien:

- Freigaben: Bedingungen, die wahr sein müssen, bevor Bewegung oder Prozessaktion beginnt - Verriegelungen: Bedingungen, die bei Verletzung eine Sperre oder Abschaltung erzwingen - Rückmeldungen: Bestätigung, dass die angesteuerte Anlage tatsächlich reagiert hat - Zeitüberwachungen: maximal zulässige Zeit für den Abschluss eines Sequenzschritts - Alarmspeicherung: ob Fehler bestehen bleiben, bis sie quittiert oder zurückgesetzt werden - Erstwert-Logik: welcher Fehler in einer Kaskade zuerst auftrat - Reset-Philosophie: was wahr sein muss, bevor ein Neustart erlaubt ist - Verhalten im manuellen Modus: welche Schutzfunktionen während Überbrückungs- oder Wartungsmodi aktiv bleiben

Ein nützliches Missverständnis, das hier korrigiert werden sollte, ist, dass Fehlerbehandlung keine "zusätzliche Logik" ist. Es ist der Teil, der die Sequenz ehrlich hält.

In OLLA Lab können Sie diesen Prozess sauber dokumentieren:

• Beginnen Sie mit der beabsichtigten Sequenz aus der Szenariodokumentation
• Verwenden Sie den Simulationsmodus, um das nominale Verhalten zu verifizieren
• Schalten Sie Eingänge um oder passen Sie Variablen an, um abnormale Bedingungen zu erzeugen
• Beobachten Sie Tag-Übergänge im Variablen-Panel
• Vergleichen Sie die Anlagenreaktion in der 3D-Simulation
• Überarbeiten Sie den Kontaktplan und führen Sie denselben Fall erneut aus

Für diskrete Fehler sind Beispiele:

• Motor angesteuert, aber Rückmeldung kommt nie an
• Förderband-Lichtschranke prellt aufgrund verrauschtem Eingang
• Not-Halt-Kette öffnet während der automatischen Sequenz
• Ventil-Öffnen-Befehl erteilt, aber Endschalter bleibt falsch
• Füllstandsschalter bleibt nach Entleerungssequenz auf "hoch" hängen

Für analoge Fehler sind Beispiele:

• Sensordrift führt zu falscher Prozessinterpretation
• Skalierungsfehler verschiebt Alarmschwellen
• PID-Reglerüberschwingen aufgrund schlechter Tuning-Annahmen
• Signal friert beim letzten Wert ein
• Analoger Wert überschreitet plausiblen physikalischen Bereich

Ein Portfolio-Eintrag wird stärker, wenn er den exakten Übergang vom Fehler zur gehärteten Logik zeigt.

Simulation-Ready bedeutet, dass ein Ingenieur die Steuerungsabsicht vor dem Einsatz gegen beobachtetes Prozessverhalten validieren kann. Es ist kein Synonym für "hat einen Simulator benutzt".

Operativ kann ein Simulation-Ready-Ingenieur:

• Die beabsichtigte Sequenz in testbaren Begriffen definieren
• Die Logik gegen einen simulierten Prozess oder eine Maschine ausführen
• E/A-Kausalität beobachten, anstatt vom Aussehen des Netzwerks zu raten
• Abnormale Bedingungen bewusst injizieren
• Diagnostizieren, warum die Sequenz fehlgeschlagen oder degradiert ist
• Die Steuerungslogik überarbeiten und erneut testen
• Den Unterschied zwischen nominalem Erfolg und fehlertolerantem Erfolg erklären

Diese Definition ist strenger als "kann Kontaktplan programmieren". Sie ist auch näher an dem, was Inbetriebnahme-Leiter tatsächlich benötigen.

In OLLA Lab wird diese Einsatzbereitschaft durch einen begrenzten Arbeitsablauf geübt:

• Kontaktplan-Konstruktion im browserbasierten Editor
• Echtzeit-Test im Simulationsmodus
• Tag- und Variableninspektion über das Variablen-Panel
• Szenariobasiertes Anlagenverhalten in 3D- oder WebXR-Ansichten
• Geführte Unterstützung durch GeniAI, wenn der Lernende blockiert ist oder eine korrigierende Erklärung benötigt

Die Rolle von GeniAI sollte ebenfalls vorsichtig formuliert werden. Sie kann die Einarbeitung erleichtern, Konzepte erklären und Benutzern helfen, durch Labore zu kommen, aber KI-Unterstützung ist für sich genommen kein Beweis für technische Kompetenz. Die Generierung von Entwürfen ist keine deterministische Validierung. Der Beweis kommt weiterhin durch beobachtetes Verhalten und dokumentierte Tests.

Ein gutes Portfolio-Projekt sollte einem kleinen Inbetriebnahme-Paket ähneln, nicht einer Unterrichtsübung ohne Konsequenzen. Wählen Sie ein Szenario, in dem Sequenz, Verriegelungen und abnormale Zustände sichtbar sind.

Geeignete Projekttypen sind:

• Leit-/Folge-Pumpensteuerung
• Förderband mit Stauerkennung und Neustart-Logik
• RLT- oder HLK-Sequenz mit Freigaben und Alarmen
• Prozess-Skid mit analogen Schwellenwerten und Abschaltungen
• Tankfüllstandsregelung mit Pumpenschutz
• Verpackungs- oder Lagersequenz mit Sensoren und Schrittlogik

Bauen Sie das Artefakt dann in dieser Reihenfolge auf.

### Schritt 1: System und Umfang definieren

Geben Sie die Maschine oder den Prozess, die Betriebsmodi und die Grenzen des Tests an.

Beispiel für eine Umfangserklärung:

- System: Duplex-Pumpstation - Modi: Auto und Manuell - Eingänge: Füllstandsschalter, HOA-Wahlschalter, Überlastschutz, Not-Halt - Ausgänge: Pumpenbefehl A, Pumpenbefehl B, Alarmhorn - Ziel: Füllstand halten, Führungswechsel, sichere Abschaltung bei Überlast oder Not-Halt

### Schritt 2: "Korrekt" definieren, bevor Logik geschrieben wird

Geben Sie die beobachtbaren Anforderungen an:

• Pumpe startet nur, wenn hoher Füllstand erreicht ist und Freigaben gesund sind
• Führungswechsel nach jedem abgeschlossenen Zyklus
• Folgepumpe startet, wenn Füllstand weiter steigt
• Überlast nimmt betroffene Pumpe außer Betrieb
• Alarm speichert bei fehlgeschlagenem Start oder Überlast
• Manueller Modus umgeht keine kritischen Abschaltbedingungen

Dies ist der Punkt, den viele schwache Portfolios auslassen. Sie zeigen die Antwort, ohne die Frage zu zeigen.

### Schritt 3: Kontaktplan bauen und E/A zuordnen

Verwenden Sie den Kontaktplan-Editor und das Variablen-Panel von OLLA Lab, um die Sequenz zu erstellen und die relevanten Tags zu binden.

Beinhaltet:

• Start-/Stopp-Logik
• Selbsthaltung oder Zustandsbeibehaltung, wo angemessen
• Verriegelungen und Freigaben
• Alarmkomparatoren oder Speicher
• Timer für Rückmeldungs- und Zeitüberwachungsverhalten
• Zähler oder Wechsel-Logik, falls das Szenario dies erfordert

### Schritt 4: Nominale Sequenz ausführen

Demonstrieren Sie, dass sich der Prozess in der simulierten Umgebung wie beabsichtigt verhält.

Aufzeichnen:

• Eingangsübergänge
• Ausgangsbefehle
• Änderungen des Anlagenzustands
• Alle für die Sequenz relevanten analogen Werte

### Schritt 5: Einen Fehler bewusst injizieren

Führen Sie eine realistische abnormale Bedingung ein.

Beispiele:

• Rückmeldung der angesteuerten Pumpe deaktivieren
• Sensor zum Prellen bringen
• Füllstandseingang nach erwartetem Ablauf hoch halten
• Analogen Eingang über die erwartete Toleranz hinaus driften lassen
• Not-Halt während des aktiven Betriebs auslösen

### Schritt 6: Logik überarbeiten und erneut ausführen

Dokumentieren Sie die Revision präzise.

Beispiele für nützliche Revisionen:

• Entprell-Timer für verrauschten Sensor hinzufügen
• Rückmeldungs-Zeitüberwachung mit gespeichertem Alarm hinzufügen
• Erstwert-Fehlererfassung hinzufügen
• Automatischer Neustart nach Not-Halt verhindern, bis Reset-Bedingungen erfüllt sind
• Analoge Plausibilitätsprüfung oder Alarm-Totzone hinzufügen

### Schritt 7: Gelernte Lektionen aufzeichnen

Geben Sie an, was sich in Ihrem Verständnis geändert hat.

Gute Lektionen sind spezifisch:

• "Nominale Sequenz maskierte das Fehlen der Rückmeldung."
• "Reset-Logik erlaubte ursprünglich unsicheren Neustart nach transientem Fehler."
• "Analoger Schwellenwert erforderte Totzone, um Alarmflattern zu verhindern."
• "Manueller Modus musste Abschaltverriegelungen beibehalten."

Dieser letzte Punkt ist in Interviews wichtig, da er Urteilsvermögen statt nur Fertigstellung zeigt.

Fehlerbehebungskompetenz wird am besten als Methode demonstriert, nicht als Persönlichkeitsmerkmal. Interviewer hören meist darauf, wie Sie die Ursache isolieren, nicht darauf, ob Sie selbstbewusst klingen, während Sie raten.

Eine praktische Methode zur Fehlerbehebung in OLLA Lab sieht so aus:

1. Bestätigen Sie die beabsichtigte Sequenz aus der Steuerungsbeschreibung
2. Identifizieren Sie den exakten Schritt, an dem das beobachtete Verhalten abweicht
3. Verfolgen Sie die relevanten Eingänge, Freigaben und Ausgänge im Variablen-Panel
4. Prüfen Sie, ob das Problem Logikzustand, E/A-Annahme, Zeitvorgabe oder analoge Interpretation ist
5. Bilden Sie eine begrenzte Hypothese
6. Ändern Sie eine Sache und führen Sie erneut aus
7. Dokumentieren Sie das Ergebnis

Hier wird die wiederholte Nutzung des Simulators wertvoll. OLLA Lab ermöglicht es Benutzern, die Diagnoseschleife zu üben, ohne auf den Zugang zur Anlage, Hardwareverfügbarkeit oder einen in der Nähe stehenden Ausbilder warten zu müssen.

Der Vorteil im Interview ist prozedural. Wenn ein Einstellungsmanager fragt, warum ein Motor nie gestartet ist, antwortet ein Kandidat mit Simulationspraxis eher in einer Sequenz:

• Befehl verifizieren,
• Freigaben verifizieren,
• Ausgangszustand verifizieren,
• Rückmeldung verifizieren,
• Timer- oder Verriegelungsbedingung verifizieren,
• dann isolieren, ob der Fehler in der Logik, der Instrumentierung oder dem Sequenzdesign liegt.

Diese Antwort spiegelt die wiederholte Beobachtung von Logikverhalten in einer kontrollierten Umgebung wider.

Digital-Twin-Validierung sollte als Beweis für Übung und logisches Denken präsentiert werden, nicht als Ersatz für Standort-Inbetriebnahme, FAT, SAT oder funktionale Sicherheitsverifizierung.

Eine vorsichtige Portfolio-Behauptung wäre:

• "Dieses Projekt demonstriert, dass ich eine Steuerungsbeschreibung definiert, Kontaktplan-Logik implementiert, nominales Verhalten in der Simulation validiert, einen Fehler injiziert, die Logik überarbeitet und das resultierende Verhalten dokumentiert habe."

Eine unvorsichtige Behauptung wäre:

• "Dies beweist, dass ich voll bereit bin, jede Anlage in Betrieb zu nehmen."

Stellen Sie nicht die zweite Behauptung auf. Seriöse Prüfer werden sie sofort abwerten.

Der Kontext der Normen ist hier wichtig. IEC 61131-3 ist relevant für die Programmierstruktur. IEC 61508 und verwandte Praktiken der funktionalen Sicherheit sind relevant für das Denken im Sicherheitslebenszyklus, Gefahrenreduzierung und Verifizierungsdisziplin. Aber Simulationsarbeit in einer Trainingsumgebung ist nicht gleichbedeutend mit formeller Sicherheitsvalidierung oder SIL-Bestimmung. Das sind unterschiedliche Verpflichtungen mit unterschiedlichen Anforderungen an den Nachweis.

Richtig eingesetzt, hilft OLLA Lab Kandidaten dabei, Verhaltensweisen zu demonstrieren, denen Arbeitgeber vertrauen können:

• Sequenzlogik,
• Fehlerbewusstsein,
• E/A-Kompetenz,
• Revisionsdisziplin,
• und die Fähigkeit, Steuerungsabsicht mit beobachteter Maschinenreaktion zu vergleichen.

Unten finden Sie eine prägnante Struktur, die Sie wiederverwenden können.

### Beispiel Portfolio-Eintrag: Stauerkennungs-Förderbandsequenz

1) Systembeschreibung Motorbetriebenes Förderband mit Startfreigabe, Lichtschranken-Produkterkennung, Stau-Zeitüberwachung, Überlastschutz und Alarm-Reset.

2) Operative Definition von "korrekt" Förderband startet nur, wenn Freigaben gesund sind, läuft bei Befehl, alarmiert, wenn Produkt über die Zeitvorgabe hinaus blockiert bleibt, schaltet bei Überlast ab und führt keinen automatischen Reset aus dem Fehlerzustand aus, ohne dass Reset-Bedingungen erfüllt sind.

3) Kontaktplan-Logik und simulierter Anlagenzustand Kontaktplan enthält Motorbefehlsnetzwerk, Rückmeldungsprüfung, Stau-Timer, Alarmspeicher und Reset-Freigabe. OLLA Lab-Simulation zeigt Förderbandzustand, blockierten Produktzustand und Tag-Übergänge im Variablen-Panel.

4) Der injizierte Fehlerfall Lichtschranke wird blockiert gehalten, während der Laufbefehl aktiv bleibt, was einen gestauten Förderbandabschnitt simuliert.

5) Die vorgenommene Revision Erstwert-Stauspeicher hinzugefügt, Trennung der Rückmeldungs-Zeitüberwachung vom Überlastalarm und Reset-Bedingung hinzugefügt, die eine freie Lichtschranke plus Bediener-Reset erfordert.

6) Gelernte Lektionen Ursprüngliche Logik erkannte den Stau, erlaubte aber ein zweideutiges Reset-Verhalten. Überarbeitete Logik verbesserte die Diagnosefähigkeit und verhinderte unsicheres oder verwirrendes Neustartverhalten.

- IEC 61508 Überblick über funktionale Sicherheit - IEC 61131-3 Programmiersprachen für speicherprogrammierbare Steuerungen - NIST SP 800-207 Zero Trust Architektur - Tao et al. (2019) Digital Twin in der Industrie (IEEE) - Kritzinger et al. (2018) Digital Twin in der Fertigung (IFAC) - Negri et al. (2017) Digital Twin in CPS-basierten Produktionssystemen - exida Ressourcen zur funktionalen Sicherheit - U.S. Bureau of Labor Statistics