Value and Valid

Artikel#: 00124

Datum: 2026-09-04

Autor: Radim

Jede Variable in einer SPS (Speicherprogrammierbare Steuerung) hat einen Wert. Das bedeutet aber noch lange nicht, dass dieser Wert eine gültige Information enthält. Nehmen wir ein einfaches Beispiel:
Temperature.Value = 23.5
Temperature.Valid = TRUE
Wir wissen, dass die Temperatur 23,5 °C beträgt, und gleichzeitig wissen wir, dass wir dieser Information vertrauen können.

Und was bedeutet Folgendes?
Temperature.Value = 23.5
Temperature.Valid = FALSE
Die Zahl ist immer noch vorhanden. Sie sieht sogar vollkommen realistisch aus. Es kann der letzte Wert vor einem Kommunikationsausfall sein, der letzte Wert vor dem Trennen des Sensors oder einfach ein alter Wert, der im Speicher der SPS geblieben ist. Und genau ein solcher Wert kann gefährlich sein. Gefährlich ist nicht unbedingt der Wert, der auf den ersten Blick falsch aussieht. Viel gefährlicher kann ein Wert sein, der vollkommen plausibel aussieht, aber nicht gültig ist.

Eine häufige Lösung beim Verlust einer Information besteht darin, den Wert auf Null zu setzen. Aber Null bedeutet nicht "invalid". Null ist ein Wert.
Speed = 0 kann dann bedeuten, dass die Maschine steht. Aber es könnte auch bedeuten, dass wir die Geschwindigkeit nicht kennen. Das sind zwei völlig unterschiedliche Informationen.
Das gleiche Problem entsteht auch bei anderen speziellen Werten wie -1, 9999 oder anderen Zahlen, die im Programm "unknown" oder "invalid" bedeuten sollen.

Ein Wert sollte nicht gleichzeitig zwei verschiedene Fragen beantworten müssen: Wie lautet der Wert? Kann ich diesem Wert vertrauen? Deshalb bevorzuge ich das Paar: Value, Valid

Dieses Prinzip ist direkt nach dem Start einer SPS nützlich. Eine Variable hat immer einen Wert. Das bedeutet nicht, dass dieser Wert eine gültige Information enthält.
Temperature.Value = 0.0
Temperature.Valid = FALSE
Die SPS hat die Variable initialisiert, also hat die Variable Temperature einen Wert. Der Sensor hat aber noch keine erste Messung geliefert. Null bedeutet in diesem Fall nicht 0 °C. Es bedeutet lediglich, dass die Variable mit Null initialisiert wurde. Die tatsächliche Temperatur kennen wir noch nicht. Nach der ersten erfolgreichen Messung können wir beispielsweise Folgendes erhalten:
Temperature.Value = 23.5
Temperature.Valid = TRUE
Die gleiche Situation kann bei Werten aus einem Bus Device, I/O Node, HMI oder einer anderen Quelle auftreten, deren Initialisierung länger dauert als der Start der SPS selbst.

Ein ähnliches Prinzip verwende ich auch bei remanenten oder persistenten Variablen. Nehmen wir an, wir haben einen Wert, der einen Neustart der SPS überstehen soll:
ProducedParts.Value = 12450
ProducedParts.Valid = TRUE
Wenn jedoch die remanenten Daten aus irgendeinem unerwünschten Grund verloren gehen oder zurückgesetzt werden, können wir nach der Initialisierung Folgendes erhalten:
ProducedParts.Value = 0
ProducedParts.Valid = FALSE
Ohne das Valid-Flag würden wir nur die Null sehen. Und wie erkennen wir, ob das bedeutet, dass 0 Teile produziert wurden, oder ob wir nicht wissen, wie viele Teile produziert wurden, weil die ursprüngliche Information verloren gegangen ist?

Es reicht aber nicht, jedem Wert einfach ein Boolean-Flag hinzuzufügen. Wir müssen auch klar definieren, wann es gesetzt und zurückgesetzt werden soll. Wenn wir beispielsweise einen Sensor trennen, kann im Speicher der SPS weiterhin Folgendes stehen:
Temperature.Value = 23.5
Der Wert hat sich nicht geändert. Das Valid-Flag müssen wir in diesem Fall aber zurücksetzen.
Temperature.Valid := FALSE

