Vom einfachen SPS-Code zum systemorientierten Engineering für die Inbetriebnahme

Systemorientiertes Denken in der Automatisierung bedeutet, SPS-Logik anhand von physikalischem Verhalten, anomalen Zuständen und sicheren Wiederanlaufpfaden über die Zeit zu validieren. Der Schritt über das bloße „Zeichnen von Rungs“ hinaus gelingt, wenn Ingenieure I/O-Kausalitäten beobachten, Zustandsübergänge modellieren, Fehler injizieren und die Steuerungslogik härten, bevor sie auf einen realen Prozess trifft.

Ein weit verbreiteter Irrtum ist, dass gute Kontaktplan-Logik (Ladder Logic) primär eine Frage der korrekten Syntax sei. Das ist nicht der Fall. Die korrekte Syntax beweist lediglich, dass die SPS Anweisungen ausführen kann; sie beweist nicht, dass die Maschine sicher und deterministisch agiert oder sauber wieder anläuft, wenn die Realität unvorhersehbar wird.

Ein begrenzter interner Benchmark von Ampergon Vallis stützt diese Unterscheidung. In einer Analyse von 2.500 simulierten Inbetriebnahmeschritten innerhalb von OLLA Lab identifizierten und korrigierten Anwender, die mit szenariobasierten digitalen Zwillingen arbeiteten, 40 % mehr Race-Conditions und Zustandsdivergenz-Fehler vor der finalen Einreichung als Anwender, die auf das bloße Umschalten diskreter I/Os beschränkt waren [Methodik: n=2.500 simulierte Aufgaben in Szenario-Labs mit Sequenzvalidierung, Fehlerbehandlung und Rückmeldebestätigung; Basisvergleich = Browser-basiertes Ladder-Testing mit Standard-I/O-Umschaltung; Zeitfenster = interne Beobachtungen von Ampergon Vallis, Jan-Feb 2026]. Dies unterstreicht den Wert fehlerbewusster Simulation für die Validierung von Logik vor der Bereitstellung. Es stützt keine Aussagen über Arbeitsplatzvermittlung, Zertifizierungen oder Feldkompetenz an sich.

Der Übergangspunkt ist einfach zu formulieren, aber schwer zu praktizieren: Das Zeichnen von Rungs erfüllt die boolesche Struktur; systemorientiertes Denken verwaltet physikalische Zustände, mechanische Latenzzeiten und Prozesssicherheit über die Zeit. Hier beginnt die Inbetriebnahme, und hier treffen saubere Logikdiagramme auf unsaubere Anlagen.

Der Unterschied liegt im Umfang. Das Schreiben von SPS-Logik beantwortet die Frage, ob eine Befehlssequenz syntaktisch gültig und intern kohärent ist. Systemorientiertes Denken beantwortet die Frage, ob diese Logik auch dann korrekt bleibt, wenn sie mit Sensoren, Aktoren, Verriegelungen, Zeitunsicherheiten und anomalen Prozessbedingungen verbunden ist.

Praktisch ausgedrückt: Die Ladder-Syntax befasst sich mit der Ausführung. Systemorientiertes Denken befasst sich mit dem Verhalten. Die eine Seite fragt, ob der Rung schaltet; die andere fragt, ob die Anlage überhaupt hätte zulassen sollen, dass dieser Rung schaltet, was den Erfolg bestätigt und was passiert, wenn diese Bestätigung ausbleibt.

Die IEC 61131-3 ist hier relevant, da sie nicht nur Programmiersprachen definiert, sondern auch eine disziplinierte Softwarestruktur für industrielle Steuerungsanwendungen unterstützt, einschließlich Modularität, wiederverwendbarer Funktionsbausteine und zustandsorientierter Entwurfsmuster, wenn der Prozess dies erfordert (IEC, 2013). Flache Logik kann laufen. Strukturierte Logik kann durchdacht werden. Das sind nicht dieselben Errungenschaften.

Die Syntax- vs. System-Matrix

