Validierung von SPS-Logik mittels Software-in-the-Loop (SITL) und OLLA Lab Digital Twins

Software-in-the-Loop (SITL)-Tests in der industriellen Automatisierung bezeichnen die Ausführung von SPS-Steuerungslogik gegen ein Softwaremodell des Anlagenverhaltens anstelle von physischer Hardware. In OLLA Lab kann Kontaktplan-Logik (Ladder Logic) gegen 3D-Digital Twins getestet werden, um Ablaufzeiten, Verriegelungen, das Verhalten bei anormalen Zuständen und die Fehlerwiederherstellung vor der Live-Inbetriebnahme zu verifizieren.

Syntaktisch korrekte Kontaktplan-Logik ist nicht gleichbedeutend mit einsatzfähiger Steuerungslogik. Ein Compiler kann die Gültigkeit von Befehlen, die Konsistenz von Tags und die grundlegende Ausführungsreihenfolge bestätigen; er kann jedoch nicht sagen, ob ein Förderband in einen ausgefahrenen Zylinder indexiert, ob eine Neustartsequenz gefährliche Bewegungen wieder unter Spannung setzt oder ob ein Sensor zu spät eintrifft, um den Mechanismus zu schützen. Syntax ist kostengünstig. Fehler bei der Inbetriebnahme sind es nicht.

Eine nützliche Definition von „simulationsbereit“ ist operativ, nicht aspirativ: Ein Ingenieur ist simulationsbereit, wenn er Steuerungslogik vor Erreichen eines Live-Prozesses beweisen, beobachten, diagnostizieren und gegen realistisches Prozessverhalten absichern kann.

In einer internen Analyse von Ampergon Vallis von 1.200 simulierten Inbetriebnahmeszenarien, die in OLLA Lab durchgeführt wurden, identifizierten Anwender, die Logik gegen einen 3D-Digital Twin validierten, 84 % der modellierten mechanischen Race Conditions vor der ersten physischen Ausführung. Methodik: Stichprobengröße = 1.200 Szenariodurchläufe über voreingestellte und benutzerdefinierte Labs; Aufgabendefinition = Erkennung modellierter Race Conditions wie überlappende Betätigungen und Indexierungskonflikte; Basis-Vergleichswert = Logikprüfung und kompilierfähiger Zustand ohne Digital-Twin-Ausführung; Zeitfenster = Januar 2025 bis Februar 2026. Dies stützt die Behauptung, dass Simulation Fehlerklassen aufdecken kann, die gewöhnliche Syntaxprüfungen übersehen. Sie beweist weder die Zuverlässigkeit im Feld, noch die Kompetenz des Bedieners oder die Sicherheitszertifizierung.

SITL, HIL und physische Inbetriebnahme beantworten unterschiedliche Validierungsfragen. Sie als austauschbar zu betrachten, ist ein sicherer Weg, Risiken zu übersehen.

Unter dem im VDI 3693 beschriebenen Rahmenwerk für die virtuelle Inbetriebnahme bedeutet Software-in-the-Loop (SITL), dass sowohl die Steuerungslogik als auch das Anlagenverhalten in Software abgebildet sind, ohne dass die physische SPS, die Feldverdrahtung oder die Maschinenhardware vorhanden sein müssen. Ziel ist es, das Steuerungsverhalten gegen die simulierte Prozessreaktion in einer risikokontrollierten Umgebung zu validieren.

Hardware-in-the-Loop (HIL) bewegt sich einen Schritt näher an die Realität. Die Anlage bleibt simuliert, aber die tatsächliche Controller-Hardware wird eingeführt. Dies testet Hardware-Zeitverhalten, E/A-Verarbeitung und einige plattformspezifische Verhaltensweisen, die SITL nicht vollständig reproduzieren kann.

Die physische Inbetriebnahme ist das vollständige Paket: Steuerungslogik, physische SPS, Verkabelung, Instrumentierung, Aktoren, Maschinendynamik und die Überraschungen, die auftreten, wenn all dies beim Anfahren aufeinandertrifft.

### Vergleich: SITL vs. HIL vs. physische Inbetriebnahme

