Beispiele für Archivierungskonzepte
Vor dem Konfigurieren der History-Datenbank müssen Sie ein Archivierungskonzept entsprechend den Anforderungen des Kunden erstellen. Dazu müssen Sie das Archivierungskonzept, die Anzahl Speicherungen und die Zeitintervalle definieren.
Es liegen Aktivitäten im Zusammenhang mit Alarmen vor. Wenn die Alarme archiviert werden, sollten diese Aktivitäten aus Konsistenzgründen ebenfalls archiviert werden.
Die History-Datenbank erlaubt die Erstellung von maximal 64 benutzerdefinierten Archivgruppen und 32 Langzeitspeicher-Repositories.
Alle Archivierungsvarianten können auch zu einem späteren Zeitpunkt geändert werden. Daten müssen von Anfang an im richtigen Speicher archiviert werden, da Informationen, die bis zu diesem Zeitpunkt in einem Speicher archiviert wurden, nicht in einen anderen Speicher verschoben werden können.
Sie können den Dateninhalt für einzelne Datengruppen reduzieren.
Symbol | Legende der Symbole |
Datenpunkte | |
Aktivitäts-Logdaten | |
Alarm-Logdaten | |
Ereignis-Logdaten | |
Wert-Logdaten (Online oder Offline) |
Standard: Löschen nach Maximum Aufbewahrungszeit
Im Standardarchivierungskonzept werden die Log-Werte nach Datentypen gruppiert und im Kurzzeitspeicher archiviert, wo sie für eine minimale Aufbewahrungszeit gehalten und nach einer maximalen Aufbewahrungszeit gelöscht werden. Diese beiden Parameter müssen für jede Archivgruppe eingestellt werden. Im Langzeitspeicher werden keine Daten archiviert.

Durch das Aktivieren der Funktion Log-Einträge löschen können alte historische Informationen automatisch aus dem Kurzzeitspeicher gelöscht werden. Die Löschung aus dem Kurzzeitspeicher kann für jede einzelne Standardarchivgruppe oder benutzerdefinierte Archivgruppe separat festgelegt werden.

Hinweis:
Alle Einstellungen für die automatische Löschung sind hinfällig, wenn eine Archivgruppe dem Langzeitspeicher zugeordnet wird. In diesem Fall sind die Eigenschaften ausgegraut.


Historische Daten werden dauerhaft gelöscht und können nicht wiederhergestellt werden.
Definieren Sie ein automatisches Backup (siehe Automatisches Backup) oder legen Sie fest, dass vor dem Löschen eine Archivierung durchgeführt wird.
Beispieleinstellungen für das Speichern nach Tagen | |||
Max. Aufbewahrungszeit für Daten im Kurzzeitspeicher | Min. Aufbewahrungszeit | Max. Aufbewahrungszeit | Löschzeitraum |
30 Tage | 10 Tage | 30 Tage | 1 Tag |
90 Tage | 30 Tage | 90 Tage | 1 Tag |
180 Tage | 90 Tage | 180 Tage | 1 Woche |
Weitere Informationen über das Berechnen der Datenbankgrösse und der Zeitspanne siehe Werte und Datenkapazitätseinstellungen.

Hinweis 1:
Wenn das Löschen deaktiviert wird, werden keine weiteren historischen Daten gelöscht.
Hinweis 2:
Das Startdatum liegt in der Vergangenheit: Wird das Löschen reaktiviert, werden die historischen Daten ausserhalb des definierten Zeitraums sofort gelöscht.
Hinweis 3:
Das Startdatum wird wieder in die Zukunft verlegt: Wird das Löschen reaktiviert, beginnt das Löschen ab dem definierten Datums- und Uhrzeitwert.
Werte und Datenkapazitätseinstellungen
Die folgenden Tabellen geben allgemeine Anhaltspunkte zum Datenvolumen, das in einem Kurzzeitspeicher gehalten werden kann, bevor eine Notlöschung durchgeführt wird. Um die Speichernutzung der Datenbank zu berechnen, wird ein durchschnittlicher Wert von 0,4 KB wird pro Eintrag angenommen. Die tatsächliche Anzahl gespeicherter Einträge kann höher sein als in den Tabellen angegeben.
Die gültigen Einstellungen hängen stark von den maximalen Einträgen pro Tag und pro Datengruppe sowie von rechtlichen Bestimmungen und dem eingesetzten SQL-Server ab (maximal 10 GB für SQL Server Express, 250 GB für SQL Server).

Hinweis:
SQL Server Express ist nicht geeignet, wenn Sie die minimale Aufbewahrungszeit verwenden und mit einer grossen Datenmenge rechnen.
Einstellungen nur mit maximalem Zeitrahmen