| Fokus Syntax | Fokus System | |---|---| | Zieht die Spule an, wenn der Kontakt schließt? | Was passiert, wenn der Kontakt 50 ms prellt, bevor er stabil ist? | | Läuft der Timer wie geschrieben ab? | Ist der Timer lang genug für den tatsächlichen Aktorweg und kurz genug, um Fehler zu erkennen? | | Ist der PID-Baustein frei von Konfigurationsfehlern? | Können Ventil, Antrieb oder Prozess innerhalb der angenommenen Regelbandbreite reagieren? | | Ist die Sequenz beendet? | Was ist der sichere Wiederanlaufpfad, wenn während Schritt 3 ein Not-Halt oder eine Störung auftritt? | | Hält der Motorstartbefehl (Latching)? | Kam die Rückmeldung (Run Proof) an, und welche Fehlerlogik greift, wenn nicht? | | Wertet die Analogvergleichs-Anweisung korrekt aus? | Ist das Signal verrauscht, driftend, korrekt skaliert und durch Alarm-/Grenzwertschwellen begrenzt? |

Eine nützliche operative Definition ergibt sich aus dieser Tabelle: Systemorientiertes Denken in der Automatisierung ist die Disziplin, Steuerungslogik basierend auf beobachtetem Anlagenzustand, Prozesstiming und Fehlerreaktion zu entwerfen, zu validieren und zu überarbeiten – anstatt sich nur auf das Erscheinungsbild der Rungs zu verlassen.

Diese Unterscheidung klingt offensichtlich, bis der Tag der Inbetriebnahme kommt. Dann wird sie teuer.

Mechanisches und instrumentierungstechnisches Verhalten entwertet routinemäßig Logik, die im Editor korrekt aussieht. Die SPS arbeitet deterministisch; der Prozess tut dies selten.

Drei physikalische Variablen verursachen bei der Steuerungskonzeption im Frühstadium unverhältnismäßig große Probleme:

1. Aktor-Latenz

Ventile, Dämpfer, Schütze und Antriebe benötigen Zeit, um sich zu bewegen, einzupendeln oder ihre Position zu bestätigen. Wenn die Logik eine sofortige Reaktion annimmt, schreiten Sequenzen zu früh voran und die Fehlerbehandlung greift zu spät.

Typische Konsequenzen sind:

• Schrittübergänge, bevor ein Ventil tatsächlich offen ist,
• Timeouts bei der Motorstartbestätigung, die zu kurz oder zu lang sind,
• Verriegelungen, die sich am Befehlszustand statt am bewiesenen Zustand orientieren,
• Störabschaltungen durch Schwankungen in der Laufzeit.

Logik auf Inbetriebnahme-Niveau nutzt daher:

• Positions- oder Laufzeitrückmeldungen (Proof-of-position/run),
• Wartezustände,
• Übergangstimer,
• Timeout-Alarme,
• explizite Fehlerzweige, wenn die erwartete Bewegung ausbleibt.

Ein Befehl ist keine Bestätigung. Anlagen sind in diesem Punkt sehr streng.

2. Sensorprellen und Signalrauschen

Diskrete Geräte liefern nicht immer saubere boolesche Flanken, und analoge Signale kommen nicht als ruhige, idealisierte Werte an. Mechanische Schalter prellen. Schwimmerschalter flattern. Druck- und Füllstandssignale driften oder oszillieren. Rauschen ist kein Softwarefehler, aber die Software macht oft einen daraus.

Robuste Logik beinhaltet typischerweise:

• Entprell-Timer für diskrete Übergänge,
• Totzonen und Filterung, wo angebracht,
• Alarmverzögerungen,
• Komparatorschwellen mit Hysterese,
• Validierungsregeln für analoge Werte außerhalb des Bereichs.

Dies ist ein Grund, warum „es hat in der Simulation funktioniert“ eine schwache Aussage sein kann, es sei denn, die Simulation beinhaltet verrauschtes oder verzögertes Verhalten. Ein perfektes Signal ist lehrreich; ein unperfektes Signal ist nützlich.

3. Zustandsdivergenz

Zustandsdivergenz tritt auf, wenn SPS-Speicher und physikalische Ausrüstung nicht mehr übereinstimmen. Die Logik glaubt, ein Motor läuft, weil das Befehlsbit gesetzt ist; die Hilfsrückmeldung sagt, er sei gestört. Die Sequenz glaubt, ein Tank füllt sich; der Füllstand bleibt gleich, weil das Einlassventil klemmt.

Dies ist kein Randfall. Es ist normale Inbetriebnahmearbeit.

Systemorientierte Logik muss daher vergleichen:

• befohlener Zustand,
• beobachteter Zustand,
• erwartete Übergangszeit,
• Fehlerkonsequenz.

Dieser Vergleich ist die Basis für:

• Rückmeldefehler-Alarme,
• Sequenz-Haltepunkte,
• sichere Abschaltpfade,
• Bedienermeldungen,
• Neustartbedingungen.

Die Validierung durch digitale Zwillinge ist gerade deshalb nützlich, weil sie Zustandsdivergenz beobachtbar macht, bevor Hardware gefährdet ist.

Zustandsbasierte Architektur ist entscheidend, weil sich reale Prozesse über die Zeit entfalten, nicht in isolierten booleschen Schnappschüssen. Wenn eine Sequenz Phasen, Freigaben, Übergänge und Fehlerzweige hat, ist ein explizites Zustandsmodell einfacher zu validieren als ein Geflecht aus Selbsthaltungen und Umgehungen.

Das zugrunde liegende Prinzip ist einfach: Jede Prozessphase sollte eine definierte Eintrittsbedingung, ein aktives Verhalten, eine Austrittsbedingung, eine Timeout-Logik und eine Reaktion auf anomale Zustände haben. Das ist der Unterschied zwischen einer Sequenz, die erklärt werden kann, und einer, die nur aus Gewohnheit überlebt.

In IEC 61131-3-Umgebungen erscheint dies oft als:

• enumerierte oder kodierte Zustände,
• Übergangsbedingungen,
• gekapselte Funktionsbausteine oder Module,
• klare Trennung zwischen Befehlslogik, Rückmeldelogik und Alarmlogik.

Warum Finite-State-Logik „Spaghetti“-Sequenzierung übertrifft

Zustandsbasiertes Design verbessert die Inbetriebnahme, da es vier Dinge explizit macht:

- Aktuelle Prozessphase: Was die Maschine gerade tun soll. - Übergangsbedingung: Was wahr sein muss, bevor die nächste Phase beginnt. - Fehlerbedingung: Was in dieser Phase ein anomalem Verhalten darstellt. - Wiederanlaufpfad: Was das System nach einem Stopp, einer Störung oder einem Bedienereingriff tut.

Im Gegensatz dazu verbergen stark verschachtelte Rung-Sets oft die Absicht der Sequenz über mehrere Netzwerke hinweg. Sie mögen laufen, sind aber schwer systematisch zu testen und nach einer Unterbrechung schwer sicher wieder anzufahren. Die Maschine deckt die Mehrdeutigkeit schließlich auf.

Beispiel für explizite Übergangslogik

Vereinfachtes Zustandsübergangsbeispiel:

IF (CurrentState = FILLING) AND Level_High AND NOT Valve_Fault THEN NextState := MIXING; Mix_Timer_Enable := TRUE; END_IF;

IF (CurrentState = FILLING) AND Fill_Timeout THEN NextState := FAULT_HOLD; Alarm_FillFailed := TRUE; END_IF;

Das wichtige Merkmal ist nicht die Syntax. Es ist die Architektur. Die Logik definiert, wie Erfolg aussieht, wie Fehler aussieht und wohin der Prozess in beiden Fällen als Nächstes geht.

Das ist Denken auf Inbetriebnahme-Niveau. Es ist zudem freundlicher gegenüber dem nächsten Ingenieur.

Simulation-Ready bedeutet nicht „vertraut mit SPS-Software“ oder „in der Lage, gängige Rung-Muster aus dem Gedächtnis zu zeichnen“. Es bedeutet, dass ein Ingenieur Steuerungslogik gegen realistisches Prozessverhalten beweisen, beobachten, diagnostizieren und härten kann, bevor diese Logik ein reales System erreicht.

Diese Definition ist operativ, nicht aspirational. Ein Simulation-Ready-Ingenieur kann:

• Logik gegen ein Prozessmodell laufen lassen statt nur gegen die Syntax,
• Live-I/O und interne Tags überwachen, während die Sequenz ausgeführt wird,
• den befohlenen Zustand mit dem simulierten Anlagenzustand vergleichen,
• gezielt anomale Bedingungen injizieren,
• erkennen, wo Logikannahmen scheitern,
• das Programm überarbeiten und denselben Fehlerpfad erneut testen.

Hier hört Simulation auf, ein Lehrzubehör zu sein, und wird zu einer Risikokontrollmethode. Reale Anlagen sind schlechte Orte, um zu entdecken, dass der Wiederanlaufpfad nie zu Ende gedacht wurde.

