So erstellen Sie XOR- und NAND-Logikgatter in einer SPS mit OLLA Lab

Um Boolesche Algebra in IEC 61131-3 Kontaktplan-Logik (KOP) zu übersetzen, bilden Ingenieure abstrakte Logikzustände auf scan-basiertes Kontaktverhalten und Ausgangsspulen ab. In OLLA Lab werden XOR und NAND nicht nur als Symbole gezeichnet; sie werden vor jedem Live-Einsatz gegen simulierte E/A, Fehlerzustände und Maschinenreaktionslogik validiert.

Boolesche Algebra und Kontaktplan-Logik sind verwandt, aber nicht austauschbar. Boolesche Ausdrücke sind abstrakt und auf dem Papier effektiv zeitlos; Kontaktplan-Logik wird von einer SPS in einem Scan-Zyklus mit realen Eingängen, gespeicherten Zuständen und Ausgangsaktualisierungen ausgeführt. Genau in diesem Unterschied entstehen viele Anfängerfehler.

Ein interner Benchmark von Ampergon Vallis verdeutlicht dies: 68 % der Anwender scheiterten bei ihrem ersten Diskrepanz-Alarm-Aufbau bei der Implementierung von XOR-Verhalten in OLLA Lab [Methodik: n=500 Anfänger-Logiksequenzen, Aufgabe definiert als Aufbau und Test eines Diskrepanz-Alarms mit zwei Eingängen in der Simulationsumgebung, Basis-Vergleich = Bestehen/Nichtbestehen beim ersten Versuch gegen die erwartete Wahrheitstabelle und das simulierte Verhalten, Zeitfenster = Jan-Feb 2026]. Dies stützt eine begrenzte Aussage: Die Übersetzung Boolescher Absichten in eine korrekte Kontaktplan-Struktur ist schwieriger, als die Wahrheitstabelle zu erkennen. Es stützt keine weitergehende Behauptung über die Kompetenz von Ingenieuren in der gesamten Industrie.

Die Boolesche Algebra beschreibt logische Beziehungen. Das IEC 61131-3 Kontaktplan-Diagramm (KOP) beschreibt, wie diese Beziehungen in einem scan-basierten Steuerungssystem implementiert werden.

Der praktische Unterschied ist folgender:

- SPS-Logik wird zyklisch ausgeführt: Eingänge lesen -> Logik ausführen -> Ausgänge schreiben.

• Boolesche Algebra behandelt Variablen wie A und B als abstrakte logische Zustände.
• Kontaktplan-Logik bildet diese Zustände auf Tags, Speicherbits und physische oder simulierte E/A ab.
• Boolesche Ausdrücke werden als statische Beziehungen gelesen.

Dieses Scan-Zyklus-Verhalten ist wichtig, da ein Netzwerk nicht nur eine symbolische Gleichung ist. Es wird sequenziell unter Verwendung des aktuellen Prozessabbilds der Steuerung ausgewertet.

### Grundlegende Übersetzungsmatrix: Boolesche Algebra zu Kontaktplan-Logik

Die standardmäßigen ersten Abbildungen sind unkompliziert:

• UND -> Kontakte in Reihe
• ODER -> Kontakte parallel
• NICHT -> Darstellung als Öffner-Kontakt
• TRUE-Ausgangszustand -> erregte Spule oder internes Bit
• FALSE-Ausgangszustand -> nicht erregte Spule oder gelöschtes Bit

Diese Abbildungen sind grundlegend, aber sie sind nicht die ganze Geschichte. Die Engineering-Aufgabe besteht nicht nur darin, Logik darzustellen. Es geht darum, Logik in einer Form darzustellen, die unter realistischen Prozessbedingungen beobachtbar, testbar und sicher bleibt.

Warum die physische Ebene die Bedeutung verändert

Eine Boolesche Variable ist kein Draht. In einer SPS kann ein Tag Folgendes darstellen:

• einen 24-VDC-Feldeingang,
• ein internes Speicherbit,
• einen abgeleiteten Status,
• eine Freigabe,
• eine Auslösebedingung,
• oder einen simulierten Gerätezustand.

Deshalb muss „korrekt“ operativ definiert werden. In diesem Artikel bedeutet korrekt, dass das Netzwerk für alle relevanten Eingangskombinationen das erwartete Ergebnis liefert und sich bei Tests gegen simulierte Prozesszustände und Fehlerfälle konsistent verhält.

