Erweiterte Konfiguration

Die folgenden Konfigurationseinstellungen sind optional und müssen für die Basisanwendung des Dashboards nicht verändert werden. Sie erlauben eine weitergehende Anpassung des Dashboards für fortgeschrittene Benutzer oder die spezielle Handhabung der Netzwerkkonfiguration Ihrer Anlage.

Zertifikate

Nachdem Sie den Dashboard-Server eingerichtet haben, wird empfohlen, dass Sie die HTTP-Server-Zertifikate in Ihrem Browser oder im Zertifikatspeicher des Client-Betriebssystems installieren, um sicherzustellen, dass eine sichere Verbindung hergestellt werden kann.

Wenn die Zertifikate nicht ordnungsgemäß auf Ihrem Client installiert sind, ist eine Verbindung zum Dashboard dennoch möglich, aber einige Features können möglicherweise nicht verwendet werden, da eine sichere Verbindung erforderlich ist, z. B. Shared Worker.

VORSICHT:
Bitte beachten Sie, dass Standardzertifikate eines Legacy-Standardprojekt nicht in einer produktiven Umgebung verwendet werden dürfen!

In Firefox und Edge ist es erforderlich, dass die Ausnahme für selbstsignierte Zertifikate zweimal akzeptiert werden muss. Einmal für die Verbindung zum HTTP-Server (URL: https://<Server Host Name>:<HTTPS Port>) und einmal für die Verbindung zum WebSocket-Server (URL: https://<Server Host Name>:<WebSocket Port>).

Dashboard-Benutzerberechtigungen

Abhängig vom Einsatzgebiet muss der Benutzer spezifische Berechtigungen haben. Folgende Berechtigungen werden für die Dashboard-Benutzer für das Anzeigen, Bearbeiten oder Veröffentlichen von Dashboards benötigt:

  • Benutzer, welche keine Berechtigungsbits gesetzt haben, dürfen Dashboards nur sehen, jedoch nicht bearbeiten oder veröffentlichen.
  • Benutzer mit dem Berechtigungsbit 3 können Dashboards bearbeiten. Das erforderliche Berechtigungsbit kann über den Config-Eintrag [wssServer] canEditPermissionBit angepasst werden.
  • Benutzer mit dem Berechtigungsbit 4 können Dashboards veröffentlichen. Das erforderliche Berechtigungsbit kann über den Config-Eintrag [wssServer] canPublishPermissionBit angepasst werden.
  • Das Berechtigungsbit 4 wird auch für das Schreiben auf Datenpunkte mit dpSet() vom Dashboard aus verwendet, welches ebenfalls über [wssServer] canWritePermissionBit gesetzt werden kann.
    Der Standardwert ist "4", was Schreibrechte gewährt. Diese können auch durch Aktivieren des Kontrollkästchens Mit Schreibrechten anmelden auf der Anmeldeseite erlangt werden. Wenn [wssServer] canWritePermissionBit auf "0" gesetzt ist, wird die Nutzung des ULCUX-Widgets und aller Befehls-Widgets global deaktiviert.

Jeder Dashboard-Benutzer muss ein Passwort gesetzt haben.

Einschränkung:
Der Benutzer root ist nicht berechtigt, sich innerhalb des Dashboards einzuloggen.

Webserver-Port

Standardmäßig verwendet der Webserver die Ports 443 (Windows) oder 8443 (Linux). Dies kann über den Config-Eintrag [webClient] httpsPort angepasst werden.

WebSocket-Port

Zusätzlich zu dem HTTP Server Port, der zur Verbindung mit dem Dashboard verwendet wird, ist ein weiterer Port für die WebSocket-Verbindung in Verwendung. Standardmäßig ist dieser Port 8448, er kann über den Config-Eintrag [wssServer] httpsPort verändert werden.

Wichtig:
Es muss sichergestellt werden, dass beide in Betrieb befindlichen Dashboard-Ports (HTTP-Server und WebSocket) innerhalb ihres Netzwerks und der Firewall-Konfiguration erreichbar sind.

Webserver-Redirect

Um innerhalb Ihres Webservers eine Weiterleitung auf die Dashboard-Instanz einzurichten, aktualisieren Sie die Config-Datei durch Einfügen oder Ändern des Config-Eintrages [httpServer] indexPage auf: 

[httpServer]
indexPage = "data/dashboard-wc/index.html"

Dadurch können Sie das Dashboard nun über die nachfolgende URL direkt aufrufen:

https://localhost
Anmerkung:
Bitte beachten Sie, dass für diese URL nicht, wie bei der URL des Dashboards, eine Ausnahme für die HTTP-Server Authentifizierung hinterlegt wurde, d.h. es ist erforderlich, sich vor dem Login bereits mit dem WinCC OA-Benutzer für den HTTP-Server zu authentifizieren. Um diese zusätzliche Authentifizierung zu deaktivieren, siehe HTTP-Server Authentifizierung.
Abbildung 1. HTTP-Server Authentifizierungsdialog (Chrome)
Tipp:
Für einen Linux Server muss der HTTPS-Port manuell an die URL angefügt werden, da ein automatischer Redirect auf den Standard-Linux-Port 8443 nicht verfügbar ist.
Achtung:
Mit dieser Änderung ändern Sie die Download-URL des Desktop UIs von https://<Your Server Host Name> auf https://<Your Server Hostname>/download, da der automatische Redirect des Hauptservers nun für das Dashboard-Feature verwendet wird.

HTTP-Server Authentifizierung

Standardmäßig benötigt der WinCC OA HTTP Server eine Authentifizierung bevor eine Verbindung hergestellt wird. Dieses Verhalten kann durch Setzen des Config-Eintrags [webClient] clientSideAuthauf 1 deaktiviert werden.

[webClient]
clientSideAuth = 1

Authentifizierungs-Token

Als Alternative zum Login mit Benutzerdaten kann auch ein Login mittels eines temporären Authentifizierungs-Tokens durchgeführt werden. Eine Anleitung zum Erstellen des Tokens finden Sie in Anmeldung mittels Authentifizierungs-Token.

  • Die Benutzungsdauer des Authentifizierungs-Tokens kann mit dem Config-Eintrag [wssServer] tokenExpire konfiguriert werden. Standardmäßig ist ein Token für 10 Minuten valide.
  • Für zusätzliche Sicherheit kann das Token so konfiguriert werden, dass es nach einer bestimmten Zeit vom Server widerrufen wird, auch wenn die Verbindung noch besteht. Dieses Verhalten ist standardmäßig deaktiviert, kann aber durch Setzen des Zeitlimits mit dem Config-Eintrag [wssServer] tokenExpireWarning aktiviert werden, nach welchem die Verbindung zwangsweise beendet wird. Der Benutzer erhält eine Warnung im Dashboard, bevor das Zeitlimit abgelaufen ist.
    Abbildung 2. Warnung zum Ablauf der Session

Verbindungs-Heartbeat

Das Dashboard verwendet einen Heartbeat, um die Aufrechterhaltung der Verbindung zwischen Server und Client zu überprüfen.

Um eine stabilere Verbindung in langsameren oder instabilen Netzwerkumgebungen zu garantieren, kann das Intervall zwischen den gesendeten Heartbeats verändert werden.

Die Länge des Intervalls kann durch Setzen des Config-Eintrags [wssServer] heartbeatSeconds konfiguriert werden.

Shared Worker

Datenaktualisierungen im Dashboard werden über eine WebSocket-Verbindung an das WinCC OA-Backend gesendet. In der Standardeinstellung verbindet sich jeder Browser-Tab und jedes Fenster einzeln mit dem WinCC OA-Backend und benötigt daher jeweils eine eigene Dashboard-Lizenz, solange die Verbindung besteht.

Wenn der Config-Eintrag [wssServer]useSharedWorker auf "1" gesetzt wird, werden alle verbundenen Browser-Tabs Updates über eine einzige Socket-Verbindung abrufen. Dadurch werden die erforderlichen Dashboard-Lizenzen auf eine Lizenz pro Browser reduziert. Allerdings ist es in diesem Fall nicht mehr möglich, mit verschiedenen Benutzern gleichzeitig im selben Browserkontext angemeldet zu sein.

Wichtig:
Die Verwendung des Shared Workers benötigt ein sicheres Zertifikat, welches durch den Webbrowser akzeptiert wird.
Abbildung 3. Nicht sichere Verbindung (Chrome)
Abbildung 4. Sichere Verbindung (Chrome)

Projekt ohne Webserver

Sollte Ihr Projekt noch keinen Webserver beinhalten, so muss dieser manuell zu Ihrem Projekt hinzugefügt werden. Hierfür fügen Sie einen neuen CTRL-Manager mit folgendem Parameter hinzu:

webclient_http.ctl

Drosselung

In Chromium-basierten Browsern kann es zu intensiver Drosselung kommen z. B. bei Tabs, die seit einiger Zeit nicht besucht wurden, was reibungslose Aktualisierungen von Widgets verhindert. Dies kann verhindert werden, indem der Browser mit nachfolgendem Parameter gestartet wird.

--disable-background-timer-throttling.

Anpassungen über WinCC OA

Eigene Icons zur Verbesserung der Darstellung für Dashboards und Widgets können über den Ordner data/WebUI/icons hinzugefügt werden. Sie sind dann in der Dashboard-Icon-Auswahl verfügbar.

Eigene Widgets werden über den Ordner data/WebUI/widgets hinzugefügt.

Migration auf neue Web Components Technologie

Die meisten bestehenden, auf Angular basierenden Dashboards können innerhalb der Web Components Dashboard Anwendung angezeigt werden. Hierbei können aus Kompatibilitätsgründen nicht alle Widgets oder spezifischen Einstellungen wie zuvor dargestellt werden. Insbesondere können auf Angular basierende, vom Benutzer erstellte Widgets nicht angezeigt werden.

Diese Angular basierenden Dashboards können als Web Component Dashboard gespeichert werden. Wenn das auf Angular basierende Dashboard geändert und gespeichert wird, erscheint ein Dialog zum Bestätigen der Änderung. Nach Bestätigung wird es als Web Component Dashboard gespeichert. Diese Änderung ist einmalig und unumkehrbar.

Die neue Indexseite, die dem Verzeichnis /data/dashboard hinzugefügt wurde, stellt sicher, dass Links von /data/dashboard/index.html stattdessen auf das Web Component Dashboard unter /data/dashboard-wc/index.html umgeleitet werden.

Hohe Verfügbarkeit

Das Dashboard kann auch in einem redundanten System mit mehreren Backends verwendet werden, um die Verfügbarkeit zu erhöhen. Für einen nahtlosen Übergang wird ein Service Worker eingesetzt. Er stellt sicher, dass die HTTP-Verbindung zusammen mit der WebSocket-Verbindung umgeschaltet wird.

Die Einrichtung der Hohen Verfügbarkeit erfordert die Konfiguration gültiger [httpServer] loadBalance Config-Einträge für jede zu verwendende Domain sowie gültiger [httpServer] accessControlAllowOriginConfig-Einträge, um CORS-Anfragen für jede Domain zu ermöglichen. Danach müssen die folgenden Header mit [httpServer] httpHeader für Anmeldeinformationen sowie erlaubte Methoden, Header und den Geltungsbereich des Service Workers angegeben werden:

[httpServer]
httpHeader = "Access-Control-Allow-Credentials: true"
httpHeader = "Access-Control-Allow-Methods: GET,OPTIONS,POST"
httpHeader = "Access-Control-Allow-Headers: authorization, Access-Control-Allow-Headers, Origin, Accept, Content-Type, Access-Control-Request-Method, Access-Control-Request-Headers, Upgrade-Insecure-Requests"
httpHeader = "Service-Worker-Allowed: /"

Eine Konfiguration könnte zum Beispiel wie folgt aussehen:

[httpServer]
# Load-Balancing-Einstellungen mit verschiedenen Domains
loadBalance = "md2t47dc max=5 exts=domain1:7443"
loadBalance = "md2t47dc max=5 exts=domain2:8443"

# Erlaube CORS-Anfragen der Domains
accessControlAllowOrigin = "https://domain1:7443"
accessControlAllowOrigin = "https://domain2:8443"

# Zusätzliche Header in CORS-Anfragen erlauben
httpHeader = "Access-Control-Allow-Credentials: true"
httpHeader = "Access-Control-Allow-Methods: GET,OPTIONS,POST"
httpHeader = "Access-Control-Allow-Headers: authorization, Access-Control-Allow-Headers, Origin, Accept, Content-Type, Access-Control-Request-Method, Access-Control-Request-Headers, Upgrade-Insecure-Requests"
httpHeader = "Service-Worker-Allowed: /"
WARNUNG:
Die [httpServer] httpHeader Config-Einträge müssen gesetzt werden, da andernfalls der Service Worker in einen "unresponsive state" versetzt wird.

Bei Verwendung der Hohen Verfügbarkeit erscheint folgendes Popup nach der Anmeldung in der Dashboard-Anwendung um anzuzeigen, dass eine Verbindung zum regulären HTTP-Server aufgebaut wurde:

Bei der Umschaltung der Verbindung auf einen alternativen HTTP-Server erscheint folgendes Benachrichtigungs-Popup:

Die Nutzung von Hoher Verfügbarkeit erfordert ein HTTP-Zertifikat, das vom Webbrowser ausnahmslos als vertrauenswürdig eingestuft wird. Weiters wird vorausgesetzt das alle Hosts vom Client erreicht werden können, genauere Informationen dazu befinden sich in den Kapiteln Redundanz und Redundante Netzwerkverbindungen

Es muss berücksichtigt werden, das der Cache-Control-Header negativen Einfluss auf die Service Worker-Routinen haben kann. Daher sollte der Cache-Control-Header bei Verwendetem Service Worker entfernt oder auf no-cachegesetzt werden. Wird der Service Worker nicht verwendet, kann der Cache-Control-Header frei verwendet werden.