OLLA Lab ist am besten als risikofreie Simulationsumgebung zu verstehen, um Validierungsaufgaben zu üben, die an realer Ausrüstung teuer, störend oder unsicher wären. Sein Wert liegt nicht darin, dass es Ladder-Logik in einem Browser zeichnet. Sein Wert liegt darin, dass es Logik, Variablen, simuliertes Anlagenverhalten und Fehlerinjektion in einem Workflow verbindet.

Der Ladder-Logik-Editor bietet die Programmieroberfläche, einschließlich Kontakten, Spulen, Timern, Zählern, Komparatoren, mathematischen Funktionen, Logikoperationen und PID-Anweisungen. Für sich genommen unterstützt dies das Syntax-Training. Der Engineering-Wert steigt, wenn diese Logik im Simulationsmodus ausgeführt und über das Variablenpanel, Analog-Tools, PID-Dashboards und szenariospezifische I/O-Mappings beobachtet wird.

### Operativ unterstützt OLLA Lab die Validierung im Inbetriebnahme-Stil, indem es Anwendern ermöglicht:

• Logik ohne physische Hardware zu starten und zu stoppen,
• diskrete I/O in Echtzeit umzuschalten und zu überwachen,
• Tag-Zustände und Variablenänderungen zu inspizieren,
• mit analogen Werten und PID-bezogenem Verhalten zu arbeiten,
• den Ladder-Zustand mit 3D- oder WebXR-Anlagenverhalten zu vergleichen,
• Logik gegen szenariospezifische digitale Zwillinge zu validieren,
• realistische industrielle Sequenzen und Verriegelungen zu proben.

Die Produktdokumentation positioniert diese Fähigkeiten über Szenarien in der Fertigung, Wasser- und Abwasserwirtschaft, HLK, Chemie, Pharma, Lagerhaltung, Lebensmittel und Getränke sowie Versorgungsunternehmen hinweg. Das ist wichtig, weil die Steuerungsphilosophie kontextabhängig ist. Ein Problem bei der Pumpenumschaltung, eine Freigabesequenz für ein Lüftungsgerät und der Anlauf eines Prozess-Skids scheitern nicht auf die gleiche Weise.

Was „Validierung durch digitale Zwillinge“ hier bedeutet

In diesem Artikel bedeutet die Validierung durch digitale Zwillinge zu beobachten, ob die Steuerungslogik das beabsichtigte Verhalten an einem realistischen virtuellen Anlagenmodell erzeugt, einschließlich erwarteter Übergänge, Rückmeldebestätigung, analoger Reaktion und Behandlung anomaler Zustände.

Diese Definition ist bewusst eng gefasst. Sie impliziert keine formale Anlagenabnahme, SIL-Qualifizierung oder Konformität durch Assoziation. Sie bedeutet, dass die Logik gegen modelliertes Verhalten getestet werden kann, bevor Entscheidungen zur Bereitstellung getroffen werden.

Beispiele für Gefahren, die Ingenieure in OLLA Lab proben können

Basierend auf den dokumentierten Plattformfunktionen und der Szenariostruktur können Anwender Fälle proben wie:

• ein Motorbefehl, der ohne gültige Laufmeldung ausgegeben wird,
• ein Ventil, das die Position nicht innerhalb der erwarteten Zeit erreicht,
• eine analoge Prozessvariable, die über die Alarmschwelle driftet,
• eine Haupt-/Reserve-Pumpensequenz mit fehlender Rückmeldung,
• eine Unterbrechung der Schrittsequenz während eines Zwischenzustands,
• PID-bezogene Instabilität oder schlechte Schwellenwertbehandlung,
• Verriegelungsfehler und Not-Halt-Kettenreaktionen innerhalb eines Szenarios.

Hier wird OLLA Lab operativ nützlich. Es ermöglicht Junior-Ingenieuren, Zustandsdivergenz sicher herbeizuführen und dann die Logik zu schreiben, die sie erkennt und verwaltet.

Ingenieure sollten einen kompakten Bestand an Validierungsnachweisen aufbauen, keine Galerie von Screenshots. Ein Screenshot zeigt, dass ein Bildschirm existierte. Engineering-Nachweise zeigen, was getestet wurde, was fehlschlug, was sich änderte und warum die Überarbeitung sicherer oder zuverlässiger ist.

Verwenden Sie diese Struktur für jedes Szenario oder Projekt:

1) Systembeschreibung

