Programmierung der analogen Driftkompensation in einer SPS für alternde Sensoren

Die analoge Driftkompensation in einer SPS bedeutet das Erkennen und Verwalten schleichender Sensorfehler, die innerhalb des normalen 4–20-mA-Bereichs verbleiben. In der Praxis kombinieren Ingenieure Filterung, Plausibilitätsprüfungen der Änderungsrate, Offset-Logik und Wartungsalarme und validieren diese Verhaltensweisen in einer Simulation, bevor sie auf einen laufenden Prozess angewendet werden.

Analoge Drift ist oft gefährlicher als ein harter analoger Fehler, da sie elektrisch gültig bleiben kann, während sie physikalisch falsch ist. Ein Leitungsbruch macht sich meist bemerkbar; ein driftender Messumformer hingegen oft nicht.

Während der internen Validierung im beschleunigten analogen Abweichungsszenario von OLLA Lab zeigte eine unkompensierte Steuerungslogik in einem simulierten Füllstandregelkreis eine Abweichung von bis zu 4,2 % zwischen dem abgeleiteten Prozesswert und dem simulierten physikalischen Zustand, bevor eine standardmäßige Bereichsüberschreitungs-Alarmbedingung vorlag [Methodik: n=12 Simulationsläufe bei einer Tankfüllstandsregelung, Basis-Vergleicher = nominales driftfreies Signalmodell mit identischer Logik, Zeitfenster = beschleunigter 24-Stunden-Abweichungszyklus, durchgeführt während der internen Laborvalidierung im März 2026]. Dies stützt die eng gefasste Aussage, dass Drift innerhalb des Messbereichs zu materiell irreführendem Regelverhalten führen kann, bevor konventionelle Fehlerlogik für Unter- oder Überbereich reagiert. Dies stützt keine allgemeine Aussage über alle Anlagen, alle Sensoren oder alle Steuerungsarchitekturen.

Bei der Programmierung gegen Drift geht es nicht darum, vorzugeben, dass Software beschädigte Hardware reparieren kann. Es geht darum, die diagnostische Sichtbarkeit zu erweitern und die Regelungsqualität so lange zu erhalten, bis eine geordnete Erkennung, Kompensation, Alarmierung und Wartung erfolgen kann.

Analoge Drift ist gefährlicher, weil sie einen Fehler innerhalb des Messbereichs erzeugt. Das Signal bleibt innerhalb des erwarteten elektrischen Bandes, sodass die SPS es als plausibel akzeptiert, sofern keine zusätzliche Logik etwas anderes besagt.

Ein harter Fehler ist leichter zu erkennen. In einer konventionellen 4–20-mA-Schleife führt ein Leitungsbruch, ein Kurzschluss oder ein grober Ausfall des Messumformers oft dazu, dass das Signal den normalen Messbereich verlässt. Genau deshalb gibt es normbasierte Fehlersignalisierungskonventionen.

NAMUR NE 43 erkennt viele harte Fehler, aber nicht schleichenden Wahrheitsverlust

NAMUR NE 43 definiert standardisierte Fehlerstrombereiche für analoge Instrumentierung, damit Empfangssysteme zwischen Prozessmessung und Gerätefehlerverhalten unterscheiden können. In der gängigen Praxis gilt:

• < 3,6 mA deutet oft auf einen Unterbereich oder Fehler hin
• > 21,0 mA deutet oft auf einen Überbereich oder Fehler hin
• 4,0 bis 20,0 mA werden als gültiges Betriebsband behandelt

Dies funktioniert gut bei Leitungsbrüchen und offensichtlichen Messumformerausfällen. Es löst jedoch keine Drift, die innerhalb von 4–20 mA bleibt, während die physikalische Messung langsam von der Realität abweicht.