Wo IEC 61131-3 wichtig ist

IEC 61131-3 standardisiert Programmiersprachen, einschließlich Kontaktplan (KOP), Funktionsbausteinsprache (FBS) und Strukturierter Text (ST) für speicherprogrammierbare Steuerungen (IEC, 2013). Es beseitigt nicht die Implementierungsunterschiede zwischen den Herstellern, bietet aber ein gemeinsames Ausführungsmodell und einen Sprachrahmen.

Das ist wichtig, weil Boolesche Logik universell ist, während die Kontaktplan-Implementierung immer an ein Steuerungsmodell, ein Scan-Verhalten und einen Anlagenkontext gebunden ist.

Ein NAND-Gatter wird nur dann falsch, wenn beide Eingänge wahr sind. In der Industriesteuerung macht dies das Gatter nützlich für Freigabe- und Sperrmuster, bei denen ein Ausgang verfügbar bleibt, solange nicht eine spezifische Kombination von Bedingungen gleichzeitig erfüllt ist.

Die Boolesche Form lautet:

• C = NICHT (A UND B)

Die entsprechende Interpretation im Kontaktplan:

• Ausgang C ist ein, wenn A falsch ist, oder B falsch ist, oder beide falsch sind.
• Ausgang C schaltet nur aus, wenn A und B beide wahr sind.

Warum NAND in der industriellen Logik vorkommt

In der Elektronik wird NAND oft als universelles Gatter eingeführt. In der industriellen Automatisierung ist die nützlichere Einordnung enger gefasst: Es ist eine praktische Methode, um „erlauben, außer wenn diese Bedingungen zusammenfallen“ auszudrücken.

Typische Beispiele sind:

• Freigabe-Logik,
• kombinierte Sperrbedingungen,
• Fehleraggregationsmuster,
• Sequenz-Haltebedingungen,
• Unterdrückung abnormaler Zustände.

Dies muss sorgfältig eingegrenzt werden. Eine Kontaktplan-Implementierung von NAND ist kein Ersatz für ein formales funktionales Sicherheitsdesign gemäß IEC 61508 oder eine Maschinensicherheitsvalidierung. Es ist ein Steuerungslogik-Muster, kein automatischer Sicherheitsnachweis.

Kontaktplan-Implementierung eines NAND-Gatters

Eine gängige Kontaktplan-Form mit zwei Zweigen ist:

[Sprache: Kontaktplan (KOP)] // NAND-Gatter: Ausgang ist EIN, außer wenn sowohl Eingang A als auch Eingang B EIN sind.

|----[/]----------------------------------------( )----| | Eingang A Ausgang C| | | |----[/]------------------------------------------------| | Eingang B |

Dieses Netzwerk verwendet parallele Öffner-Kontakte:

• Wenn Eingang A = 0, ist der obere Zweig wahr.
• Wenn Eingang B = 0, ist der untere Zweig wahr.
• Wenn einer der Zweige wahr ist, wird Ausgang C erregt.
• Nur wenn A = 1 und B = 1, werten beide Öffner-Kontakte als falsch aus, wodurch der Ausgang abfällt.

Wahrheitstabelle für NAND in Kontaktplan-Begriffen

| Eingang A | Eingang B | Ausgang C | |--------|--------|----------| | 0 | 0 | 1 | | 0 | 1 | 1 | | 1 | 0 | 1 | | 1 | 1 | 0 |

So erstellen Sie das NAND-Gatter in OLLA Lab

Verwenden Sie den webbasierten Kontaktplan-Editor, um einen kompakten Freigabetest mit zwei Eingängen zu erstellen:

Der wichtige Schritt ist nicht das Zeichnen des Netzwerks. Es ist der Nachweis des Verhaltens:

• beide Eingänge falsch -> Ausgang ein,
• ein Eingang wahr -> Ausgang ein,
• beide Eingänge wahr -> Ausgang aus.

1. Erstellen Sie Tags für Input_A, Input_B und Output_C.
2. Fügen Sie zwei Öffner-Kontakte in separaten parallelen Zweigen ein.
3. Weisen Sie einen Zweig Input_A und den anderen Input_B zu.
4. Platzieren Sie Output_C als angesteuerte Spule.
5. Starten Sie die Simulation.
6. Schalten Sie die Eingänge im Variablen-Panel um und überprüfen Sie die Wahrheitstabelle.