Geben Sie an, was der Prozess ist, was die Ausrüstung tut und was das Steuerungsziel ist.

Beispiel:

• Hebestation mit zwei Pumpen, Haupt-/Reserve-Umschaltung, Hochwasser-Alarm und Failover bei Pumpenstörung.

2) Operative Definition von „korrekt“

Definieren Sie beobachtbare Erfolgskriterien.

Beispiel:

• Hauptpumpe startet bei Füllstandsschwelle,
• Reservepumpe startet nur, wenn der Füllstand weiter steigt,
• Hochwasser-Alarm aktiviert sich oberhalb des Sollwerts,
• gestörte Pumpe wird von der Auswahl ausgeschlossen,
• Sequenz kehrt nach Reset und Füllstandserholung zum Normalbetrieb zurück.

3) Ladder-Logik und simulierter Anlagenzustand

Zeigen Sie sowohl die Steuerungslogik als auch das entsprechende simulierte Maschinen- oder Prozessverhalten.

Beinhaltet:

• Zusammenfassung der Rung- oder Zustandslogik,
• I/O-Map,
• Rückmelde-Tags,
• Timer-Werte,
• analoge Schwellenwerte,
• relevante Anlagenzustände in der Simulation.

4) Der injizierte Fehlerfall

Erzeugen Sie bewusst eine anomale Bedingung.

Beispiele:

• Pumpenlaufbefehl ohne Laufmeldung,
• klemmender Füllstandsschalter (High),
• verrauschter Low-Level-Eingang,
• Drift des Analogmessumformers,
• Not-Halt während eines aktiven Transferschritts.

5) Die vorgenommene Überarbeitung

Dokumentieren Sie die Designänderung nach Beobachtung des Fehlers.

Beispiele:

• Laufzeit-Timeout hinzugefügt,
• Entprell-Timer eingefügt,
• Befehlszustand vom bewiesenen Zustand getrennt,
• Fehler-Haltezustand hinzugefügt,
• Reset-Freigaben überarbeitet.

6) Gelernte Lektionen

Geben Sie an, was der Fehler über die ursprünglichen Annahmen enthüllte.

Beispiel:

• ursprüngliche Logik nahm an, Befehl impliziere Bewegung,
• Reset-Pfad war bei teilweisem Sequenzabschluss unsicher,
• Alarmverzögerung war zu kurz für die tatsächliche Prozessreaktion,
• analoger Schwellenwert benötigte Hysterese, um Oszillation zu verhindern.

Dieses Format erzeugt Nachweise für technisches Urteilsvermögen. Es ist für einen Prüfer auch weitaus überzeugender als eine polierte, aber kontextlose Projektdatei.

Der Wechsel von syntaxfokussierter Programmierung zu validierungsfokussiertem Engineering wird sowohl durch Standards als auch durch die breitere Literatur zur Steuerungstechnik unterstützt.

Standards und technische Grundlagen

- Die exida-Leitlinien und die Praxis der funktionalen Sicherheit betonen wiederholt Nachweise, Diagnosen, Fehlerreaktionen und Lebenszyklus-Strenge bei sicherheitsrelevanter Automatisierungsarbeit. Die allgemeine Lektion überträgt sich sauber: Annahmen müssen gegen Verhalten getestet werden, nicht nur dokumentiert.

• IEC 61131-3 definiert die Programmiersprachen und strukturellen Prinzipien, die in industrieller Steuerungssoftware verwendet werden, einschließlich modularer und wiederverwendbarer Programmorganisation, die für zustandsorientiertes Design geeignet ist (IEC, 2013).
• IEC 61508 rahmt funktionale Sicherheit um systematische Fähigkeiten, Lebenszyklusdisziplin, Verifizierung und Validierung. Auch wenn eine Trainingsumgebung keine formale Sicherheitszertifizierung durchführt, ist der Standard eine nützliche Erinnerung daran, dass Softwarekorrektheit nicht allein durch Syntax begründet wird (IEC, 2010).

Literaturthemen, die für diesen Artikel relevant sind

Aktuelle Literatur zu industrieller Simulation, digitalen Zwillingen und immersivem Engineering-Training stützt im Allgemeinen drei begrenzte Schlussfolgerungen:

• Simulation verbessert die Beobachtung von Ursache und Wirkung im Frühstadium, wenn sie an realistisches Prozessverhalten gekoppelt ist;
• Methoden digitaler Zwillinge sind nützlich für die virtuelle Inbetriebnahme, Sequenzvalidierung und Fehleranalyse;
• Immersive oder interaktive Umgebungen können das Engagement und das prozedurale Verständnis verbessern, ersetzen jedoch nicht die standortspezifische Kompetenz, formale Sicherheitsüberprüfungen oder die beaufsichtigte Inbetriebnahme.

Diese letzte Unterscheidung ist wichtig. Simulation ist ein Proberaum, kein Ersatz für die Verantwortung in der Anlage.

Der praktische Weg besteht darin, zu ändern, was „fertig“ bedeutet. Ein Rung ist nicht fertig, wenn er kompiliert. Er ist fertig, wenn seine Erfolgsbedingungen, Fehlerbedingungen und sein Wiederanlaufverhalten gegen ein glaubwürdiges Prozessmodell getestet wurden.

Ein disziplinierter Fortschritt sieht so aus:

### Schritt 1: Beginnen Sie mit einem begrenzten Prozess

Wählen Sie ein kompaktes Szenario mit klarem Anlagenverhalten:

• Motorstarter mit Laufmeldung,
• Tankfüllung und -entleerung,
• Förderbandzonentransfer,
• Haupt-/Reserve-Pumpen,
• grundlegende HLK-Freigabesequenz.

### Schritt 2: Definieren Sie die Prozesszustände

Schreiben Sie die tatsächlichen Zustände auf:

• Leerlauf (Idle),
• Freigabeprüfung,
• Startbefehl,
• Laufprüfung (Proving Run),
• aktiver Betrieb,
• Stopp,
• Fehler-Haltezustand,
• Reset.

Wenn die Zustände vage sind, wird die Inbetriebnahme aus den falschen Gründen lebhaft.

### Schritt 3: Mappen Sie Befehl, Rückmeldung und Fehler separat

Fassen Sie sie nicht in einer Bit-Ebene-Geschichte zusammen.

Verfolgen Sie:

• was die SPS befiehlt,
• was die Anlage beweist,
• welcher Timer oder Komparator Fehler definiert,
• welcher Alarm- oder Haltezustand folgt.

### Schritt 4: Injizieren Sie eine realistische anomale Bedingung

Testen Sie nicht nur den „Happy Path“.

Verwenden Sie:

• verzögerte Rückmeldung,
• ausgebliebene Bewegung,
• verrauschter Eingang,
• analoge Drift,
• unterbrochene Sequenz.

### Schritt 5: Überarbeiten und erneut testen

Dokumentieren Sie die Logikänderung und beweisen Sie das überarbeitete Verhalten.

Diese Schleife ist das Herz des systemorientierten Denkens:

• Annahme,
• Beobachtung,
• Diskrepanz,
• Überarbeitung,
• Validierung.

OLLA Lab passt in diese Schleife als Probenumgebung. Es gibt Anwendern einen Ort, um die Sequenz auszuführen, Variablen zu inspizieren, simuliertes Anlagenverhalten zu beobachten und Überarbeitungen zu testen, ohne Fehler an reale Maschinen zu binden.

Der Schritt über das „Zeichnen von Rungs“ hinaus ist keine Einstellungsänderung. Es ist eine Änderung der Validierungsdisziplin. Ingenieure bewegen sich in Richtung Arbeit auf Inbetriebnahme-Niveau, wenn sie aufhören, Ladder-Logik als in sich geschlossenes Diagramm zu behandeln, und anfangen, sie als Steuerungshypothese zu betrachten, die Timing, Rückmeldung, Rauschen und fehlerhaftes Anlagenverhalten überstehen muss.

Systemorientiertes Denken in der Automatisierung lässt sich daher einfach formulieren: Es ist die Praxis, Logik um physikalischen Zustand, Übergangsbedingungen, anomales Verhalten und sicheren Wiederanlauf herum zu entwerfen, anstatt nur um die Syntax.

Deshalb ist Simulation wichtig. Nicht, weil sie modisch ist, sondern weil sie es Ingenieuren ermöglicht, Ursache und Wirkung zu beobachten, bevor ein realer Prozess Lehrgeld fordert.

- IEC 61131-3: Programmable controllers — Part 3 - IEC 61508 functional safety standards family - exida functional safety and validation resources - NAMUR NE 107 status signaling recommendation - Digital twin in industry: state-of-the-art (DOI)