| Signalzustand | SPS-Sicht | Typische Reaktion der Basis-Fehlerlogik | Tatsächliches Risiko | |---|---|---|---| | 0 mA oder nahe Null | Ungültiges Signal | Löst Unterbereichsfehler aus | Meist offensichtlich und schnell behoben | | < 3,6 mA | Fehlerbereich | Alarm / Fail-Safe-Aktion | Durch Standard-Fehlerlogik erkennbar | | > 21,0 mA | Fehlerbereich | Alarm / Fail-Safe-Aktion | Durch Standard-Fehlerlogik erkennbar | | 4–20 mA mit schleichendem Bias | Gültiges Signal | Kein Fehler durch einfache Bereichsprüfung | Regler agiert auf Basis falscher Prozesswerte |

Das betriebliche Problem ist einfach: Ein PID-Regler kann nicht zwischen „genau, aber unpraktisch“ und „plausibel, aber falsch“ unterscheiden, es sei denn, man gibt ihm mehr Kontext.

Was verursacht analoge Drift in realen Anlagen?

Analoge Drift entsteht meist durch langsame physikalische Degradation, nicht durch plötzlichen elektrischen Zusammenbruch.

Häufige Ursachen sind:

- Sensorverschmutzung: Ablagerungen, Schlamm, Beschichtungen oder Biofilme auf Sonden - Thermische Alterung: Degradation von Thermoelementen, Drift von Messumformerkomponenten - Mechanische Ermüdung: Verschleiß der Membran bei Druckmessgeräten - Referenzinstabilität: Alterung von pH- und Leitfähigkeitssensoren - Umweltbelastung: Vibration, Feuchtigkeitseintritt, Temperaturwechsel - Installationseffekte: Probleme mit Impulsleitungen, Montagespannungen, schlechte Schirmung, Erdungsprobleme

Der wichtige Unterschied liegt zwischen Fehler und Degradation. Harte Fehler unterbrechen die Messkette. Drift degradiert sie, während die Kette scheinbar intakt bleibt.

Programmierung für das 10. Jahr bedeutet, Steuerungslogik für ein Instrument so zu schreiben, wie es sich nach Betriebseinflüssen, Verschmutzung, Vibration und Wartungshistorie verhalten wird – nicht nur so, wie es am Tag der Inbetriebnahme funktioniert.

Für diesen Artikel bedeutet Programmierung gegen Drift die Implementierung von Softwarestrukturen, die schleichende Messfehler beobachtbarer und betrieblich weniger schädlich machen. In ingenieurtechnischen Begriffen umfasst dies:

• Software-Kalibrierungs-Offset-Logik für bekannte Null- oder Referenzzustände
• Plausibilitätsprüfungen der Änderungsrate gegenüber physikalischen Prozessgrenzen
• Filterung zur Unterdrückung von Rauschen, ohne reale Prozessbewegungen zu verdecken
• Abweichungsalarme zwischen redundanten oder abgeleiteten Messungen
• Wartungs-Flags, die anzeigen, dass die Kompensation akzeptable Grenzen überschreitet

Dies ist auch der Punkt, an dem Ampergon Vallis’ Verwendung von Simulation-Ready eine präzise Definition benötigt. Ein Simulation-Ready-Ingenieur ist nicht jemand, der lediglich Ladder-Syntax aus dem Gedächtnis schreiben kann. Ein Simulation-Ready-Ingenieur kann Steuerungslogik vor Erreichen eines realen Prozesses beweisen, beobachten, diagnostizieren und gegen realistisches Prozessverhalten absichern.

Keine Softwarestrategie behebt degradierte Instrumentierung vollständig. Sie kann jedoch den Regelungsfehler reduzieren, die Fehlersichtbarkeit verbessern und ein saubereres Wartungsfenster schaffen.

1. Auto-Zero- oder Tara-Offset-Logik

Die Auto-Zero-Logik erfasst den Sensor-Bias während eines bekannten physikalischen Referenzzustands und speichert diesen Bias als Offset, der zur Korrektur des Messwerts verwendet wird.

