NGA - Hinweise und Einschränkungen

Kompatibilität

NGA verwendet die gleichen Datenpunkt-Configs (_archive und _alert_class) und Attribute für die Konfiguration des Archivverhaltens auf Datenpunktelement-Ebene wie bestehende Archivierungslösungen in WinCC OA. Da NGA die Möglichkeit bietet in mehreren Zielen zu archivieren (z.B. zwei Datenbanken zur gleichen Zeit), wurden diese Konfigurationen entsprechend erweitert, um dies zu ermöglichen.

Anmerkung: Archivglättungen können durchgeführt werden, müssen aber für jede Archivgruppe einzeln konfiguriert werden.

Um bestehende Archivkonfigurationen für NGA zu konvertieren, muss die Zuweisung der Archivgruppe für jedes Datenpunktelement auf eine NGA-Archivgruppe umgestellt werden. In der aktuellen Version ist die Alarmarchivierung ident zwischen NGA und den Wertarchiven / RAIMA / RDB-Manager, d.h. es ist keine Konvertierung erforderlich.

Die NGA-Konfiguration (welche Archivgruppen existieren, Segmentkonfigurationen, usw.) ist unterschiedlich zur Konfiguration des RDB-Managers oder den Wertarchiven. Hier ist keine automatische Konvertierung möglich.

VORSICHT: Beachten Sie, dass diese Schritte nur mit ausreichenden WinCC OA-Kenntnissen ausgeführt werden sollten.

Import von ASCII-Dateien mit "altem" Archiv-Config

Für das Importieren von ASCII-Dateien, welche Archivkonfigurationen beinhalten und noch nicht für die NGA-Verwendung angepasst wurden, müssen folgende Schritte befolgt werden:

  • Starten Sie das Projekt ohne den NGA-Manager.
  • Legen Sie die erforderlichen Archivgruppen mittels des NGA- Konfigurationspanels an, z.B. eine Gruppe je Wertearchiv / RDB-Gruppe.
  • Entweder:
    1. Bearbeiten Sie die ASCII-Datei und ändern Sie jede Referenz auf das Wertearchiv / die RDB-Gruppe in allen Sektionen der Archivkonfiguration auf die entsprechende NGA-Gruppe (z.B. Ändern Sie alle "_ValueArchive_<Archiv-Nummer>" auf "_NGA_G_<Archivgruppen Name>").
    2. Starten Sie den NGA-Manager.
    3. Importieren Sie die ASCII-Datei.
    oder
    1. Starten Sie den NGA-Manager.
    2. Importieren Sie die ASCII-Datei (Fehlermeldungen könnten im LogViewer angezeigt werden).
    3. Verwenden Sie den PARA, um die Archivgruppen auf die entsprechenden NGA-Archivgruppen anzupassen. Beachten Sie, dass die "alten" Wertarchive / RDB-Gruppen nicht mehr angezeigt werden.

Konvertieren eines bestehenden Projekts auf NextGen Archiver

Zum momentanen Zeitpunkt gibt es kein Tool für die automatische Konvertierung bestehender Projekte (basierend auf HDB oder RDB) auf NextGen Archiver. Anbei finden Sie einen Überblick für die erforderlichen manuellen Schritte (für erfahrene Benutzer), um ein Projekt zu konvertieren:

VORSICHT:

