Datenpersistenz¶

Persistente Daten sind Daten, die auch bei einem erneuten Laden der Applikation ihre Werte behalten. Die Werte persistenter Daten können Sie nach einem Download oder Kaltstart wiederherstellen.

CODESYS bietet folgende drei Mechanismen zum Erreichen von Persistenz:

1. Deklaration von VAR PERSISTENT-Variablen in POUs. VAR PERSISTENT-Variablen werden mit Hilfe des Persistenzeditors in einer globalen persistenten Variablenliste verwaltet und bearbeitet. Diesen Mechanismus muss die Steuerung durch einen entsprechenden Speicher unterstützen (NVRam, USV)! Typischerweise werden die VAR PERSISTENT-Variablen dort sogar in einem eigenen Speichersegment abgelegt. Im Gegensatz zu (B) entsteht kein zusätzlicher Zeitbedarf für das Sichern der Daten. Es gehen jedoch die Werte verloren, wenn Namen oder Datentypen in der Deklaration geändert werden. Ausführliche Informationen zu den persistenten Variablen finden Sie im Kapitel “Remanente Variablen - RETAIN, PERSISTENT”. Wenn der Anwendungsfall Änderungen von Namen und Datentypen der persistenten Variablen häufig erfordert, sollten Sie sich auf die Verwendung von Retain-Variablen beschränken oder eine Definition über den Mechanismus des Persistence Managers des Application Composers erwägen. Beachten Sie zum Unterschied zu den Retain-Variablen auch den i-Hinweis unten und die Informationen zu den Variablentypen PERSISTENT und RETAIN.
1. Deklaration von persistenten Variablen über den Persistence Manager des Application Composers: Sie kennzeichnen Variablen im Applikationsprogramm über Attribute als persistent und der Application Composer speichert die persistenten Variablen mit ihren Werten in einer externen Archivdatei. Es gibt somit keine speziellen Anforderungen an die Speicherausstattung der Steuerung. Der Funktionsumfang ist in folgenden Punkten größer als beim VAR PERSISTENT-Mechanismus, allerdings auf Kosten der Performanz: In Abhängigkeit von der Steuerung kann das Lesen und insbesondere das Schreiben einer großen Menge persistenter Variablen sehr lange dauern und die entsprechende Task lange blockieren.
- Konfigurierbares Speicher- und Einleseverhalten: Sie können verschiedene “Persistenzgruppen” mit Variablen füllen und für jede Gruppe ein bestimmtes Speicher- und Einleseverhalten konfigurieren. Sie können Variablen über Deklaration oder Attribute als persistent kennzeichnen.
- Werteerhaltung, auch wenn sich Deklarationen ändern: Wenn Sie persistente Variablen aus der Applikation löschen oder neu hinzufügen, wird automatisch dafür gesorgt, dass keine persistenten Werte verloren gehen. Für die Fälle von Datentyp-Änderungen können Sie passende Konvertierungen konfigurieren, die ebenfalls bewirken, dass die persistenten Werte erhalten bleiben.
- Externe Dateien: Da die persistenten Daten nur in externen Dateien verwaltet werden, benötigt die SPS keine spezielle Speicherausstattung. Außerdem können Sie die Datensätze sowohl in einem externen Editor (zum Beispiel: Notepad) bearbeiten, als auch auf einfache Weise zwischen Applikationen austauschen.
1. Rezepturen: Eine Rezeptur enthält einen definierbaren Satz an Variablen mit Werten und kann unter einem bestimmten Namen als Datei abgelegt werden. Für die gleichen Variablen können Sie verschiedene Rezepturen abspeichern und die jeweils gewünschte Rezeptur auf die Steuerung schreiben. Zum Erstellen einer Rezeptur können Sie aktuelle Werte aus der Steuerung lesen oder die Rezeptur manuell oder programmatisch aus der Applikation befüllen. Die Verwaltung erfolgt im Rezepturverwalter.