| Validierungsmodus | Was ist real | Was ist simuliert | Hauptzweck | Risikostufe | |---|---|---|---|---| | SITL | Ausführungsumgebung der Steuerungslogik | Anlagen-/Geräteverhalten | Validierung von Ablauflogik, Verriegelungen, Zeitannahmen, Zustandsübergängen, Fehlerbehandlung | Niedrig | | HIL | Physische SPS/Controller-Hardware | Anlagen-/Geräteverhalten | Validierung der controllerspezifischen Ausführung, E/A-Verhalten, Hardware-Zeitverhalten, Integrationsannahmen | Mittel | | Physische Inbetriebnahme | SPS, Verkabelung, Sensoren, Aktoren, Maschine/Prozess | Wenig oder keine | Validierung des eingesetzten Systems unter tatsächlichen Betriebsbedingungen | Hoch |

Was SITL gut kann

• Verifizierung der Ablaufreihenfolge und Freigabelogik
• Testen von Alarm- und Abschaltverhalten
• Üben von Neustart- und Wiederherstellungslogik
• Aufdecken von Race Conditions zwischen Befehlen und Rückmeldungen
• Proben von anormalen Zuständen, ohne die Ausrüstung zu gefährden

Was SITL nicht ersetzt

• Abnahmeprüfungen vor Ort (Site Acceptance Testing)
• Schleifenprüfungen und Verdrahtungsüberprüfung
• Validierung der funktionalen Sicherheit
• SIL-Bestimmung oder Nachweis der Konformität
• Bedienerschulung an der exakt installierten Anlage, sofern der Modellumfang dies nicht unterstützt

Diese Grenze ist wichtig. Ein Digital Twin ist nützlich, weil er Unsicherheit verringert, nicht weil er sie beseitigt.

Kontaktplan-Logik scheitert in der Praxis, weil physische Systeme keine booleschen Diagramme sind. Sie haben Verzögerungen, Trägheit, Reibung, Drift und Fehlermodi, die ein Compiler nicht modelliert.

Ein kompilierfähiger Kontaktplan kann dennoch eine unmögliche Sequenz befehlen. Er kann auch eine mögliche Sequenz zur falschen Zeit befehlen, was oft schlimmer ist, da es nur sporadisch auftritt.

Die drei physikalischen Realitäten, die Compiler ignorieren

1. Mechanische Trägheit Ein Stopp-Befehl führt nicht zu einem sofortigen Stillstand. Motoren laufen aus, Förderbänder überfahren ihre Position und hängende Lasten bewegen sich weiter. Die Logik mag auf Scan-Ebene korrekt sein, aber auf Maschinenebene falsch.
2. Sensorlatenz Echte Sensoren haben Ansprechzeiten, Montagetoleranzen, Prellen und Filterung. Eine Lichtschranke oder ein Endschalter, der seinen Zustand einige Millisekunden später als erwartet ändert, kann eine ansonsten elegante Sequenz entwerten.
3. Haftreibung der Aktoren und Prozessverzögerung Pneumatikzylinder benötigen Druckaufbau. Ventile können vor der Bewegung klemmen. Pumpen erzeugen keinen stabilen Durchfluss in dem Moment, in dem ein Motor-Bit eingeschaltet wird. Das Kontaktplan-Diagramm kümmert das nicht; den Prozess schon.

Der „Sieht richtig aus“-Trugschluss

„Sieht richtig aus“ bedeutet meist „besteht eine visuelle Prüfung unter idealen Annahmen“. Das ist nicht dasselbe wie der Beweis, dass die Sequenz realistische Zeit- und Fehlerbedingungen übersteht.

Betrachten Sie ein Sortierförderband mit einem Schiebezylinder:

• Die Logik befiehlt den Stopp des Förderbands.
• Die Logik befiehlt das Ausfahren des Zylinders.
• Die Logik wartet auf die Rückmeldung „Ausgefahren“.
• Die Logik startet das Förderband nach der Produktausleitung neu.

Auf dem Papier ist das sauber. In einer simulierten Maschine läuft das Förderband möglicherweise noch aus, wenn der Zylinder in die Bahn eintritt. Wenn die Sequenz von einem sofortigen Stopp abhängt, kollidiert der Mechanismus, obwohl jeder Kontaktplan-Zweig legal und jeder Tag-Name korrekt ist. Der Compiler wird keinen Einwand erheben. Die Physik meist schon.

In diesem Artikel ist ein Digital Twin kein Branding-Synonym für 3D-Grafiken. Es ist ein Softwaremodell, das Zustände in einer deterministischen Validierungsschleife mit der Steuerungslogik austauscht.

Operativ ist ein Digital Twin zur SPS-Validierung:

> Ein kinematisches und ereignisdiskretes Softwaremodell, das SPS-Ausgänge verarbeitet, simulierte physikalische Einschränkungen wie Bewegungsverzögerung, Schwerkraft, Reibung und zustandsabhängiges Zeitverhalten anwendet und deterministische Sensor- und Prozesseingänge an die Steuerungslogik zurückgibt.

Diese Definition ist bewusst eng gefasst. Sie schließt dekorative Visualisierungen aus, die nicht am Austausch von Steuerungszuständen teilnehmen.

Ein nützlicher Digital Twin für die Steuerungstechnik muss vier Dinge tun

Beispiel: Motor-Startbefehle, Ventil-Öffnungsbefehle, Zylinder-Ausfahr-Bits, analoge Sollwerte.

• Controller-Ausgänge verarbeiten

Beispiel: Beschleunigung, Verzögerung, Verweilzeit, Fahrzeit, Druckverzögerung, Pegeländerung oder Prozessverzögerung.

• Modelliertes Geräteverhalten anwenden

Beispiel: Näherungsschalter, Lichtschranken, Endschalter, analoge Prozesswerte, Alarmzustände, Rückmeldungen.

• Simulierte Eingänge an die Logik zurückgeben

Derselbe Testfall sollte reproduzierbar genug sein, um Logikänderungen zu diagnostizieren und Revisionen zu vergleichen.

• Deterministische Testbedingungen bewahren

Das ist der Unterschied zwischen einem Video und einer Validierungsumgebung. Das eine ist illustrativ. Das andere kann schlechte Steuerungslogik abweisen.

OLLA Lab wird operativ nützlich, wenn das Kontaktplan-Programm und die simulierte Ausrüstung einen beobachtbaren Zustand teilen. Die Plattform ist nicht nur ein Kontaktplan-Editor mit einer Szene daneben; der Wert liegt in der Bindung von Logikvariablen an das Maschinenverhalten und dem anschließenden Schließen der Schleife.

In OLLA Lab erstellen Anwender Kontaktplan-Logik in einem webbasierten Editor, führen sie im Simulationsmodus aus und inspizieren oder manipulieren Variablen über das Variablen-Panel. Die Plattform unterstützt Lern-Workflows für Boolesche Werte, Analogwerte, Timer, Komparatoren, Mathematik und PID-orientierte Logik sowie 3D/WebXR-Simulationsszenarien. Innerhalb dieses Workflows können Tags mit simulierten Gerätezuständen verknüpft werden, sodass Befehls-Bits das Modell steuern und Modellereignisse Rückmeldungen in die Logik zurückgeben.

Praktischer Tag-Bindungs-Workflow in OLLA Lab

Ein typischer Validierungsaufbau sieht so aus:

• Definieren der Befehls-Tags in der Kontaktplan-Logik
• `Conveyor_Run_CMD`
• `Cylinder_Extend_CMD`
• `Reset_Fault_CMD`

• Definieren der Rückmelde- und Sensor-Tags
• `Conveyor_At_Speed`
• `Cylinder_Extended_LS`
• `Photoeye_PE1`
• `Jam_Fault`

• Binden der Befehls-Tags an Digital-Twin-Verhalten
• `Conveyor_Run_CMD` steuert den Bewegungszustand des Förderbands
• `Cylinder_Extend_CMD` steuert die Ausfahrsequenz des Aktors

• Binden der simulierten Geräterückmeldungen an Tags
• Förderbandbewegung aktualisiert `Conveyor_At_Speed`
• Virtueller Endschalter aktualisiert `Cylinder_Extended_LS`
• Virtueller Raycast oder Objekterkennung aktualisiert `Photoeye_PE1`

• Ausführen der Sequenz und Inspizieren der Zustandsübergänge
• Eingänge umschalten
• Simulation pausieren, ausführen oder stoppen
• Tag-Änderungen, Timer, Analogwerte und Fehlerzustände beobachten

Was dies dem Ingenieur bietet

• Eine sichtbare Ursache-Wirkungs-Kette zwischen Kontaktplan-Logik und Maschinenreaktion
• Einen Ort, um zu testen, ob Verriegelungen tatsächlich ausreichen
• Eine Möglichkeit, Zeitabweichungen zwischen Befehl und Rückmeldung zu untersuchen
• Eine sichere Umgebung, um Fehler zu injizieren, die an echter Ausrüstung teuer oder gefährlich wären