Alle bestehenden historischen Daten gehen verloren!

  1. Updaten Sie Ihr Projekt auf die neueste WinCC OA-Version 3.18. Nur erforderlich für Projekte aus älteren WinCC OA-Versionen.
    Anmerkung: Beachten Sie, dass eine Archivgruppe für NGA nicht leer sein darf, wenn ein existierendes HDB- oder RDB-Projekt in ein NGA-Projekt konvertiert wird.
  2. Exportieren Sie alle Archivkonfigurationen mit Hilfe des ASCII-Managers.
  3. Fügen Sie den Config-Eintrag [general] useNGA = 1 in der Config-Datei Ihres Projekts hinzu.
  4. Fügen Sie innerhalb des Projekts den Manager "NextGen Archiver" in der Startreihenfolge der WinCC OA-Konsole vor dem Event-Manager hinzu.
  5. Entfernen Sie die Wertarchive / den RDB-Manager aus Ihrem Projekt (Konsole) über die WinCC OA-Konsole.
  6. Erstellen Sie ein neues separates NGA-Projekt "NGA_Projekt", aus welchem die erforderlichen Konfigurationsdateien kopiert werden können. Dieses Projekt kann nach erfolgreicher Durchführung der Konvertierung wieder entfernt werden.
  7. Kopieren Sie die Datei "influxdb.conf" aus dem temporär erzeugten "NGA_Projekt" in das config-Verzeichnis Ihres Zielprojektes und passen Sie die Pfade der [meta] und [data] Sektion ("dir", "wal-dir") entsprechend in dieser Datei an.
  8. Kopieren Sie die Verzeichnisse "influx" und "nga" (Pfad: WinCC_OA_Proj/db/winccoa) aus dem temporär erzeugten "NGA_Projekt" an die gleiche Stelle in Ihrem Zielprojekt.
  9. Starten Sie Ihr Projekt (Fehlermeldungen können für den NGA-Manager im LogViewer angezeigt werden).
  10. Fügen Sie NGA-Gruppen und erforderliche Backends dem Projekt hinzu.
  11. Bearbeiten Sie die ASCII-Datei und ändern Sie jede Referenz auf das Wertearchiv / die RDB-Gruppe in allen Sektionen der Archivkonfiguration auf die entsprechende NGA-Gruppe (z.B. Ändern Sie alle "_ValueArchive_<Archiv-Nummer>" auf "_NGA_G_<Archivgruppen Name>").
  12. Importieren Sie die ASCII-Datei.
  13. Wenn die Meldung "SEVERE, 0, , partial write: max-values-per-tag limit exceeded ... " im LogViewer angezeigt wird, ist die Anzahl der archivierten DPEs höher als das Defaultlimit von 100.000. Die Datei influxdb.conf (in <winccoa_path>/config) enthält den Eintrag "max_values_per_tag", um diesen Wert zu ändern. Wenn der Eintrag auf 0 gesetzt wurde, ist die Anzahl der DPEs nicht limitiert aber die Performanz und Ressourcenverbrauch des InfluxDB®-Prozesses verschlechtern sich da mehr neue DPEs hinzugefügt werden. Der InfluxDB®-Prozess muss neu gestartet werden, um die Änderung zu übernehmen.

Wie wird eine existierende InfluxDB® eines Projekts ersetzt

Eine existierende InfluxDB® sollte mit einer leeren ersetzt werden. Das WinCC_OA_Proj/db/wincc_oa/influx-Verzeichnis muss gelöscht werden und mit dem "/db/wincc_oa/influx" der WinCC OA-Installation (default: wincc_oa_path) ersetzt werden. Nachdem das Verzeichnis ersetzt wurde, muss die Datenbank erneut konfiguriert werden, sieheKonfiguration - Grundlagen.