Dies ist nur angemessen, wenn der Prozess einen vertretbaren Referenzzustand aufweist, wie zum Beispiel:

• ein leerer Tank mit verifiziert niedrigem Füllstand
• eine entlüftete Druckleitung bei atmosphärischer Referenz
• eine Waage bei bestätigter Null-Last
• ein gestoppter Durchflussweg mit bestätigtem Null-Durchfluss-Zustand

Eine ordnungsgemäße Auto-Zero-Routine erfordert strikte Freigabebedingungen. Wenn der Referenzzustand nicht real ist, wird die Korrektur zu einem formalisierten Fehler.

2. Plausibilitätsprüfung der Änderungsrate

Die Änderungsraten-Logik (Rate-of-Change, RoC) weist Werte zurück oder alarmiert, wenn sie sich schneller bewegen, als der Prozess sich physikalisch ändern kann.

Beispiele:

• ein großer Tankfüllstand sollte nicht in einem Zyklus um 8 % springen
• ein thermischer Prozess sollte nicht ohne entsprechende Energiezufuhr in wenigen Sekunden um 20 °C steigen
• ein Drucksignal sollte nicht schneller oszillieren, als es das mechanische System zulässt, es sei denn, es liegen Rauschen oder Instrumentierungsprobleme vor

Die RoC-Logik korrigiert die Drift nicht direkt, hilft aber dabei, langsame, glaubwürdige Änderungen von unplausiblem Signalverhalten zu unterscheiden und kann verhindern, dass schlechte Daten Regelungsentscheidungen beeinflussen.

3. Filterung

Filterung glättet Rauschen und kurzfristige Störungen, sodass der Regler auf das Prozessverhalten reagiert und nicht auf elektrisches Flattern.

Gängige Softwareoptionen sind:

• Gleitende Mittelwertfilter
• PT1-Filter (Verzögerungsfilter erster Ordnung)
• Gewichtete Glättung
• Totband-Behandlung für kleine Schwankungen

Filterung ist nützlich, aber auch leicht falsch anzuwenden. Ein zu aggressiver Filter verdeckt die Prozesswahrheit und verzögert die Fehlererkennung.

4. Redundanter Sensorvergleich

Redundante Sensorlogik vergleicht zwei Messungen derselben oder einer verwandten Prozessvariablen und alarmiert, wenn die Abweichung einen definierten Schwellenwert überschreitet.

Typische Muster sind:

• Direkter Vergleich von Sensor A und Sensor B
• Messumformerwert versus abgeleiteter Wert aus Massenbilanz oder Gerätezustand
• Prozessvariable versus erwarteter Zustand während bekannter Sequenzschritte

Dies ist oft robuster als eine eigenständige Offset-Logik, da es ein Diskrepanzsignal erzeugt.

5. Kompensationsgrenze und Wartungsalarm

Die Kompensation sollte immer eine Obergrenze haben. Wenn der erforderliche Offset kontinuierlich steigt, sollte die Logik das Instrument nicht mehr als gesund betrachten und einen Wartungsalarm ausgeben.

Nützliche Alarmbedingungen sind:

• Offset-Größe überschreitet technischen Schwellenwert
• Offset ändert sich zu häufig
• Abweichung zwischen redundanten Sensoren hält über Zeit-Schwellenwert hinaus an
• Gefilterte und Rohwerte driften über das erwartete Rausch-Enveloppe hinaus auseinander

Eine Kompensationsroutine ohne Wartungsgrenze ist keine vollständige Resilienzstrategie.

Eine Auto-Zero-Routine sollte nur ausgeführt werden, wenn sich der Prozess in einem verifizierten Referenzzustand befindet.

Erforderliche Freigaben vor der Erfassung eines Null-Offsets

Typische Freigaben könnten sein:

• Pumpe_Aus = TRUE
• Ventil_Offen = TRUE oder bekannter Entlüftungs-/Ablasszustand
• Füllstand_Niedrig = TRUE oder eine andere unabhängige Bestätigung des leeren Zustands
• Kein aktiver Alarm, der die Kalibrierung verhindert
• Bediener- oder Sequenzfreigabe vorhanden
• Kalibrierung läuft noch nicht

Die unabhängige Bestätigung ist entscheidend. Die Verwendung des driftenden Sensors zur Bestätigung seines eigenen Nullpunkts kann die falsche Antwort automatisieren.

Beispiel-Kontaktplanstruktur

Rung 1: Pumpe_Aus Ventil_Offen Füllstand_Niedrig Null_Anforderung ----] [---------] [-------------] [--------------] [----------------(Freigabe_Null_Routine)

Rung 2: Freigabe_Null_Routine Flankenimpuls ----] [------------------] [----------------------------------------(Erfasse_Null)

Rung 3: Erfasse_Null ----] [------------------[SUB Roh_Eingang Null_Referenz_Counts Sensor_Offset_Wert]

Rung 4: Immer_An ----] [------------------[SUB Roh_Eingang Sensor_Offset_Wert Kalibrierter_PV]

Rung 5: ABS(Sensor_Offset_Wert) > Offset_Limit ---------------------------------------------------------------(Drift_Wartungs_Alarm)

Was die einzelnen Rungs tun

• Rung 1 legt die Freigaben für ein gültiges Null-Ereignis fest.
• Rung 2 verwendet einen Flankenimpuls, damit der Offset nur einmal erfasst wird, nicht in jedem Zyklus.
• Rung 3 berechnet den Offset zwischen Roh-Eingang und bekannter Referenz.
• Rung 4 wendet den gespeicherten Offset an, um eine kalibrierte Prozessvariable zu erzeugen.
• Rung 5 alarmiert, wenn der Offset über eine akzeptable Wartungsschwelle hinaus wächst.

Die exakte Arithmetik hängt von der Skalierungskonvention ab. Manche Systeme erfassen Rohwerte, andere technische Einheiten. Beides kann funktionieren, wenn die Referenz klar und der Konvertierungspfad kontrolliert ist.

Was kann bei der Auto-Zero-Logik schiefgehen?

Auto-Zero-Routinen scheitern, wenn die Freigaben schwach sind oder wenn der Prozesszustand angenommen statt verifiziert wird.

Häufige Fehlermodi sind:

• Erfassung des Nullpunkts, während sich noch Restprodukt im Behälter befindet
• Anwendung von Offsets nach der Wartung ohne Zurücksetzen der Validierungsprüfungen
• Bediener lösen die Kalibrierung vom HMI aus, ohne physikalische Bestätigung
• Verbergen chronischer Instrumentendegradation hinter einer ständig wachsenden Kompensation
• Korrektur des angezeigten PV, während Alarm- und Regelungsberechnungen auf dem Rohsignalpfad verbleiben

Änderungsraten-Grenzwerte und Filterung erfüllen unterschiedliche Aufgaben. Sie werden oft zusammen diskutiert, da beide in der Signalkonditionierungsschicht liegen, sind aber nicht austauschbar.

Filterung reduziert Rauschen

Filterung glättet kurzzeitige Variationen, sodass die Logik einen stabileren Prozesswert sieht.

Verwenden Sie Filterung, wenn:

• das Rohsignal elektrisches Rauschen enthält
• der Prozess im Verhältnis zur Zykluszeit natürlich langsam ist
• kleine Schwankungen störende Alarme oder instabiles Regelverhalten erzeugen

Vermeiden Sie Überfilterung, wenn:

• der Prozess schnell ist
• die Reaktionszeit für die Sicherheit wichtig ist
• Bediener tatsächliche Transienten sehen müssen
• die Erkennung abnormaler Zustände von einer schnellen Änderungserkennung abhängt

Änderungsraten-Prüfungen erzwingen physikalische Plausibilität

Die RoC-Logik fragt, ob sich das Signal auf eine Weise bewegt, die der Prozess tatsächlich unterstützen kann.

Verwenden Sie RoC-Prüfungen, wenn:

• Prozessdynamiken bekannt sind
• große, sofortige Sprünge physikalisch unmöglich sind
• ein schlechtes Signal eine schädliche Regelungsaktion auslösen könnte
• Sie bei unplausiblen Bewegungen alarmieren, den Wert einfrieren oder ersetzen möchten

Ein praktisches Muster ist:

1. Roh-Analogwert lesen
2. leichte Filterung anwenden
3. aktuellen Wert mit dem vorherigen Wert über die Zeit vergleichen
4. RoC berechnen
5. alarmieren oder Wert halten, wenn RoC den physikalischen Schwellenwert überschreitet
6. den validierten Wert in die Steuerungslogik einspeisen

Diese Sequenz ist meist vertretbarer, als einen starken Filter vor den PID zu setzen und auf das Beste zu hoffen.

Das Testen von Drift-Logik an realer Ausrüstung ist langsam, invasiv und oft betrieblich nicht zu rechtfertigen. Hier wird Simulation nützlich.

In OLLA Lab ist der relevante Wert nicht, dass die Umgebung digital ist. Der Wert liegt darin, dass Sie die Steuerungslogik an einem sich ändernden Prozessmodell beobachten, eine begrenzte Fehlerbedingung injizieren und das E/A-Verhalten inspizieren können, ohne die Produktionsausrüstung zu berühren.

Was OLLA Lab hier in begrenzten Begriffen tut

Für diesen Anwendungsfall fungiert OLLA Lab als webbasierter Kontaktplan- und Digital-Twin-Simulator, in dem ein Ingenieur:

• Kontaktplan-Logik im Browser erstellen oder bearbeiten kann
• Simulation ohne physikalische Hardware ausführen kann
• Variablen und E/A-Zustände überwachen kann
• Logikverhalten mit dem simulierten Gerätezustand vergleichen kann
• szenariobasierte Abweichungen anwenden kann, um Fehlerbehandlung und Kompensationslogik zu testen

Dies ist eine Validierungs- und Übungsumgebung. Sie ist kein Ersatz für die Abnahmeprüfung der Anlage, Feldkalibrierung oder formale funktionale Sicherheitsverifizierung.

Ein praktischer Drift-Validierungs-Workflow in OLLA Lab

Ein typischer Workflow ist:

1. Basis-Steuerungslogik im Kontaktplan-Editor erstellen Beinhaltet Roh-Eingangsskalierung, kalibrierten PV, Alarme und jede PID- oder Sequenznutzung des Signals.
2. Simulationsmodus öffnen Starten Sie das Prozessmodell und verifizieren Sie das nominale Verhalten ohne Drift.
3. Variablen-Panel verwenden Beobachten Sie Roh-Eingang, korrigierten PV, Offset-Wert, Alarm-Bits und alle zugehörigen Prozesszustände.
4. Analoges Driftszenario auswählen oder konfigurieren Wenden Sie über eine beschleunigte Zeitachse einen langsamen mathematischen Bias auf den analogen Roh-Eingang an.
5. Roh-PV mit dem simulierten physikalischen Zustand vergleichen Dies ist der entscheidende Test. Es geht nicht darum, ob der Rung kompiliert; es geht darum, ob die Logik den Prozess noch repräsentiert.
6. Kompensationsverhalten validieren Bestätigen Sie, ob Offset-Logik, Filterung, RoC-Prüfungen und Wartungsalarme wie beabsichtigt funktionieren.
7. Überarbeiten und erneut ausführen Ändern Sie Schwellenwerte, Freigaben oder Kompensationsgrenzen und wiederholen Sie das Szenario.

Hier ist die Zeitkompression wichtig. Ein 24-Stunden-Degradationsmuster kann in Minuten ausgewertet werden, anstatt eine Schicht oder einen Produktionstag zu beanspruchen.

Die richtige Frage ist nicht „lief die Logik“. Die richtige Frage ist „was blieb nicht wahr, als das Signal degradierte“.

Beobachten Sie diese Variablen zusammen, nicht isoliert

Bei der Validierung der Driftkompensation überwachen Sie:

• Analoger Roh-Eingang
• Skalierter technischer Rohwert
• Korrigierter oder kompensierter PV
• Simulierter physikalischer Gerätezustand
• Offset-Größe
• RoC-Wert
• Alarm- und Wartungs-Bits
• PID-Ausgang oder Sequenzentscheidungen unter Verwendung des PV

Der Vergleich zwischen simuliertem physikalischem Zustand und reglerseitig sichtbarem PV ist besonders wichtig.

Definieren Sie „korrekt“, bevor Sie den Test starten

Ein Ingenieur sollte Korrektheit in beobachtbaren Begriffen definieren, wie zum Beispiel:

• kompensierter PV bleibt innerhalb einer angegebenen Toleranz des simulierten physikalischen Zustands
• Drift-Alarm aktiviert sich, nachdem Schwellenwert- und Zeitbedingungen erfüllt sind
• Offset-Routine führt nur aus, wenn Freigaben wahr sind
• PID-Ausgang windet sich nicht auf oder jagt falsche Fehler über definierte Grenzen hinaus
• Wartungsalarm aktiviert sich, bevor die Kompensation die technische Richtlinie überschreitet

Ohne eine betriebliche Definition von „korrekt“ ist die Simulation schwer rigoros auszuwerten.

Eine Screenshot-Galerie ist für sich genommen kein starker Ingenieursnachweis.

Wenn Sie echte Fähigkeiten demonstrieren wollen – intern, gegenüber einem leitenden Ingenieur oder im Einstellungsprozess – dokumentieren Sie einen kompakten Beweis unter Verwendung dieser Struktur:

Geben Sie die Akzeptanzkriterien in messbaren Begriffen an: Toleranz, Alarmschwelle, zulässiger Offset, Reaktionszeit oder Sequenzverhalten.

Beschreiben Sie die exakte Drift oder Abweichung: Größe, Richtung, Rate, Dauer und ob sie innerhalb des Bereichs blieb.

Dokumentieren Sie, was sich in der Logik geändert hat: Offset-Erfassung, Filterkonstante, RoC-Schwellenwert, Wartungsalarm, Sensorvergleich oder Freigabestruktur.

1. Systembeschreibung Definieren Sie den Prozess, Instrumententyp, Signalbereich, Regelungsziel und relevante Betriebszustände.
2. Betriebliche Definition von „korrekt“
3. Kontaktplan-Logik und simulierter Gerätezustand Zeigen Sie die Rung-Logik und das entsprechende simulierte Maschinen- oder Prozessverhalten unter nominalen Bedingungen.
4. Der injizierte Fehlerfall
5. Die vorgenommene Überarbeitung
6. Gelernte Lektionen Erklären Sie, was das ursprüngliche Design übersehen hat, was die überarbeitete Logik verbessert hat und was noch Wartung oder Feldverifizierung erfordert.

Dieses Format hilft dabei, Urteilsvermögen zu demonstrieren, nicht nur Software-Vertrautheit.

Die zugrunde liegenden Ingenieursideen sind gut etabliert, gehören aber zu unterschiedlichen Bereichen und sollten nicht vermischt werden.

Relevante Standards und technische Rahmenbedingungen

Definiert standardisierte Fehlersignalpegel für analoge Stromschnittstellen. Nützlich zur Unterscheidung von harten Fehlern vom Messverhalten innerhalb des gültigen Bereichs.

• NAMUR NE 43

Bietet den breiteren Rahmen für funktionale Sicherheit für elektrische, elektronische und programmierbare elektronische sicherheitsbezogene Systeme. Dies ist relevant für die Philosophie der Fehlerbehandlung, bedeutet aber nicht, dass jede Driftkompensationsroutine eine Sicherheitsfunktion ist.

• IEC 61508

Branchenleitlinien zu Kalibrierung, Signalkonditionierung, Alarmmanagement und Sensorwartung informieren darüber, wie Kompensation begrenzt werden sollte.

• ISA und Praxis der Prozessinstrumentierung

Forschung im Bereich industrieller Ausbildung und modellbasierter Validierung unterstützt den Einsatz von Simulation für Proben, Fehlerinjektion und Vorbereitung der Inbetriebnahme, insbesondere dort, wo Live-Tests kostspielig oder riskant sind.

• Digital Twin und Simulationsliteratur

Eine notwendige Grenze für Sicherheitsaussagen

Driftkompensationslogik kann die Regelungsqualität und diagnostische Sichtbarkeit verbessern. Das macht sie nicht automatisch zu einer zertifizierten Sicherheitsfunktion, einem SIL-bewerteten Mechanismus oder einem Ersatz für Instrumentenwartung, Prüfungen oder unabhängige Schutzschichten.

OLLA Lab ist das richtige Werkzeug, wenn die Aufgabe darin besteht, drift-bewusste Logik gegen einen simulierten Prozess zu proben und zu validieren, bevor ein reales System dieser Logik ausgesetzt wird.

In begrenzten Produktbegriffen unterstützt OLLA Lab diese Arbeit, indem es Ingenieuren ermöglicht:

• Kontaktplan-Logik in einem browserbasierten Editor zu erstellen
• Simulationen ohne Hardware auszuführen
• Variablen, Tags und E/A-Verhalten zu inspizieren
• realistische industrielle Szenarien durchzuarbeiten
• Steuerungslogik mit dem Verhalten eines digitalen Zwillings zu vergleichen
• schnell an Logik für abnormale Zustände und Inbetriebnahmeprüfungen zu iterieren

Das macht es nützlich für Aufgaben, die Arbeitgeber unerfahrenen Ingenieuren nicht kostengünstig an einem laufenden Prozess übertragen können: Logik validieren, Ursache und Wirkung nachverfolgen, mit abnormalen Bedingungen umgehen und Logik nach einem Fehler überarbeiten.

Es sollte nicht als Abkürzung für Standortkompetenz, Zertifizierung oder formale Compliance positioniert werden. Die Inbetriebnahme vor Ort umfasst immer noch den Zustand der Instrumentierung, die Installationsqualität, Prozesswissen und menschliches Urteilsvermögen unter Bedingungen, die kein Simulator vollständig reproduziert.

Analoge Driftkompensation ist ein Problem der Regelungsqualität und Diagnostik, nicht nur eine Programmierübung. Der gefährliche Fall ist nicht der tote Messumformer, den jeder bemerkt. Es ist der alternde Messumformer, der innerhalb von 4–20 mA bleibt, während er den Regler leise vom realen Prozess wegbewegt.

Die praktische Antwort besteht darin, begrenzte Softwaremaßnahmen – Offset-Logik, Filterung, RoC-Plausibilitätsprüfungen, Sensorvergleich und Wartungsalarme – mit disziplinierter Validierung zu kombinieren. Simulation ist wertvoll, weil sie Zeit komprimiert und Verhalten offenlegt. Sie lässt Ingenieure testen, wie Logik auf langsame Degradation reagiert, bevor die Anlage den Preis dafür zahlt.

Wenn das Ziel darin besteht, Simulation-Ready zu sein, ist der Standard klar: Beweisen Sie, dass die Logik unter realistischen Fehlerbedingungen beobachtbar, diagnostizierbar und vertretbar bleibt, bevor sie reale Ausrüstung erreicht.

- IEC 61508 Functional Safety overview - exida Functional Safety and Automation resources - Åström & Hägglund, *Advanced PID Control* (ISA) - Skogestad (2003), PID tuning rules00062-8) - Tao et al. (2019), Digital Twin in Industry