Hier passt OLLA Lab glaubwürdig hinein: als risikokontrollierte Übungsumgebung für Validierung und Fehlerbehebung. Es ersetzt nicht die Inbetriebnahme vor Ort, aber es ermöglicht Ingenieuren, Teile der Inbetriebnahme zu proben, die zu destruktiv, zu teuer oder zu störend sind, um sie an einer Live-Linie zu erlernen.

Die wertvollsten SITL-Tests sind keine nominalen Sequenzen. Es sind Tests für anormale Zustände. Fast jede Steuerungsstrategie sieht kompetent aus, wenn jeder Sensor funktioniert und jeder Aktor pünktlich eintrifft.

Obligatorische SITL-Testfälle

Lösen Sie einen Not-Halt aus, während eine Bewegung aktiv ist und der Mechanismus Material trägt oder schiebt. Überprüfen Sie:

• ob gefährliche Bewegungen wie beabsichtigt spannungsfrei geschaltet werden,
• ob sich der Zustandsspeicher vorhersehbar verhält,
• ob ein Neustart eine bewusste Bedienhandlung erfordert,
• ob kein versteckter automatischer Wiederanlaufpfad existiert.

Erzwingen Sie während der Bewegung einen Fehlerzustand bei einem Öffner- oder Schließer-Endschalter. Überprüfen Sie:

• ob die Fehlererkennung innerhalb des erwarteten Zeitfensters erfolgt,
• ob die Bewegung sicher gehemmt oder gestoppt wird,
• ob Alarmtexte und Fehler-Bits eindeutig sind,
• ob Rücksetzbedingungen bewusst und begrenzt sind.

Simulieren Sie den Verlust der Steuerspannung oder eine Unterbrechung der Ausführung. Überprüfen Sie:

• ob Ausgänge in sichere Standardzustände zurückkehren,
• ob die Anlauflogik keine gefährlichen Bewegungen automatisch neu startet,
• ob gespeicherte Zustände keine unmöglichen Sequenzannahmen erzeugen,
• ob eine Quittierung durch den Bediener erfolgt, wo dies angemessen ist.

Befehlen Sie eine Bewegung und halten Sie die erwartete Rückmeldung zurück. Überprüfen Sie:

• ob die Timeout-Logik auslöst,
• ob der Fehler korrekt gespeichert wird,
• ob nachgelagerte Bewegungen blockiert werden,
• ob der Wiederherstellungspfad explizit ist.

Führen Sie zeitliche Überlappungen zwischen benachbarten Maschinenzuständen ein. Überprüfen Sie:

• ob sich gegenseitig ausschließende Aktionen exklusiv bleiben,
• ob ein Zustand einen anderen nicht ohne den erforderlichen Nachweis vorwegnehmen kann,
• ob Annahmen zur Scan-Reihenfolge keinen Sequenzierungsfehler maskieren.

Injizieren Sie Prozessstörungen oder unrealistische Sensorwerte. Überprüfen Sie:

• ob Alarme bei definierten Schwellenwerten aktivieren,
• ob sich der Steuerausgang innerhalb der erwarteten Grenzen verhält,
• ob stoßfreie Umschaltungen oder Modusänderungen sauber gehandhabt werden,
• ob Abschaltungen und Freigaben bei analogen Störungen kohärent bleiben.

1. Asynchroner Not-Halt unter Last
2. Sensorausfall und Failsafe-Verifizierung
3. Wiederanlauf nach Stromausfall
4. Mechanisches Timeout und fehlende Rückmeldung
5. Sequenz-Race-Conditions
6. Analoge Auslenkung und PID-Störung

Ein praktisches Missverständnis, das korrigiert werden sollte

Nur den „Happy Path“ zu testen, ist keine Validierung. Es ist eine Demonstration. Das reale Inbetriebnahmerisiko liegt in Übergängen, Verzögerungen und Fehlern.

Ein Timeout-Muster ist eine der einfachsten defensiven Strukturen, die in SITL einen echten Mehrwert bietet. Es wandelt „der Aktor hätte sich längst bewegen müssen“ in einen beobachtbaren Fehlerzustand um.

Unten ist ein kompaktes Beispiel für ein Zylinder-Ausfahr-Timeout. Die exakte Syntax variiert je nach Plattform, aber die Steuerungsabsicht ist Standard.

Sprache: Kontaktplan (Ladder Diagram)

// Zylinder-Betätigungs-Timeout-Fehlerlogik |---[ ]-----------[/]-----------[/]-----------------(TON)---| CMD_Extend Limit_Retract Limit_Extend Fault_Delay

