Erweiterte Einstellungen

Selektieren Sie den Backend-Prozesstyp. Jedes Backend kann als In-Proc (als Shared Library im NGA Frontend-Manager) oder Out-Of-Proc (als separater Prozess) gestartet werden.

• In-Proc (Backend als plugin). Das Frontend ist immer mit dem Backend verbunden. Es gibt nur eine "externe" Verbindung zwischen dem Backend und der Datenbank. Nur diese Verbindung zur Datenbank wird überwacht. Wenn der Prozess stirbt, läuft NGA nicht weiter.
• In-Proc (Backend als plugin) nur für NGA-Manager. Wie oberhalb, aber wird nur für den NGA-Manager und nicht für "Direkte Read-Option" verwendet.
• In-Proc (Backend als plugin) nur für "Direct Read". Wie oberhalb, aber wird nur für "Direkte Read-Option" verwendet.
• Out-Off-Proc (separater Prozess) / In-Proc für "Direct Read". Der Vorteil des separaten eigenständigen Prozesses ist, dass NGA-Frontend weiterläuft, wenn der Prozess unerwartet stoppt . Es gibt eine Verbindung zwischen dem Frontend und dem Backend sowie zwischen dem Backend und der Datenbank. Für die "Out-Off-Proc"-Option können die voreingestellten Einstellungen für Kommunikation (siehe "Kommunikation"-Registerkarte) oder benutzerdefinierte Einstellungen genutzt werden. Werden mehrere Backends "Out-Off-Proc" verwendet, müssen über benutzerdefinierte Einstellungen verschiedene Portnummern für die Kommunikation vergeben werden. Out-Off-Proc wird in In-Proc für die "Direkte Read-Option" konvertiert und in diesem Fall läuft das Backend als Plugin.
• Out-Off-Proc (separater Prozess) nur für NGA-Manager. Wie oberhalb, aber wird nur für den NGA-Manager und nicht für "Direkte Read-Option" verwendet.

Der "Pufferung"-Reiter der NGA Backend-Konfiguration wird genutzt, um Backend-Parameter zu definieren, die mit der Pufferung von Daten zu tun haben, die geschrieben werden sollen.

Die Blöcke können wie folgt gespeichert werden:

Diese Einstellungen definieren wie gepufferte Blöcke im Hauptspeicher gespeichert werden und nach wievielen Millisekunden Blöcke gepuffert werden.

• Blöcke nicht speichern: schnell, aber Daten gehen verloren, wenn der Prozess gestoppt wird oder abstürzt,
• Nur im Hauptspeicher: Puffern im Hauptsspeicher: Konfiguriert wie viele Blöcke sich im Hauptspeicher befinden dürfen. Wenn diese Nummer erreicht ist, werden die ältesten Blöcke gelöscht (wenn "Blöcke speichern in" auf "Nur im Hauptspeicher" gesetzt ist) oder auf eine Festplatte gespeichert (wenn "Blöcke speichern in" auf "Hauptspeicher und Platte" gesetzt ist).
• Nur auf Platte: auf der Festplatte (langsam aber sicherer) oder
• Hauptspeicher und Platte: auf beiden Orten (neu gepufferte Daten werden im Speicher gespeichert, alte Daten auf einer Festplatte)

Puffere nach [ms]: Wenn ein Block nicht in diesem Zeitintervall in der Datenbank abgelegt werden kann, wird sie gepuffert.

Blockanzahl: Blöcke werden gepuffert nachdem die Anzahl von Blöcken erstellt wurden.