Das Valid-Flag sollte also immer einen Grund haben, warum es TRUE ist, und ebenso klar definierte Bedingungen, unter denen es wieder auf FALSE gesetzt werden muss.

Und dieses Prinzip gilt nicht nur für Werte, die von Sensoren kommen. Nehmen wir eine einfache Berechnung:
Power.Value := Voltage.Value * Current.Value;
Wenn aber Folgendes gilt:
Voltage.Valid = TRUE
Current.Valid = FALSE
können wir zwar mathematisch eine Zahl berechnen, aber wir können nicht automatisch davon ausgehen, dass das Ergebnis gültig ist. Zum Beispiel:
Power.Valid := Voltage.Valid AND Current.Valid;

Natürlich lässt sich nicht jeder Algorithmus auf ein logisches AND reduzieren. Es hängt davon ab, welche Eingänge für das jeweilige Ergebnis tatsächlich benötigt werden.

Die Gültigkeit ist Teil der Daten und sollte zusammen mit den Daten weitergegeben werden. Vom Sensor über die SPS, die Kommunikation und die Berechnungen bis hin zum SCADA-System, zur Datenbank und zur Visualisierung. Wenn wir Valid irgendwo auf diesem Weg verwerfen und nur noch Value weitergeben, haben wir einen Teil der Information verloren.

Und die Gültigkeit eines Ergebnisses hängt nicht nur von der Gültigkeit seiner Eingänge ab. Auch die Operation selbst kann Bedingungen haben, unter denen kein gültiges Ergebnis entstehen kann. Zum Beispiel:
Result.Value := A.Value / B.Value;
Wenn B.Value = 0 ist, haben wir kein gültiges Ergebnis.
IF A.Valid AND B.Valid AND (B.Value <> 0) THEN
    Result.Value := A.Value / B.Value;
    Result.Valid := TRUE;
ELSE
    Result.Valid := FALSE;
END_IF
Eine ähnliche Frage sollten wir uns bei Durchschnittswerten, Minimum, Maximum, statistischen Funktionen oder überall dort stellen, wo das Ergebnis von der Verfügbarkeit und Verwendbarkeit der Eingangsdaten abhängt.

Es ist ausserdem wichtig, die Gültigkeit eines Wertes nicht mit dem Zustand zu verwechseln, den dieser Wert beschreibt.
Temperature.Value = 150.0
Temperature.Valid = TRUE
150 °C kann weit ausserhalb des zulässigen Betriebsbereichs liegen.
Der Wert ist aber gültig. Der Sensor funktioniert und teilt uns tatsächlich mit, dass wir ein Problem haben. Dagegen:
Temperature.Value = 23.5
Temperature.Valid = FALSE
sieht nach einer perfekten Betriebstemperatur aus, aber dieser Information können wir nicht vertrauen.

Das Valid-Flag beantwortet die Frage: Kann ich dieser Information vertrauen?
Eine Warnung oder ein Alarm beantwortet die Frage: Ist der Zustand, den diese Information beschreibt, in Ordnung?

Auch bei der Visualisierung müssen wir uns überlegen, wie wir dem Benutzer eindeutig anzeigen, dass ein Wert nicht gültig ist. Die HMI sollte nicht einfach Null anzeigen. Wenn wir die Temperatur nicht kennen, sollten wir dem Bediener nicht Folgendes anzeigen:
Temperature: 0.0 °C
Stattdessen könnten wir zum Beispiel Folgendes anzeigen:
Temperature: ???
oder:
Temperature: ***
Eine andere Möglichkeit besteht darin, den letzten bekannten Wert weiterhin anzuzeigen, aber eindeutig visuell zu kennzeichnen, dass er nicht mehr gültig ist. Der letzte bekannte Wert kann beispielsweise für die Diagnose weiterhin sehr nützlich sein. Invalid bedeutet nicht zwangsläufig nutzlos. Es bedeutet lediglich, dass wir diesen Wert nicht als aktuell vertrauenswürdige Information darstellen dürfen. Die HMI sollte deshalb nicht nur für die Zustände "Normal", "Warning" und "Alarm" eine definierte Darstellung haben, sondern auch für "Invalid" / "Not available" / "No connection".

