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.

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.

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.

Lesekonsistenzprüfung für Alarme

Durch die Einführung der Konsistenzprüfung auf ausstehende Daten von Alarmabfragen in 3.19 P006 kommt es bei Abfragen von Zeitbereichen, welche sich mit der aktuellen Zeit überschneiden, zu längeren Abfragezeiten.

Wenn diese erhöhten Abfragezeiten aktiv Auswirkungen auf die Performance auf das Projekt haben, kann diese Prüfung manuell deaktiviert werden. Dies wird jedoch nur beim Auftreten von tatsächlichen Problemen empfohlen, da es bei einer deaktivierten Prüfung vorkommen kann, dass in der durchgeführten Abfrage nicht alle Alarme angezeigt werden, da diese noch nicht in die Datenbank geschrieben wurden.

Die Prüfung kann deaktiviert werden, indem der Config-Eintrag ../../cfg_doku/all_config_entries.html#NextGenArch__timeoutForAlertReadConsistency auf den Wert "0" gesetzt wird.

[NextGenArch]
timeoutForAlertReadConsistency = 0

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.
  • InfluxDB®: Sie können eine Aggregatfunktion für Alarm-Abfragen mit dpQuery und SELECT ALERT verwenden. Allerdings wird nur die Funktion COUNT unterstützt - die Funktionen MIN, MAX, AVG und SUM werden nicht unterstützt. Außerdem kann die Funktion COUNT nur einmal in der Select-Anweisung verwendet werden. Die Alarmzeit einer solchen Ergebniszeile ist die Startzeit der Abfrage. Standardmäßig werden alle Alarmmeldungen des gesamten Systems als eine Zeile gezählt. Sie können nach Elementen gruppieren, um eine Zeile pro Datenpunktelement zu erhalten (wie bei Ereignisabfragen), indem Sie eine GROUP BY _EL-Klausel hinzufügen.
  • 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 von HDB zu NGA migrieren - siehe Kapitel Konvertierungseinstellungen und NextGen Archiver (NGA) Importer

  • Sie können nicht migrieren:

  • Der "_original"-Config-Wert wird nicht archiviert.
  • Daten werden aufgrund von Inkonsistenzen in Schemaversionen gepuffert, und eine Fehlermeldung wird in die Log-Datei geschrieben.
Anmerkung: Die WinCC OA Known Bugs-Liste finden Sie in der WinCC OA-Installation.
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