Werte per Block ODER ms: Definiert Parameter, wenn ein Block an ein Backend gesendet wird. Um die Leistung zu verbessern, werden Daten (Alarme und Ereignisse) in "Blocks" gesendet. Die Entscheidung wann ein "Block" an das Backend gesendet wird, kann von seiner Größe abhängen ("Werte pro Block"), z.B. , wenn die Anzahl an Ereignissen und Alarmen in einem Block gespeichert ist, wird sie ans Backend geschickt. Zusätzlich kann auch ein Timeout ("ms") definiert werden, welche die maximale Zeit angibt, in der kein Puffer gesendet wird. Nach diesem Zeitintervall (beginnend mit dem Erstellen eines neuen Puffers) wird der Puffer zum Backend gesendet, unabhängig von der Anzahl von Ereignissen und Alarmen, die darin gespeichert sind.

Puffer nach Start einlesen: Diese Einstellung gibt an ob beim Start bestehende Puffer-Dateien (aus der letzten Sitzung) eingelesen werden sollen oder nicht.

Ort für Pufferdateien: Verzeichnisse zum Speichern des Plattenpuffers. Das voreingestellte Verzeichnis (wenn leer) ist <projdir>/db/wincc_oa/nga. Absolute und relative (zu <projdir>/db/wincc_oa) Pfade können angegeben werden.

Pufferdatei-Präfix: Da die Namen von Pufferdateien nur aus Nummern bestehen, die mit der Zeit größer werden, muss jedes Backend eine spezifisches Präfix nutzen, wenn alle Puffer im gleichen Verzeichnis gespeichert werden, um identische Dateinamen zwischen verschiedenen Backends zu vermeiden.

Der "Kommunikation"-Reiter der NGA Backend-Konfiguration wird verwendet, um spezifische "timing"-Parameter für die Kommunikation zwischen NGA Front- und Backend zu definieren. Diese Parameter haben einen Effekt auf die Schreib- und Leseperformance und sollten nicht geändert werden außer die Auswirkungen werden vollkommen verstanden.

• Nur für Experten: Aktivieren Sie diese Checkbox, um Werte unterhalb zu definieren. Diese Einstellungen sind nur für Experten und eine falsche Konfiguration kann zu einem kritischen Engpass im Datenfluss zum Backend führen.
• ZMQ timeout [ms]: Polling-Interval für ZMQ, ein hoher Wert wird die Leistung vermindern (aber die Reaktionszeit erhöhen, z.B. um das NGA zu stoppen), ein niedriger Wert braucht mehr Prozessorleistung. HINWEIS: ZMQ-Kommunikation ist nicht verschlüsselt.
• Backend Schreiben [ms]: Maximale Wartezeit für Backend-Rückmeldung beim Schreiben; dauert der Vorgang länger, wird eine Fehlermeldung angezeigt und der Wert sollte erhöht werden.
• Async Task [ms]: Zeit, die gewartet werden muss, um den Datenbank-Schreibevorgang abzuschließen. Sollte diese Zeit überschritten werden, wird das NGA den aktuellen Datenpuffer auf die Festplatte schreiben (wenn die Platten-Pufferung aktiv ist).

DPEs senden als: Abhängig von den Möglichkeiten des Backends können die Datenpunkte an die Datenbank als ID und/oder als DPE-Name übertragen werden. Auch Aliase können an das Backend übertragen werden. Diese Einstellung ist normalerweise durch das Profil vordefiniert (z.B. Ersteller des Backends) und sollte nicht für aktuell existierende Backends verändert werden.

Aufspaltungsgröße: Diese Einstellung definiert die Anzahl der Aufzeichnungen, in welchen die Antworten auf Leseanfragen gruppiert werden, um die Datenübertragung zu beschleunigen. Bei der Verwendung von "Split"-Funktionen in WinCC OA (z.B. dpGetPeriodSplit()) ist dies die Größe eines "Blocks". Aufspaltungsgröße = Anzahl der Aufzeichnungenzeilen. In der Abbildung oberhalb 1000 Zeilen. Der empfohlene Bereich ist 200-10.000. 1 bedeutet, dass das Backend nicht blockweise abgefragt und geliefert wird, sondern als ein Ganzes. Vermeiden Sie Werte außerhalb des empfohlenen Bereiches, da dies einen großen Einfluss auf die Performanz haben kann.