|---[ ]---------------------------------------------( )-----| Fault_Delay.DN Fault_Cyl_Ext_Timeout

Was dieser Zweig bewirkt

• `CMD_Extend` startet die Zeitbedingung, wenn das Ausfahren befohlen wird.
• `Limit_Retract` nicht gesetzt bedeutet, dass der Zylinder nicht mehr sicher in der Grundstellung ist, abhängig von der Gerätephilosophie.
• `Limit_Extend` nicht gesetzt bedeutet, dass die Ausfahrbestätigung noch nicht eingetroffen ist.
• `Fault_Delay` misst das erlaubte Fahrzeitfenster.
• Wenn der Timer ohne Ausfahrbestätigung abläuft, wird `Fault_Cyl_Ext_Timeout` gesetzt.

Warum SITL hier wichtig ist

In einer statischen Logikprüfung erscheint dieser Zweig unkompliziert. In einem Digital Twin können Sie testen, ob das Timeout:

• zu kurz für eine realistische Aktor-Fahrzeit ist,
• zu lang ist, um den Mechanismus zu schützen,
• durch Sequenzübergänge falsch zurückgesetzt wird,
• blind gegenüber Teilbewegungen oder Stauzuständen ist.

Das ist der Unterschied zwischen dem Schreiben eines Timeouts und dessen Validierung.

Technische Nachweise sollten die Argumentation zeigen, nicht nur die Vertrautheit mit der Benutzeroberfläche. Eine Screenshot-Galerie beweist, dass Software geöffnet wurde. Sie beweist sehr wenig anderes.

Wenn das Ziel darin besteht, ernsthafte Steuerungsarbeit zu demonstrieren, dokumentieren Sie jede simulierte Übung mit dieser Struktur:

Erforderliche Nachweisstruktur

Beispiel: „Das Förderband darf erst neu starten, wenn der Ausleitungszylinder vollständig eingefahren und die Produktpräsenz geklärt ist.“

Beispiel: „Zylinder-Ausfahrbefehl erteilt, während die Auslaufzeit des Förderbands noch 1,8 s betrug.“

Beispiel: „Förderband-Nullgeschwindigkeitsfreigabe und Ausfahr-Timeout-Fehler hinzugefügt.“

1. Systembeschreibung Definieren Sie die Maschine oder Prozesszelle, die wichtigsten Aktoren, Sensoren und das Betriebsziel.
2. Operative Definition von „korrekt“ Geben Sie an, was wahr sein muss, damit die Sequenz als korrekt angesehen wird.
3. Kontaktplan-Logik und simulierter Gerätezustand Zeigen Sie die relevanten Zweige, Tag-Definitionen und entsprechenden Digital-Twin-Zustände oder Rückmeldungen.
4. Der injizierte Fehlerfall Geben Sie genau an, was erzwungen oder gestört wurde.
5. Die vorgenommene Revision Dokumentieren Sie die Logikänderung.
6. Gelernte Lektionen Erklären Sie, welche Annahme fehlgeschlagen ist und wie die überarbeitete Logik die Sequenz absichert.

Diese Struktur ist nützlich, da sie Steuerungsabsicht, Fehlermodell und korrigierende Argumentation erfasst. Das ist das Material, das Arbeitgeber und Prüfer tatsächlich hinterfragen können. Screenshots allein sind meist dekorativ.

OLLA Lab unterstützt einen simulationsbereiten Workflow durch die Kombination von Kontaktplan-Erstellung, Simulation, Variableninspektion, Szenariokontext und Digital-Twin-Interaktion in einer webbasierten Umgebung. Der Vorteil ist nicht Bequemlichkeit um ihrer selbst willen; es ist die Reduzierung des Kontextwechsels während der Validierung.

Innerhalb der gegebenen Produktfakten bietet OLLA Lab:

• Einen webbasierten Kontaktplan-Editor mit Kontakten, Spulen, Timern, Zählern, Komparatoren, mathematischen Funktionen, Logikoperationen und PID-Anweisungen
• Simulationsmodus zum Ausführen von Logik, Umschalten von Eingängen und Beobachten von Ausgängen ohne physische Hardware
• Ein Variablen-Panel zur Überwachung von Tags, E/A, Analogwerten, PID-bezogenen Variablen und Szenariostatus
• 3D/WebXR/VR-Simulationen, die Steuerungslogik mit Geräteverhalten verbinden
• Digital-Twin-Validierungs-Workflows zum Testen von Logik gegen realistische Maschinenmodelle
• Szenariobasierte Labs für Fertigung, Wasser/Abwasser, HLK, Chemie, Pharma, Lagerhaltung, Lebensmittel und Getränke sowie Versorgungsunternehmen
• Geführte Aufbauanleitungen mit Zielen, E/A-Mapping, Steuerungsphilosophie, Verriegelungen und Verifizierungsschritten
• KI-Unterstützung durch GeniAI, positioniert als Lab-Coaching und korrigierende Unterstützung innerhalb des Lern-Workflows

Die begrenzte Behauptung

OLLA Lab kann Ingenieuren helfen, Validierungsaufgaben zu proben, die auf Live-Systemen nur schwer sicher durchzuführen sind:

• Nachverfolgung von E/A-Ursache-Wirkungs-Zusammenhängen,
• Testen von Verriegelungen,
• Beobachten von Fehlerverhalten,
• Überarbeiten von Logik nach Fehlern in anormalen Zuständen,
• Vergleichen des Kontaktplan-Zustands mit dem simulierten Gerätezustand.

Es sollte nicht als Ersatz für Felderfahrung, formale funktionale Sicherheitsarbeit oder standortspezifische Inbetriebnahmegenehmigung dargestellt werden. Ein Simulator kann schlechte Annahmen frühzeitig aufdecken. Er kann keine Anlage abnehmen.

SITL kann die Qualität der Inbetriebnahme verbessern, indem die Fehlererkennung nach vorne verlagert wird, aber es begründet für sich allein keine Sicherheitskonformität. Diese Unterscheidung ist zentral.

Was SITL unterstützen kann

• Frühere Entdeckung von Sequenzierungsfehlern
• Bessere Testabdeckung von anormalen Zuständen
• Sichereres Proben der Fehlerbehandlung
• Diszipliniertere Vorbereitung der Inbetriebnahme
• Verbesserte Kommunikation zwischen Steuerungs-, Mechanik- und Prozessteams

Was weiterhin eine separate Behandlung erfordert

• Aktivitäten im Lebenszyklus der funktionalen Sicherheit gemäß IEC 61508
• Design und Verifizierung von sicherheitsgerichteten Funktionen (SIF)
• Standortspezifische Risikobewertung
• Analyse der Hardware-Fehlertoleranz
• Typprüfung und Validierung des installierten Systems

Die Industrieliteratur zur virtuellen Inbetriebnahme und cyber-physischen Simulation unterstützt im Allgemeinen den Wert einer früheren Verhaltensvalidierung, insbesondere für sequenzlastige und mechatronische Systeme. Das wiederkehrende Ergebnis ist nicht, dass Simulation das Inbetriebnahmerisiko beseitigt. Es ist, dass Simulation einen bedeutenden Teil der Fehlererkennung in eine billigere und sicherere Phase des Projekts verlagert. Das ist eine bescheidenere Behauptung und auch die glaubwürdigere.

Beginnen Sie mit einer kompakten Sequenz, die Bewegung, Rückmeldung und einen Zweig für anormale Zustände enthält. Wenn die erste Übung zu einfach ist, lehrt sie Syntax, aber kein Urteilsvermögen.

Ein guter Einstiegsfall in OLLA Lab ist ein Förderband-mit-Ausleiter- oder Pumpen-Haupt/Reserve-Szenario mit:

• einem Befehlspfad,
• einer Rückmeldung,
• einem Timeout,
• einem Alarm,
• einer Neustartbedingung,
• einem injizierten Fehler.

Das bietet genug Struktur, um Kausalität zu testen, ohne sich in der Architektur zu verlieren. Der Punkt ist zu lernen, ob die Logik den Kontakt mit einem modellierten Prozess überlebt, nicht am ersten Tag ein großes System zu bauen.

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

Dieser Artikel wurde von Experten für industrielle Automatisierung bei Ampergon Vallis verfasst, die sich auf die Validierung von Steuerungslogik und die Implementierung von Digital-Twin-Technologien spezialisiert haben.

Die in diesem Artikel genannten methodischen Ansätze und die Analyse der 1.200 Inbetriebnahmeszenarien basieren auf internen Daten von Ampergon Vallis (Zeitraum 2025–2026). Die Definitionen von SITL und HIL orientieren sich an gängigen Standards der virtuellen Inbetriebnahme (VDI 3693).