Dieses Prinzip ist auch wichtig bei Trends. Wenn wir während eines Kommunikationsausfalls den Wert nicht kennen, sollten wir nicht Null in die Historie schreiben. Damit würden wir Daten erzeugen, die nie existiert haben. Der Trend sollte stattdessen eine Lücke enthalten. Wenn wir fünf Minuten lang keine Verbindung zum Sensor hatten, wissen wir nicht, was während dieser fünf Minuten passiert ist. Erzeuge keine Historie für einen Zeitraum, für den du keine Informationen hattest.

Die Gültigkeit sollte nicht nur beeinflussen, was der Benutzer sieht, sondern auch, was er tun darf. Wenn beispielsweise die HMI nicht mit der SPS verbunden ist, sollten wir dem Benutzer nicht erlauben, einen Sollwert so zu ändern, dass der Eindruck entsteht, er sei tatsächlich in die SPS geschrieben worden.

Im SPS-Programm können wir das gesamte Prinzip mithilfe eigener Datentypen standardisieren. Zum Beispiel in Structured Text:
TYPE ST_VariableReal :
STRUCT
    Value : REAL;
    Valid : BOOL;
END_STRUCT
END_TYPE

Auf die gleiche Weise können wir weitere Datentypen erstellen:
ST_VariableReal
ST_VariableLreal
ST_VariableBool

und dann zum Beispiel deklarieren:
Temperature : ST_VariableReal;
Pressure : ST_VariableReal;
MachineRun : ST_VariableBool;

Damit erhalten wir immer ein natürliches Paar, zum Beispiel:
Temperature.Value
Temperature.Valid

Nicht jede Hilfsvariable in einem Programm benötigt ein Valid-Flag. Aber immer dann, wenn ein Wert eine Information repräsentiert, die nicht verfügbar, veraltet, unvollständig oder aus einem anderen Grund nicht vertrauenswürdig sein kann, reicht der Wert allein nicht aus. Wir brauchen Value und Valid.

Wann immer wir einen Wert verwenden, sollten wir deshalb nicht nur fragen: Wie lautet der Wert?
Wir sollten uns auch noch diese Frage stellen: Kann ich dem Wert vertrauen?

© Radim-Automation, 2020–2026. Alle Rechte vorbehalten.
Die Verbreitung dieses Artikels ist mit Angabe der Quelle (Link zur Originalseite) ausdrücklich gestattet.

Verwandte vorherige Artikel:

• Wie lange wird eine Störung unsere Produktion stilllegen?
• Resilient Machine Control Design
• Diagnosetools
• Ohne Sensoren geht es nicht
• Klare Signale
• Variablennamen
• Hardwarekonzept
• Gibt es auch Nachteile?
• Denke kritisch!
• HMI- und SPS-Anwendungen sollen zusammenwachsen
• Ich sehe was, was du nicht siehst
• Mehr als nur starten und stoppen
• Mach die richtigen Dinge und mach sie richtig!
• Verwirkliche jede gute Idee so schnell wie möglich!
• Konzentriere dich auf das Ziel!
• Halte es einfach!
• Transparenz und Zuverlässigkeit

Verwandte nächste Artikel:

• Lass KI Automatisierungsprojekte für dich erledigen

Kommentar#: 00001

Datum: 2026-08-27

Benutzer: Radim

Vor vielen Jahren, am Anfang meiner Karriere, arbeitete ich als Softwareentwickler an einem meiner ersten grösseren Projekte. Ich entwickelte ein zentrales SCADA-System für eine Maschine, die von mehreren SPSen gesteuert wurde.