Einschränkungen

  • Im Emergency Mode werden Anfragen zu historischen Daten nicht beantwortet.
  • Wenn ein Datenpunkt in einem NGA Projekt umbenannt werden soll, erscheint kein Warungsdialog, und die archivierten Daten gehen mit dem Umbenennen verloren.
  • WinCC OA-Onlinebackup: Derzeit enthält der WinCC OA-Onlinebackup keine NGA-Daten (z.B. keinen InfluxDB®-Backup). Beachten Sie, dass der NGA-Backup sich nur auf Segmente bezieht. Daher darf er nicht als Disaster Recovery-Backup verwendet werden. Eine komplette Sicherung (Dateikopie) der InfluxDB® kann erstellt werden, wenn die Datenbank heruntergefahren wurde (siehe Kapitel Konfiguration - Backend). Aufgrund des NGA-Pufferingmechanismus gehen keine Daten verloren. Für den vollen PostgreSQL®-Backup, lesen Sie die PostgreSQL®-Dokumentation des Herstellers.
  • In besonderen Konstellationen und bei Verwendung von NGA kann es zu geringfügigen Verschiebungen der CPU-Last von den zur Archivierung von Daten verwendeten Managern (HDB-Projekt: Datenmanager + Archivmanager / NGA-Projekt: Datenmanager + NGA-Manager) zum Event-Manager kommen.
  • BLOBs/dyn_blobs können nicht gespeichert werden, wenn ein InfluxDB®-Backend verwendet wird.
  • Split-Modus steht für redundante NGA-Projekte nicht zur Verfügung! Der Split-Modus wird in einem zukünftigen Patch verfügbar sein.

  • Im Falle einer Netzwerkunterbrechung zwischen den redundanten Hosts kann die Konsistenz der Datenbank nicht garantiert werden. Welche der beiden Hosts die gepufferten Daten für einen bestimmten Zeitpunkt nach dem erneuten Aufbau der Datenbankverbindungen schreibt, ist nicht eindeutig definiert.

    Das Schreiben der Daten erfolgt direkt nach dem Öffnen der Verbindung zur Datenbank ohne Synchronisation der Schreibvorgänge mit dem redundanten Partner.

    Im Falle von Duplikaten oder unterschiedlichen Werten für den selben Zeitpunkt hängt es von der Datenbank ab, was mit den doppelten Werten geschieht.

    • Bei InfluxDB®, wird ein Wert mit dem neuen Wert überschrieben.
    • Bei PostgreSQL® bleiben beide Werte in der Datenbank erhalten (BRIN Index)
    • Bei PostgreSQL® bleibt der erste Wert in der Datenbank erhalten. Normalerweise ist die lokale Datenbank schneller und damit bleibt der lokale Wert in der Datenbank (BTREE Index).
    • Bei MS SQL® versuchen beide Seiten, in die Datenbank zu schreiben. Das bedeutet, dass der erste Server, der einen Wert schreiben kann, gewinnt und der zuerst geschriebene Wert in der Datenbank bleibt.
  • Das Schlüsselwort FIRST funktioniert nur, wenn eine Abfrage nach Zeitstempeln sortiert ist. Das Schlüsselwort LAST funktioniert nicht mit NGA.
  • Einige Config-Einträge in HDB und RAIMA, insbesondere solche, die sich auf die Historie beziehen (wie maxAlertRequestCount und maxLinesInQuery), gelten nicht für SQLite® und NGA. Stattdessen werden NGA-spezifische Datenpunkte wie limitEventQuerySize und limitAlertQuerySize verwendet.
  • Nach einer Änderung des Systemnamens/der System-ID in einem NGA-Projekt können die vor der Änderung archivierten historischen Werte nicht mehr abgefragt werden.
  • NGA und RDB oder HDB können nicht gleichzeitig verwendet werden.
  • NGA kann in einem RAIMA oder SQLite®-Projekt verwendet werden. Allerdings kann SQLite® nur mit NGA und nicht mit HDB / RDB-Archivierung verwendet werden.

  • Sie können nicht migrieren:

  • Der "_original"-Config-Wert wird nicht archiviert.
Anmerkung: Die WinCC OA Known Bugs-Liste finden Sie in der WinCC OA-Installation.
Einschränkung: Der Excel Report funktioniert nicht mit dem NextGen Archiver (NGA).
Anmerkung:

Für die Zeitwerte und Variablen ist folgendes zu beachten:

  • Laufzeitwerte/Alarme können mit einer Genauigkeit von bis zu Nanosekunden erstellt werden.
  • Historische Datenbanken behalten die korrekte Reihenfolge bei, speichern aber nur bis zu Millisekunden, d.h. sie verwerfen die Teile mit höherer Genauigkeit.
  • Der Vergleich von Zeitvariablen berücksichtigt nur Millisekunden. Zeitvariablen, die sich nur im Mikrosekunden- oder Nanosekundenbereich unterscheiden, würden von den eingebauten Vergleichsmethoden als gleichwertig angesehen.

SQL-Schlüsselwörter