Hinweis:
Beim Anwenden der Einstellungen sollten Sie berücksichtigen, dass bei Belegung von 90% der Datenbankkapazität eine Not-Löschung durchgeführt wird.
Verwenden Sie die folgende Tabelle, wenn Sie Datenvolumen präziser berechnen müssen.
Benutzerspeicher pro Datengruppe und Zeilen | |
Datengruppe | KB je Dateneintrag |
Zeitreihen | 0,057 |
Aktivitätslog | 0,37 |
Alarmlog | 0,38 |
Alarme | 0,21 |
Konzept 1: Einfache Archivierung mit einem Speicher
Diese Archivierungsvariante erfordert den geringsten Konfigurationsaufwand. Alle protokollierten Daten werden in einem einzigen Speicher archiviert . Nach Ablauf des eingestellten Zeitabschnittsintervalls (hier: ein Jahr) oder wenn der bisherige Speicher voll ist, wird ein neuer Langzeitspeicher angelegt.

Konzept 2: Einfache Archivierung mit doppeltem Speicher
Für einen bestimmten Datentyp (hier: Werte-Log-Daten) kann ein separater Langzeitspeicher angelegt werden wenn eine grosse Menge an Daten dieses Typs erwartet wird. In diesem Fall empfiehlt es sich, das Zeitabschnittsintervall auf einen Monat festzulegen. (Siehe Einfache Archivierung mit zwei Speichern)
Alle Daten des Aktivitäts-, Alarm- und Ereignis-Logs werden in einem Speicher archiviert.

Konzept 3: Archivierung mit benutzerdefinierten Speicherzeiträumen
Das Konzept der Archivierung mit benutzerdefinierten Speicherzeiträumen wird empfohlen, wenn ein Projekt mehrere benutzerdefinierte Gruppen von Datenpunkten erfordert, deren protokollierte Daten nicht in demselben Langzeitspeicher gespeichert werden können, sondern auf mehrere Speicher verteilt werden müssen. Im folgenden Beispiel sind drei benutzerdefinierte Archivgruppen vorhanden, die unterschiedliche Kombinationen von Datentypen in drei Langzeitspeichereinheiten mit benutzerdefinierten Zeitabschnittsintervallen speichern. Die Daten aller Datenpunkte, die keiner benutzerdefinierten Archivgruppe zugeordnet wurden, werden entsprechend dem Standardarchivkonzept, d.h. im standardmässigen Kurzzeitspeicher, gespeichert und nach der für die Standardarchivgruppen festgelegten maximalen Aufbewahrungszeit gelöscht.
Einige der protokollierten Daten müssen monatlich oder jährlich in einem Speicher archiviert werden. Alle anderen Daten müssen nicht archiviert werden.

Konzept 4: Werte von einzelnen Datenpunkten aufbewahren
Bestimmte Arten von sensiblen Daten dürfen aus rechtlichen Gründen nur für einen begrenzten Zeitraum aufbewahrt werden. Das folgende Beispiel erfordert drei benutzerdefinierte Archivgruppen. Es werden zwei Archivgruppen erstellt, eine mit einer Aufbewahrungszeit von sieben Tagen und eine mit einer Aufbewahrungszeit von drei Monaten. Das Alter der Daten wird täglich überprüft. Durch die Festlegung einer maximalen Aufbewahrungszeit, z.B. von 7 Tagen, werden die ältesten Daten automatisch gelöscht und nicht archiviert. Alle Datenpunkte, die keiner benutzerdefinierten Archivgruppe zugewiesen wurden, werden im Langzeitspeicher gespeichert. (Siehe Werte von einzelnen Datenpunkten aufbewahren.)
Einige der protokollierten Daten müssen monatlich oder jährlich archiviert werden. Alle anderen protokollierten Daten werden in einem separaten Speicher archiviert.

Konzept 5: Werte von einzelnen Datenpunkten und Standardarchivgruppen aufbewahren
Es ist möglich, dem Kurzzeitspeicher sowohl benutzerdefinierte als auch Standardarchivgruppen zuzuweisen. Für jede Archivgruppe kann eine individuelle Aufbewahrungszeit festgelegt werden. In dem folgenden Beispiel werden drei Archivgruppen, zwei benutzerdefinierte und eine Standardarchivgruppe, verwendet, deren Daten im Kurzzeitspeicher mit jeweils unterschiedlichen Aufbewahrungszeiträumen archiviert werden. (Siehe Werte von einzelnen Datenpunkten und Standardarchivgruppen aufbewahren.)