Ein realistisches Freigabebeispiel

Betrachten Sie eine vereinfachte Freigabe, bei der eine Wartungssperre verfügbar bleiben soll, es sei denn, beide Bedingungen sind erfüllt:

• A = Fernbedienungsmodus gewählt
• B = Auto-Start-Sequenz aktiv

Ein NAND-artiges Netzwerk kann einen Ausgang auf „wahr“ halten, bis beide Bedingungen gleichzeitig vorliegen. In der Praxis ist dieses Muster oft in größere Freigabenetzwerke eingebettet und wird nicht als Lehrbuch-Gatter angezeigt.

Ein XOR-Gatter wird nur dann wahr, wenn genau ein Eingang wahr ist. In der industriellen Automatisierung macht dies das Gatter nützlich für Diskrepanzerkennung, Dual-State-Verifizierung und Fehleridentifikation, bei denen zwei Signale in gewisser Weise nicht widersprüchlich sein sollten.

Die Boolesche Form lautet:

• C = (A UND NICHT B) ODER (NICHT A UND B)

In Kontaktplan-Begriffen wird XOR normalerweise als zwei parallele Zweige mit kreuzgekoppelten Schließer- und Öffner-Kontakten aufgebaut.

Warum XOR bei Maschinen- und Prozessdiagnosen wichtig ist

XOR wird wertvoll, wenn zwei Signale sich gegenseitig ausschließende Gerätezustände darstellen.

Ein klassisches Beispiel ist ein Ventil mit:

• Endschalter Offen
• Endschalter Geschlossen

Unter normalen Bedingungen sollten diese beiden Anzeigen bei einem einfachen Ventil mit zwei Positionen nicht gleichzeitig wahr sein. Abhängig von Timing und Bewegungszustand sollten sie auch nicht dauerhaft beide falsch bleiben. Die genaue Alarmphilosophie hängt vom Gerät und dem Sequenzdesign ab, aber Diskrepanzlogik wird oft um XOR oder dessen Komplement herum aufgebaut.

Kontaktplan-Implementierung eines XOR-Gatters

[Sprache: Kontaktplan (KOP)] // XOR-Gatter: Ausgang ist EIN, wenn A oder B EIN ist, aber nicht beide.

|----[ ]--------[/]----------------------------( )----| | Eingang A Eingang B Alarm C | | | |----[/]--------[ ]------------------------------------| | Eingang A Eingang B |

Dieses Netzwerk funktioniert wie folgt:

• Oberer Zweig ist wahr, wenn A = 1 und B = 0
• Unterer Zweig ist wahr, wenn A = 0 und B = 1
• Wenn einer der Zweige wahr ist, wird Alarm C erregt
• Wenn beide Eingänge gleich sind, bleibt der Alarm aus

Wahrheitstabelle für XOR in Kontaktplan-Begriffen

| Eingang A | Eingang B | Alarm C | |--------|--------|---------| | 0 | 0 | 0 | | 0 | 1 | 1 | | 1 | 0 | 1 | | 1 | 1 | 0 |

Wie XOR Diskrepanz-Alarme unterstützt

Für einen Diskrepanz-Alarm ist XOR nützlich, wenn die Alarmbedingung als „die beiden Zustandssignale widersprechen sich“ definiert ist.

Beispiele sind:

• Widerspruch der Offen/Geschlossen-Anzeige,
• Redundanz-Sensor-Fehlanpassung,
• Diskrepanz zwischen befohlenem Zustand und Rückmeldung,
• Widerspruch bei Wahlschaltern,
• gepaarte Statusbits, die sich gegenseitig ausschließen sollten.

Dies muss dennoch kontextbezogen entwickelt werden. Ein Ventil während der Bewegung kann legitimerweise einen vorübergehenden Widerspruch oder einen vorübergehenden Verlust beider Endzustandsbestätigungen erzeugen. Gute Alarmlogik fügt normalerweise Timing, Sequenzzustand oder Bewegungskontext hinzu. Rohes XOR ist ein nützlicher Kern, nicht die fertige Philosophie.

So erstellen Sie das XOR-Gatter in OLLA Lab

Verwenden Sie OLLA Lab, um das Diskrepanz-Netzwerk direkt im Browser zu konstruieren und zu testen:

Die Testsequenz sollte bestätigen:

• 00 -> Alarm aus
• 01 -> Alarm ein
• 10 -> Alarm ein
• 11 -> Alarm aus

Wenn das Netzwerk etwas anderes tut, liegt das Problem meist an einer von drei Ursachen:

• Kontakttyp vertauscht,
• Zweigstruktur inkorrekt,
• Tag-Bedeutung schlecht definiert.

1. Erstellen Sie Tags für Input_A, Input_B und Alarm_C.
2. Fügen Sie zwei parallele Zweige hinzu.
3. Platzieren Sie im ersten Zweig Schließer Input_A in Reihe mit Öffner Input_B.
4. Platzieren Sie im zweiten Zweig Öffner Input_A in Reihe mit Schließer Input_B.
5. Steuern Sie Alarm_C mit dem Zweigausgang an.
6. Führen Sie die Simulation aus und schalten Sie die beiden Eingänge durch alle vier Zustände.

Der SPS-Scan-Zyklus macht Kontaktplan-Logik zeitlich, nicht nur logisch. Eingänge werden gelesen, Logik wird gelöst und Ausgänge werden sequenziell geschrieben, was bedeutet, dass das Verhalten davon abhängt, wann Zustandsänderungen beobachtet werden.

Bei einfachen Beispielen mit zwei Eingängen mag der Scan-Zyklus unsichtbar erscheinen. Bei echten Geräten ist er das nicht.

Die Standard-Scan-Sequenz

Die meisten SPS-Ausführungen folgen diesem groben Muster:

1. Eingänge lesen
2. Programmlogik ausführen
3. Ausgänge aktualisieren
4. Kommunikation, Diagnose, Housekeeping durchführen

Die genauen Details variieren je nach Plattform, Aufgabenmodell und Hersteller, aber das Prinzip ist stabil.

Warum das für Diskrepanzlogik wichtig ist

Ein XOR-Diskrepanz-Alarm kann sich unterschiedlich verhalten, abhängig von:

• Timing der Eingangsaktualisierung,
• Entprellung,
• Sequenzzustand,
• Flankenauswertung,
• Verwendung von Timern,
• asynchroner Gerätebewegung.

Zum Beispiel:

• ein Ventil kann während der Bewegung beide Endschalter als falsch melden,
• ein Schalter kann prellen,
• eine Rückmeldung kann der anderen um mehrere Scans hinterherhinken,
• ein simulierter oder erzwungener Eingang kann sich sauber ändern, während ein echtes Gerät dies nicht tut.

Deshalb ist scan-bewusste Validierung wichtig. Boolesche Algebra setzt idealisierte Zustandsbeziehungen voraus. Geräte führen oft Verzögerungen, Prellen und Mehrdeutigkeiten ein.

Warum das für Freigaben wichtig ist

Eine NAND-artige Freigabe kann einen Ausgang nur dann abfallen lassen, wenn beide Bedingungen im selben ausgewerteten Zustand wahr werden. Wenn eine Bedingung gespeichert, verzögert oder durch ein anderes Netzwerk abgeleitet wird, kann das beobachtete Verhalten von der einfachen Wahrheitstabelle abweichen, sofern die umgebende Logik nicht verstanden wird.

OLLA Lab simuliert das Verhalten von Logikgattern, indem es Benutzern ermöglicht, Kontaktplan-Netzwerke zu erstellen, sie in einer kontrollierten Umgebung auszuführen, Eingänge umzuschalten, Variablenzustände zu prüfen und die Ergebnisse des Kontaktplans mit dem simulierten Geräteverhalten zu vergleichen.

Das macht es zu einer begrenzten Validierungsumgebung für risikoreiche Lernaufgaben, nicht zu einem Ersatz für die Abnahmeprüfung vor Ort oder eine formale Sicherheitsvalidierung.

Was „Simulationsbereit“ hier bedeutet

In diesem Artikel bedeutet Simulationsbereit, dass ein Ingenieur:

• erwartetes Logikverhalten gegen definierte Testzustände beweisen kann,
• E/A-Kausalität in der Simulation beobachten kann,
• inkorrektes Netzwerkverhalten diagnostizieren kann,
• abnormale Bedingungen injizieren kann,
• die Logik überarbeiten kann,
• und das überarbeitete Verhalten verifizieren kann, bevor er echte Geräte berührt.

So testen Sie einen NAND-Fehlerfall in OLLA Lab