Siehe auch

Bemerkung

Ein weitere Möglichkeit, Daten remanent zu halten, sind die RETAIN-Variablen. Persistente Daten sind immer auch RETAIN. Die RETAIN-Variablen behalten wie die persistenten Variablen bei einem Reset Warm (Stromausfall) ihre Werte, nicht aber bei einem erneuten Download der Applikation, den nur die persistenten Daten überdauern. Über eine Deklaration mit RETAIN + PERSISTENT können Sie die remanenten Eigenschaften auch kombinieren. Dabei werden auch die nur mit VAR PERSISTENT deklarierten Variablen immer als VAR RETAIN PERSISTENT oder VAR PERSISTENT RETAIN behandelt. Dadurch erhalten Sie Daten, die nur noch beim Zurücksetzen der Steuerung in den Auslieferungszustand neu initialisiert werden (Reset Origin).

Welcher Mechanismus für welchen Anwendungsfall?¶
Hier werden einige übliche Anwendungsfälle betrachtet, die konkreten Beispiele in Klammern beziehen sich auf eine Haussteuerung:
	Anwendungsfall	(A) VAR PERSISTENT	(B) Persistence Manager	(C) Rezepturen

1	Erhalten von Geräteeinstellungen (Stromausfall -> Jalousie “weiß” danach noch, wie lange sie fürs Hochfahren braucht)	geeignet¹ (bevorzugter Anwendungsfall, ist aber auch über `VAR RETAIN` möglich; wenn die Variablen-Definition im Praxisfall des öfteren geändert werden muss, sollten besser Retain-Variablen verwendet werden.	geeignet² Vorteil: durch spezielle Funktionalitäten (double file buffering) auch für Steuerungen ohne Hardware-Unterstützung einsetzbar	Möglich, aber sehr umständlich

2	Erhalten von Werten auch bei Ändern/Erweitern des Applikationsprogramms
	2a: seltene Erweiterungen (neuer Schalter, neues Licht wurden eingebaut, der Rest bleibt unberührt)	geeignet ¹ (bevorzugter Anwendungsfall)	geeignet²	Möglich aber umständlich
	2b:freiere Änderungen, auch Löschen oder Ändern des Datentyps von Variablen (die Haussteuerung läuft und ist persistiert, jetzt wird aber neue Funktionalität eingebaut, so dass in einem Funktionsbaustein eine weitere Variable persistiert werden muss; beispielsweise automatisches Ausschalten einer vergessenen Lampe nach gewisser Zeit)	nicht geeignet	geeignet soweit möglich ² (bevorzugter Anwendungsfall)	Möglich, wenn textuell, aber umständlich
3	Verwenden verschiedener Wertesätze nach Bedarf (Betriebseinstellungen für Sommer, Winter, Urlaub sollen abgelegt und nach Bedarf eingespielt werden können)	nicht geeignet	nicht geeignet	geeignet (bevorzugter Anwendungsfall)

4	Übertragen der Einstellungen von einer Anlage auf eine andere, die ähnliche Variablen verwendet	nicht geeignet	geeignet²	geeignet³

5	Einstellungen sollen textuell lesbar sein (um Stände/Änderungen vergleichen und editieren zu können)	nicht geeignet	geeignet²	geeignet³

¹ Nachteil: Laufzeitsystem muss den Mechanismus unterstützen: NVRam-Speicher oder USV; Vorteil: Schnelligkeit; empfohlener Anwendungsfall: 1 und 2a

² Nachteil: Im Falle großer Variablenmengen (> 10000) lange Wartezeiten bei Initialisierung und Shutdown; Vorteil: Keine spezielle Speicherausstattung nötig; Werteerhalt auch bei Änderungen/Erweiterungen/Löschungen;

³ Vorteil: Extern bearbeitbar, Übertragbarkeit; Nachteil: umständlich

Siehe auch