Konzept 6: Filtern mit Filtergruppen
Einige der protokollierten Daten müssen gefiltert werden. Durch die Filterung wird die Kommunikations- und Datenmenge reduziert, die in der HDB gespeichert werden.
Dieses Filterkonzept empfiehlt sich, wenn für ein Projekt Datenpunktgruppen benötigt werden, deren COV-Daten nach Werten oder Zeiten gefiltert werden sollen. Der Filter bewirkt, dass nur die Werte protokolliert werden, die die Filterkriterien erfüllen. Um festzustellen, ob ein Wert in der Vergangenheit gefiltert wurde, konsultieren Sie die Spalte Gefiltert in der Tabelle HDB_DpIdsTs in der HDB oder in abgeschlossenen und archivierten Datenbanken (LTS).
Einem Datenpunkt können die folgenden Filtergruppen zugewiesen werden:
- Nicht zugewiesen: Die Daten aller Datenpunkte, die keiner Filtergruppe zugewiesen sind, werden basierend auf einem Wertvergleichsfilter protokolliert. Das System vergleicht dazu einen neuen Systemwert und dessen Qualität mit dem zuletzt protokollierten Wert und der Qualität, bevor der Wert protokolliert oder gefiltert wird.
Filtergruppe "Nicht zugewiesen" - Ungefiltert: Wenn Datenpunkte der Filtergruppe Ungefiltert zugewiesen sind, werden die Daten ohne jeglichen Vergleich der Werte und Qualität protokolliert. Diese Art von Daten wird benötigt, wenn der gleiche Wert zu Aggregationszwecken protokolliert werden muss.
Filtergruppe "Ungefiltert" - Gefiltert: Wenn Datenpunkte einer wertbasierten Filtertyp-Filtergruppe zugewiesen werden, werden Daten basierend auf prozentualen und absoluten Totzonen-Werten protokolliert und wenn sie einer Filtergruppe vom Typ Zeitintervallprotokollierung zugewiesen sind, werden Daten basierend auf dem definierten Intervall protokolliert. Siehe Arbeitsbereich Filtergruppen.

In dem Beispiel unten ist eine Filtergruppe zu sehen, die Werte basierend auf Wertfiltern filtert.

Anwendungsfälle für die Filtergruppe "Zeitintervallprotokollierung"
Anwendungsfall 1:
Bei Projekten, bei denen verschiedene Subsysteme mit sich schnell ändernden Werten (z.B. Änderungen pro Sekunde) integriert werden, ist die Anzahl der generierten COV-Online-Trends enorm hoch und wirkt sich erheblich auf die Grösse der HDB aus.
Beispiel: Wir haben es mit einem sich in der Zeit schnell ändernden Objekt zu tun, das die folgenden Werte generiert. In diesem Beispiel kann eine Filtergruppe mit einem Zeitfenster von 1 Minute definiert werden. Dadurch wird sichergestellt, dass pro Minute nicht mehr als ein HDB-Datensatz generiert wird.
Das Ergebnis ist:
Zeit (H/M/S) | COV - Input vom Subsystemsensor | Aktuelles HDB-Log | Neues HDB-Log |
12:00:00 | 10 | 10 | 10 |
12:00:10 | 11 | 11 |
|
12:00:20 | 12 | 12 |
|
12:00:30 | 13 | 13 |
|
12:01:00 |
|
| 13 |
12:01:30 | 14 | 14 |
|
12:01:40 | 15 | 15 |
|
12:02:00 |
|
| 15 |
12:02:15 | 16 | 16 |
|
Anwendungsfall 2:
Bei Projekten, die verschiedene Subsysteme mit sich langsam ändernden Werten integrieren (z.B. Änderungen pro Stunde), ist es nicht einfach, die HDB-Werte pro Zeit für ein solches Objekt abzufragen.
Beispiel: Wir haben es mit einem sich in der Zeit langsam ändernden Objekt zu tun, das die folgenden Werte generiert. In diesem Beispiel kann eine Filtergruppe mit einem Zeitfenster von 1 Minute definiert werden, in dem in jeder Minute noch der letzte verfügbare Wert in der HDB protokolliert ist. Dadurch wird sichergestellt, dass pro Minute immer ein HDB-Datensatz generiert wird.
Das Ergebnis ist:
Zeit (H/M/S) | COV - Input vom Subsystemsensor | Aktuelles HDB-Log | Neues HDB-Log |
12:00:00 | 10 | 10 | 10 |
12:01:00 |
|
| 10 |
12:02:00 |
|
| 10 |
12:02:10 | 11 | 11 |
|
12:03:00 |
|
| 11 |
12:04:00 |
|
| 11 |
12:05:00 |
|
| 11 |
12:05:20 | 12 | 12 |
|
12:06:00 |
|
| 12 |