Verwenden Sie das Variablen-Panel, um die Eingangskombinationen durchzugehen:

• Setzen Sie Input_A = 0, Input_B = 0 -> bestätigen Sie Output_C = 1
• Setzen Sie Input_A = 1, Input_B = 0 -> bestätigen Sie Output_C = 1
• Setzen Sie Input_A = 0, Input_B = 1 -> bestätigen Sie Output_C = 1
• Setzen Sie Input_A = 1, Input_B = 1 -> bestätigen Sie Output_C = 0

Injizieren Sie dann ein Fehlerszenario:

• definieren Sie einen Eingang konzeptionell als „stuck-high“ Freigabequelle,
• beobachten Sie, ob der Ausgang noch aus der Netzwerkstruktur erklärt werden kann,
• überarbeiten Sie die Logik oder Tag-Definition, wenn das Verhalten nicht mehr der beabsichtigten Steuerungsphilosophie entspricht.

So testen Sie einen XOR-Diskrepanz-Fehler in OLLA Lab

Für ein Diskrepanz-Alarm-Modell:

- Simulieren Sie dann einen Fehlerfall wie:

• Schalten Sie Input_A und Input_B durch alle vier Zustände der Wahrheitstabelle.
• Bestätigen Sie, dass Widerspruchszustände Alarm_C erregen.
• ein Endschalter klemmt ein,
• beide Schalter werden auf „wahr“ erzwungen,
• beide Schalter sind länger als erwartet „falsch“,
• Befehlszustand inkonsistent mit Rückmeldezustand.

Das Variablen-Panel ist hier nützlich, da es den Zustand direkt offenlegt.

Warum das über das Erlernen der Syntax hinaus wichtig ist

Simulation schließt die Lücke zwischen Netzwerkkonstruktion und Verhaltensnachweis. Forschung zu digitalen Zwillingen, simulationsbasiertem Training und cyber-physischer Validierung weist auf den Wert virtueller Tests zur Risikoreduzierung, Verbesserung des Systemverständnisses und Unterstützung der früheren Fehlerentdeckung in Automatisierungs-Workflows hin (Tao et al., 2019; Fuller et al., 2020; Villalonga et al., 2021).

Das bedeutet nicht, dass ein Simulator ein Design zertifiziert. Es bedeutet, dass ein Simulator Ingenieuren einen sichereren Ort bietet, um offensichtliche Fehler zu finden, bevor die Anlage es tut.

Ein guter Workflow definiert Korrektheit, bevor die Tests beginnen. Wenn „korrekt“ vage bleibt, wird die Simulation zum Theater.

Verwenden Sie diese kompakte Nachweisstruktur bei der Dokumentation eines Logikgatter-Aufbaus oder einer Überprüfung:

Definieren Sie das Gerät oder die Steuerungsfunktion. Beispiel: „Zwei-Positionen-Ventil mit Offen- und Geschlossen-Rückmeldung für Diskrepanz-Alarmierung.“

Geben Sie das erwartete Verhalten in beobachtbaren Begriffen an. Beispiel: „Alarm erregt, wenn genau eine Rückmeldung wahr ist; Alarm bleibt aus, wenn beide gleich sind, vorbehaltlich separat dokumentierter Timing-Ausnahmen.“

Definieren Sie den abnormalen Zustand. Beispiel: „Geschlossen-Endschalter klemmt während des befohlenen Öffnungsvorgangs auf ‚wahr‘.“

Zeigen Sie, was sich geändert hat. Beispiel: „Übergangs-Timer und Befehlszustands-Qualifizierer hinzugefügt, um Fehlalarme während der normalen Bewegung zu unterdrücken.“

Geben Sie an, was der Test ergeben hat. Beispiel: „Rohes XOR erkannte den Widerspruch korrekt, löste aber während legitimer Zustandsübergänge zu viele Alarme aus.“

1. Systembeschreibung
2. Operative Definition von „korrekt“
3. Kontaktplan-Logik und simulierter Gerätezustand Fügen Sie das tatsächliche Netzwerk und die entsprechenden simulierten Tag-Zustände oder Gerätezustände bei.
4. Der injizierte Fehlerfall
5. Die vorgenommene Überarbeitung
6. Gelernte Lektionen

Der häufigste Fehler ist die Annahme, dass die Wahrheitstabelle das Design sei. Das ist sie nicht. Die Wahrheitstabelle ist nur die anfängliche Einschränkung.