Das Projekt war sehr gut geführt. Ein gutes Konzept, eine gute Dokumentation, klare Spezifikationen und ein realistischer Projektplan.

Zum SCADA-System gehörte auch eine BDE - Betriebsdatenerfassung. Wir sammelten Produktionsdaten in einer Datenbank, aggregierten sie und erstellten Statistiken: die Anzahl der produzierten Teile, die Anzahl der Maschinenstopps pro Schicht, den kürzesten und längsten Stillstand und ähnliche Informationen.

Auch dieser Teil war im Voraus durchdacht und gut spezifiziert.

Als ich jedoch mit der Programmierung begann, stiess ich auf ein Problem. Die Spezifikation berücksichtigte nur den optimalen Zustand, in dem alle Teile der Maschine in Betrieb waren und alle SPSen Daten lieferten. Aber was passiert, wenn ein Teil der Maschine absichtlich ausgeschaltet ist? Was passiert, wenn eine SPS eine Störung hat und keine Daten liefert? Was passiert, wenn die Kommunikation mit dem SCADA-System genau beim Schichtwechsel unterbrochen wird? Während ich all diese IF - THEN - ELSE-Anweisungen programmierte, wurde mir langsam klar, dass die Statistiken in solchen Situationen möglicherweise keine korrekten Ergebnisse liefern würden.

Ich wies darauf hin. Aufgrund der zugesagten Termine bekam ich jedoch im Wesentlichen eine einfache Antwort: "Die Funktion ist spezifiziert. Programmiere sie gemäss der Spezifikation." Also tat ich das.

Die Maschine wurde erfolgreich an viele Kunden auf der ganzen Welt verkauft und ausgeliefert. Mehrere Monate lang passierte nichts.

Dann rief mich eines Tages ein leitender Manager in sein Büro. Ich stand vor seinem Schreibtisch, und er erklärte mir, dass ein Kunde die Abnahme verweigerte, weil die statistischen BDE-Funktionen nicht richtig funktionierten, wenn einige Teile der Maschine ausser Betrieb blieben.

"Was sagst du dazu?"

"Ah... ich weiss", antwortete ich.

Er stand plötzlich von seinem Stuhl auf.

"Was? Du weisst das?"

"Ja. Ich musste es gemäss der Spezifikation programmieren. Situationen, in denen nicht die gesamte Maschine in Betrieb ist, wurden bei der Auswertung der statistischen Daten nicht berücksichtigt."

Er dachte einen Moment nach und sagte dann: "Gut. Dann wirst du das korrigieren. Und danach gehst du zum Kunden und weist nach, dass die Lösung korrekt ist. Du bleibst dort so lange, bis er bestätigt, dass das System funktioniert, und die Abnahme erteilt. Wie viel Zeit brauchst du?"

Wenn ich mich richtig erinnere, bat ich um ungefähr sechs Wochen für die Überarbeitung und eine Woche für die Installation und Tests beim Kunden.

Am Ende blieb ich zwei Wochen beim Kunden. Wir optimierten die letzten Details, der Kunde war zufrieden und erteilte die Abnahme.

An diese Erfahrung erinnere ich mich auch Jahre später noch. Als Junior tat ich damals genau das, was mir gesagt wurde. Ich implementierte die freigegebene Spezifikation. Und trotzdem sah ich bereits während der Implementierung ein Problem, das die Personen, die über die Lösung entschieden, nicht sehen konnten. Nicht, weil sie ihre Arbeit schlecht gemacht hätten. Bei einem komplexen System ist es sehr schwierig, jede mögliche Kombination von Zuständen im Voraus zu berücksichtigen. Manchmal erkennt ein Problem erst derjenige, der tief in die Implementierung einsteigt.

Und genau deshalb reichen eine gute Spezifikation, gute Experten und klar verteilte Aufgaben allein nicht aus. Es muss auch einen Weg geben, neue Erkenntnisse aus der Implementierung zurück zu der Person zu bringen, die die Entscheidungsbefugnis hat. Und diese Person muss bereit sein, eine Entscheidung erneut zu öffnen, wenn neue Informationen auftauchen.