Häufige Implementierungsfehler

• Vertauschen von Schließer- und Öffner-Kontakten
• Verwechslung von Signalbedeutung mit Signalzustand
• Ignorieren von Scan-Zyklus-Effekten
• Testen nur des erwarteten Falls
• Behandlung von Freigabelogik als äquivalent zu Sicherheitslogik
• Versäumnis, das Prozesszustandsmodell zu definieren

Eine praktische Korrektur

Definieren Sie bei jedem gatterbasierten Netzwerk drei Dinge, bevor Sie simulieren:

• was jedes Tag physisch oder logisch darstellt,
• welches Ausgangsverhalten als korrekt angesehen wird,
• welche abnormalen Zustände toleriert werden müssen versus welche alarmiert werden müssen.

Diese Disziplin beseitigt eine überraschende Menge an Verwirrung. Viele „Logik-Bugs“ sind in Wirklichkeit Spezifikations-Bugs.

Verwenden Sie OLLA Lab, wenn die Engineering-Aufgabe das Einüben von Logikverhalten, E/A-Kausalität, Fehlerinjektion oder Sequenzvalidierung erfordert, ohne echte Geräte unnötigen Risiken auszusetzen.

Dazu gehören:

• Kontaktplan-Übungen für Anfänger bis Fortgeschrittene,
• Einüben von Diskrepanz-Alarmen,
• Testen von Freigabelogik,
• Szenarienarbeit für Ventil- und Motorsteuerung,
• Überprüfung der Interaktion zwischen analog und diskret,
• instruktorgeführte Laborübungen,
• Logik-Walkthroughs vor der Inbetriebnahme in einer begrenzten Umgebung.

Basierend auf der Produktdokumentation unterstützt OLLA Lab dies durch:

• einen browserbasierten Kontaktplan-Editor,
• Simulationsmodus,
• Sichtbarkeit von Variablen und E/A,
• szenariobasierte industrielle Voreinstellungen,
• Validierungs-Workflows für digitale Zwillinge,
• Zugang zur 3D/WebXR/VR-Simulation, sofern aktiviert,
• geführte Aufbauanleitungen,
• KI-Labor-Coaching durch GeniAI.

Die begrenzte Aussage ist einfach: OLLA Lab bietet Ingenieuren eine praktische Umgebung, um Kontaktplan-Logik gegen simuliertes Verhalten aufzubauen und zu testen. Es ersetzt nicht die Inbetriebnahme der Anlage, Standortverfahren, Herstellerhandbücher oder Verpflichtungen aus dem funktionalen Sicherheitslebenszyklus.

Die Boolesche Algebra liefert Ihnen die logische Form. Die IEC 61131-3 Kontaktplan-Logik liefert Ihnen die ausführbare Struktur. Die Engineering-Herausforderung ist die Übersetzung zwischen beiden, insbesondere sobald Scan-Timing, Geräteverhalten und Fehlerzustände ins Spiel kommen.

NAND und XOR sind nützliche Beispiele, weil sie diese Übersetzung sauber offenlegen:

• NAND drückt Freigabelogik aus, die nur abfällt, wenn Bedingungen zusammenfallen.
• XOR drückt Widerspruchslogik aus, die Zustands-Fehlanpassungen identifiziert.

In beiden Fällen ist das Netzwerk nur der Anfang. Die eigentliche Arbeit besteht darin, das Verhalten unter normalen und abnormalen Bedingungen zu beweisen. Genau dort zahlt sich eine Simulationsumgebung aus.

Weiterführende Literatur

- Siehe Der Wandel zum Systemdenken: Über das Zeichnen von Netzwerken hinaus.

• Für einen breiteren Kontext zu Standards besuchen Sie unseren Ladder Logic Mastery Hub.
• Siehe Warum „Öffner“-Kontakte die wichtigsten Netzwerke sind, die Sie schreiben werden.
• Bereit, diese Diskrepanzlogik zu testen? Öffnen Sie das Ventilsteuerungs-Preset in OLLA Lab.

- IEC 61131-3: Programmierbare Steuerungen — Teil 3 - IEC 61508 Familie funktionaler Sicherheitsstandards - exida Ressourcen für funktionale Sicherheit und Validierung - NAMUR NE 107 Empfehlung zur Statussignalisierung - Digitaler Zwilling in der Industrie: Stand der Technik (DOI)