Client/Server-Anwendungen (nur SCADA)¶

Allgemeiner Hinweis¶

PROCON-WEB ist vom Aufbau grundsätzlich ein Client-Server-System. Für klassische Einzelplatzanwendungen mit zusätzlichen Oberflächen z.B. für Smartphones ist dabei wenig bzgl. Client-Server-Anwendungen zu beachten. Anders ist das im Falle von komplexen SCADA (Leittechnik) Anwendungen, weil gleichzeitig mehrere Clients aktiv sind und Daten beeinflussen können. Zudem sollen evtl. ‚lokale‘ Rechte für bestimmte Bedienaktionen beachtet werden. Hierzu wurden diverse Erweiterungen in das System aufgenommen, die bei einer Projektierung berücksichtigt werden sollten. Dazu gehören:

Globale und lokale Tags (siehe Prozessankopplung – Erstellen von Prozessvariablen)
Bereichszuordnung in der Störungsverarbeitung
Dedizierte und Nicht-Dedizierte Clients (Konfiguration – Netzwerk)
Bereiche (Konfiguration – Bereiche)

Innerhalb eines lokalen Systems sind bzgl. der Übertragung zwischen Server und Client meist keine sicherheitsrelevanten Betrachtungen anzustellen. Dies ist bei komplexen Anwendungen, die auch netzwerkübergreifend sein können, anders. Hierzu gibt es die Möglichkeit verschlüsselte Übertragungen anzulegen.

Anpassungen am Projekt¶

Netzwerkkonfiguration¶

Die Netzwerkkonfiguration stellt das Abbild der PROCON-WEB Client/Server Netzwerkstruktur dar.

Abb: Beispiel Maschinennetzwerk Die vorherige Abbildung zeigt folgendes Beispiel:

Die dedizierten Clients 1-3 sind dem Bereich A zugeordnet
Der dedizierte Clients 4 ist dem Bereich B zugeordnet
Der dedizierte Clients 5 ist dem Bereich C zugeordnet
Darüber hinaus gibt es die nicht-dedizierten Clients 6 und 7

Ergebnis: Für die Clients 1-7 werden Lizenzen an die konkreten Geräte gebunden und können nicht von anderen Teilnehmern übernommen werden

Zwei weitere Clients werden dynamisch vergeben

Es können Beschränkungen bzgl. Bedienung oder Störungsverarbeitung, für die den Bereichen zugeordneten Clients vergeben werden (z.B. nur Client 1-3 sieht die Störungen aus dem Bereich A und kann dort kritische Sollwerte verändern, Client 4-7 darf das nicht)

Die Netzwerkkonfiguration wird über Konfiguration Netzwerk im Projektbaum aufgerufen.

Im linken Teil werden die, für das Projekt benötigten, Serverkomponenten aktiviert oder deaktiviert. Je nach Projektierung kann es sein, dass nicht alle Serverkomponenten benötigt werden. :::{important} WebServer, TagServer, AlertServer, SkriptServer und DataServer sollten in jedem Projekt vorhanden sein. ::: :::{note} Für den OPC UA-Server wird eine zusätzliche Lizenz benötigt. ::: Je nach Anwendungsfall kann es nötig sein mehrere Clients auf einem Rechner starten zu wollen. Damit der WebServer diese Clients unterscheiden kann, müssen diese mit einer zusätzlichen Option in der URL gestartet werden. Diese Option besteht aus „?client=“ und der Nummer des Clients.

BEISPIEL:
http://192.168.10.20?client=1/

Localhost erlauben: Durch diese Option kann man auf einfache Art und Weise ein Quasi-Einzelplatz-System konfigurieren.

Nicht dedizierte Teilnehmer bei unbekannter Gerätekennung automatisch neu zuordnen‘: Durch diese Option wird der nicht dedizierte Teilnehmer bei unbekannter Gerätekennung automatisch neu zugeordnet.

Anzahl nicht dedizierte Teilnehmer: Bestimmt die Anzahl der nicht dedizierten Teilnehmer im Projekt.

Teilnehmer Durch diese Liste auf der rechten Seite werden die Anzahl und die Namen der dedizierten (= namentlich bekannte) Clients bestimmt.

Über ein Teachen in der Webruntime wird das Endgerät als dedizierter Client namentlich bekannt gemacht. Dieser Vorgang muss nur einmalig für ein Gerät vorgenommen werden und wird für alle folgenden Anmeldungen gemerkt.

Das Teachen geschieht entweder automatisch, wenn die Anzahl der nicht-dedizierten Clients überschritten wurde, oder manuell über den Aufruf der Sonderfunktion 431, z.B. über einen Button.

Dies sollte jedoch nur über eine Admin-Berechtigung erfolgen und im Anschluss sollte sich der Benutzer selbst am Gerät anmelden. Aus diesem Grund, wird nach dem Teach-In Vorgang der aktive Benutzer automatisch abgemeldet.

Über den Button „Trennen“ kann eine bestehende Verknüpfung zwischen Gerät und Client aufgehoben werden, um z.B. einen dedizierten Client die Anmeldung zu ermöglichen, wenn die Höchstgrenze der dedizierten Clients erreicht ist.

Die Funktion löscht jedoch nur die Zuweisung. Der Client selbst wird nicht vom System kommunikationstechnisch abgetrennt.

Important

Cookies müssen im Browser zugelassen sein, damit der zugewiesene Client auch bei Neustart noch bekannt ist. Ebenso darf der Browserverlauf nicht gelöscht werden, da sonst ebenfalls die Zuweisung verloren geht.

Prozessvariablen¶

Prozessvariablen können entweder global oder lokal definiert sein.

Eine globale Definition bedeutet, dass die Prozessvariable über das gesamte System hinweg bekannt ist und den gleichen Wert hat. Wird der Wert in einem Client geändert, ist die Änderung an allen Clients sichtbar.

Eine lokale Definition bedeutet, dass jeder Client seine eigene Variable dieses Typs hat. Wird der Wert in einem Client geändert, ist die Änderung nur an diesem Client sichtbar.

Beispiel: Wenn Daten, die in einem Rezept verwaltet werden sollen von mehreren Teilnehmern gleichzeitig verändert werden sollen, so sind diese als lokale Variable anzulegen.

Note

Eine Variable mit Treiber-Ankopplung ist immer global definiert.

Important

Eine Variable, die im Skript verwendet wird, sollte global definiert sein. Ansonsten sind die Werte-Änderungen nicht im Client sichtbar.

Alarme und Meldungen¶

Alarme und Meldungen werden vom Alert-Server verwaltet. Für jeden Alarm muss in der Alarmdefinition die Spalte „Bereich“ ausgefüllt werden. Hier muss festgelegt werden, in welchem Bereich der Alarm angezeigt werden soll.

Ein Alarm kann den Bereichen „Lokal“, „Global“ und einem „benutzerdefinierten Bereich“ zugewiesen werden. Jeder Alarm wird beim Auslösen mit dem PC Namen im AlertServer eingetragen. Ist der Alarm dem Bereich „Lokal“ zugeordnet, so kann er nur auf dem Viewer des entsprechenden Rechners gesehen bzw. quittiert werden. Ist der Alarm dem Bereich „Global“ (= Standard) zugeordnet, so wird er unabhängig von seinem Auslöserechner auf allen Viewern des Netzwerkes dargestellt. Gehört der Alarm zu einem „benutzerdefinierten Bereich“, so kann der Alarm auf allen Rechnern dieses Bereiches angezeigt und quittiert werden.

Im Baum unter Konfiguration -> Bereiche können die Bereiche definiert werden.

Important

Werden Alarme über Prozessvariablen ausgelöst, so sind diese als ProzessVariablen des Globalen Servers zu definieren.

Note

Weitere Informationen sind in der Designer Dokumentation oder der OnlineHelp zu finden.

Aufbau des PROCON-WEB Server (SCADA)¶

Der PROCON-WEB Server führt den Datenaustausch mit der/den Steuerungssystemen (dem Prozess) durch und ist für die zentrale Verwaltung von Daten (Rezepten, Logs, …) zuständig. Er bedient die Clients mit den für den Bildaufbau notwendigen Daten, ohne allerdings die Bilder oder deren Inhalte zu kennen.

Über den Designer werden Bilddaten als Webdateien erzeugt und dem WebServer zur Auslieferung an den Client übergeben. Zusätzliche Konfigurationsdateien sollen den verschiedenen Servermodulen (Diensten) deren Aufgaben beschreiben. Jedes Modul ist für eine andere Aufgabe zuständig und die konkrete Konstellation an Modulen (Services) kann anwendungsspezifisch angepasst werden.

SystemServer¶

SystemServer-Console¶

Über die SystemServer-Console erhält man einen Einblick über die für das Projekt konfigurierten bzw. benötigten Server.

Die SystemServer Console bietet folgende Funktionen:
Anzeigen aller vom SystemServer verwalteter Server und deren Informationen (z.B. aktueller Status)
Anzeigen aller am SystemServer angemeldeten Clients und deren Informationen
Steuerung der Server (z.B. Start, Stopp)
Steuerung des PROCON-WEB Systems (Shutdown, Reboot)
Steuerung der aktiven Clients
Anzeige welche Clients sich mit einem Server verbunden haben
Interaktive Projektumschaltung/Projektaktualisierung
Anzeige der Logfiles der Server

Systemübersicht in der SystemServer-Console: Die SystemServer Console teilt sich in zwei Fensterteile auf. Im linken Teil ist das Abbild der Netzwerkkonfiguration mit den Serverkomponenten und den Clients in einer Baumstruktur dargestellt. Im rechten Teil können, falls verfügbar, weiterführende Informationen abgerufen werden.

Server-Stati: Die SystemServer Console zeigt im Baum links bildlich den Status der einzelnen Server mit einem entsprechenden Icon an. In der folgenden Tabelle sind die dargestellten Icons für den Systemstatus der einzelnen Server am Beispiel des AlertServer aufgeführt und beschrieben. Das folgende Schaubild verdeutlicht den Aufbau des WebClient und seine Kommunikation zu den Serverkomponenten.

Server	Status
	Aktiv
	In Pause
	Inaktiv
	Status unbekannt
	Projektupdate
	Statuswechsel
	Undefinierter Zustand
	Aktiv, kann aber nicht mit abhängigem Server kommunizieren

Client-Stati Die SystemServer Console zeigt im Baum links bildlich den Status der einzelnen Clients mit einem entsprechenden Icon an. In der folgenden Tabelle sind die dargestellten Icons für den Systemstatus der einzelnen Clients aufgeführt und beschrieben.

Client	Status
	Dedizierter Client (geteached) / localhost inaktiv
	Dedizierter Client (geteached) / localhost aktiv
	Dedizierter Client (nicht geteached) inaktiv
	Nicht-Dedizierter Client inaktiv
	Nicht-Dedizierter Client aktiv

Über das Menü der SystemServer-Console gibt es die Möglichkeit weitere Diagnostik vorzunehmen.

Unter dem Menüpunkt „System“ sind die folgenden Untermenüpunkte verfügbar.

Menüpunkt	Bedeutung
Exit	Verlassen der Konsole
Reboot	Neustarten des SystemServerdienstes

Über den Punkt „Operating“ sind diese Untermenüpunkte verfügbar:

Menüpunkt	Bedeutung
Startup server system	Start des Systemservers
Server system in Pause	Anhalten des Systemservers
Shut down server system	Herunterfahren des Systemservers

Unter dem Menüpunkt „Diagnostic“ sind die folgenden Untermenüpunkte verfügbar.

Menüpunkt	Bedeutung
TagServer console	Aufruf der TagServer Console
Start System	Muss als Administrator ausgeführt werden. Startet die Laufzeit
Stop System	Muss als Administrator ausgeführt werden. Beendet die Laufzeit
Kill System	Muss als Administrator ausgeführt werden. Bricht die Laufzeit ab

Unter dem Menüpunkt „Configuration“ sind die folgenden Untermenüpunkte verfügbar.

Menüpunkt	Bedeutung
Console	Unter diesem Punkt können Einstellungen für die SystemServer Console vorgenommen werden. Hier wird die Refresh-Rate der SystemServer Console eingetragen.
Runtime Database	Verwaltung der Datenbanken möglich
	Datenbanken können gelöscht, aus einem Backup wiederhergestellt werden. Ebenfalls kann ein Backup angestoßen werden (Ausgewählte Datenbank kann als .bak Datei in einem auswählbaren Verzeichnis gespeichert werden)

Unter dem Menüpunkt „Help“ sind die folgenden Untermenüpunkte verfügbar.

Menüpunkt	Bedeutung
Help	Aufruf der Online-Hilfe für die SystemServerConsole
Info	Ruft das Info-Fenster der SystemServerConsole auf. Hier werden u.A. Deteils zur Lizenz angezeigt.

TagServer¶

TagServer-Console¶

Mit der TagServer Console kann der Variablenhaushalt im TagServer beobachtet oder gesteuert werden.

In folgender Tabelle sind die Spalten der Tag Liste aufgeführt:

Spalte	Beschreibung
Name	Tagname eventuell mit Feldindex
ID	Variablenindex aus Variablentabelle
NewID	Eindeutige ID über alle Variablen
Value	Aktueller Variablenwert
Access	Zugriffsart, R = Lesen (Read), W = Schreiben (Write)
Quality	Qualität der Variable (0 oder 1 = OK, siehe nächste Tabelle)
HiOut	Max. Wertebereichsüberschreitung
LoOut	Min. Wertebereichsüberschreitung
IsLocal	Konfiguration der Variable lokal oder global

In folgender Tabelle sind die Fehlernummern aus der Spalte „Quality“ der Tags aufgeführt:

Fehlernummer	Beschreibung
-12	Zugriff auf Treiber DLL oder abhängige DLL nicht möglich, Initialisierung Fehler
-11	Datenauftrag abgebrochen
-10	letzter externer Fehler (wird vom Kommunikationspartner gesendet)
-8	Floatfehler, Floatunterdrückung in Treiber-Ini-Datei einstellen
-7	falsches Floatformat
-6	erster externer Fehler (wird vom Kommunikationspartner gesendet)
-5	Parametrierfehler einer Variablendefinition
-4	Initialisierungsfehler des Treibers
-3	Speicherfehler im Treiber
-2	Übertragungsfehler der Kommunikation
-1	Timeoutfehler der Kommunikation
0	OK
1	wartet bis Variable aktualisiert wurde (Status bis zur erste Aktualisierung)

In folgender Tabelle sind die Buttons und Reiter beschrieben

Button / Reiter	Beschreibung
Connect	Verbindet die TagServer Console mit dem Tagserver
Disconnect	Trennt die TagServer Console mit dem Tagserver
New Session	TagServer Console öffnet eine neue, eigene Session zur Kommunikation mit dem TagServer
Use existing Session	TagServer Console benutzt eine vorhandene Session zur Kommunikation mit dem TagServer
Top	Springt an den Anfang der gewählten Liste
Next	Springt weiter in der gewählten Liste
Previous	Springt zurück in der gewählten Liste
Botton	Springt an das Ende der gewählten Liste
Boolean Tags	Liste der logischen Variablen
Numeric Tags	Liste der numerischen Variablen
String Tags	Liste der Textvariablen

Im Menü Watchlist > Save Watchlist Tags wird die aktuell angezeigte Liste der Tags als CSV-Datei gespeichert. Diese kann zu Diagnosezwecken genutzt werden.

Beenden bestehender Verbindungen: Im Menü Connection->Sessions gibt es einen neuen Unterpunkt jede Session mit der Bedeutung „CloseSession“:

Über diesen Menüeintrag kann eine bestehende Verbindung zum TagServer hart beendet werden. Dies muss zur Sicherheit nochmal über einen Dialog bestätigt werden:

Anschließend wird die Verbindung dieser Session zum TagServer hart beendet und der TagServer räumt alle zur Verbindung gehörenden Datenstrukturen auf, z.B. löscht alle lokalen Variablenwerte.

Was der betroffene Client an der Stelle tut, ist vom Client abhängig, die meisten Clients werden versuchen, die Verbindung im Anschluss neu aufzubauen.

Mithilfe der Funktion „Nur referenzierte Variablen anzeigen“ im Menüpunkt „Configuration“ werden alle Tags mit Status „not registered“ herausgefiltert.

Somit wird die Tag-Liste übersichtlicher da nur die im aktuellen Bild eingebundenen Variablen angezeigt werden. Neben der SystemServer-Console und der TagServer-Console gibt es noch weitere Server, die über deren Config-Dateien auch teilweise administrierbar sind. Auch diese Komponenten sind elementare Bestandteile des gesamten Laufzeitsystems.

Die nachfolgenden Kapitel erläutern die Dienste im Detail.

Über das Dropdown Menü rechts können vorhandene Verbindungen oder Watchlisten aufgerufen werden.

In Vorbereitung auf den Umbau der Konsolen hin zu einer einheitlichen SystemServerState Seite, wird ab der Version 6.9 noch ein Eintrag „System“ aufgeführt. Dieser hat aktuell noch keine Bedeutung. Bei Auswahl werden alle Tags als „not registered“ in rot dargestellt, ohne, dass dies eine Auswirkung hat.

WebServer¶

Der PROCON-WEB-WebServer dient als zentrale Schnittstelle zwischen den Server-Komponenten und der WebVisu. Er sorgt dafür, dass die erzeugten Dateien für einen Internetbrowser zur Verfügung gestellt werden.

Der WebServer des Betriebssystems (kann auch durch PROCON-WERB mitinstalliert werden) übergibt die Webanwendung an den Client mit den für den Bildaufbau benötigten Dateien (*.js, *.htm, *.css). Der PROCON-WEB-WebServer ist als Dienst realisiert.

Er hat folgende Aufgaben:

Entgegennehmen von Anforderungen (Requests) der WebVisu und Weiterleitung an die entsprechenden Server
Entgegennehmen der Server-Antwort und Weiterleitung an die WebVisu
Session-Handling der Clients

Um diese Aufgaben zu erfüllen, kommuniziert der WebServer allen anderen Servern.

PROCON-WEB_WebServer.exe.config Die Datei „PROCON-WEB_WebServer.exe.config“ dient der Konfiguration des WebServer-Dienstes und ist im Verzeichnis „:raw-latex:PROCON`-WEB:raw-latex:Runtime“ zu finden. Diese wird bei der Installation über das Setup automatisch angepasst. Änderungen sind nur im Einzelfall vorzunehmen!

Es sind hier nur die wichtigen Einträge beschrieben.

<serviceconfig>

Parameter	Beschreibung	Default
ServiceName	Name des SystemServer-Dienst	PROCON-WEB Web Server
ServiceDebug		false
UseSystemServer	Steuerung des Dienstes erfolgt über SystemServer	true
Dependencies	Abhängigkeiten von anderen Diensten
DependentService name	Dienstname (Der angegeben Dienst wird bei der Dienst-Installation als Abhängigkeit eingetragen)

<log4net>

Parameter	Beschreibung	Default
level	Loglevel für Systemserver: Default Ringprotokoll über 10 Dateien.

Erlaubte Levels in aufsteigender Reihenfolge:

OFF
Fatal
Error
Warn
Info
Debug
Error

<appSettings>

Parameter	Beschreibung	Default
WebSocketAddress	Standard Adresse und Port des WebSockets	ws://0.0.0.0:16825/
WebSocketAddressSecure	Standard Adresse und Port des sicheren WebSockets	wss://0.0.0.0:17825/
WebServer1Address	Standard Port des Webservers für http	`http://\*:80/`
WebServer2Address	Ausweich Port des Webservers für http	`http://\*:16700/`

<system.serviceModel>

In diesem Abschnitt wird die Kommunikation der Server untereinander konfiguriert.

Important

Dieser Abschnitt darf nicht verändert werden!

SystemServer allgemein¶

Der SystemServer ist im PROCON-WEB Client/Server System die zentrale Komponente. Er koordiniert alle anderen Server und sorgt für ein geordnetes Hoch- und Herunterfahren eines Projektes. Zudem bietet er über die SystemServer-Konsole diverse Diagnosefunktionen an. Über die SystemServer-Konsole kann administrativ Einfluss auf das System genommen werden. Der SystemServer ist als Dienst realisiert. Der SystemServer bietet folgende Funktionen/Komponenten:

zentrale Client/Serverüberwachung und -Steuerung

zentrales Konfigurationsmanagement für die Clients und Server

zentrale Abfrage von Protokollen (Diagnose)

zentrales Lizenzmanagement

zentrale Stelle für Softwareupdates

zentrale Versionsinformation

zentrales vereinfachtes Terminal Server Management

PROCON-WEB_SystemServer.exe.config Die Datei „PROCON-WEB_SystemServer.exe.config“ dient der Konfiguration des SystemServer-Dienstes und ist im Verzeichnis „PROCON-WEBRuntime“ zu finden. Diese wird bei der Installation über das Setup automatisch angepasst. Es sind hier nur die wichtigen Einträge beschrieben.

<log4net>

Parameter	Beschreibung	Default
level	Loglevel für Systemserver, Default Ringprotokoll über 10 Dateien. Erlaubte Levels in aufsteigender Reihenfolge: OFF, Fatal, Error, Warn, Info, Debug	Error

<ServiceConfig>

Parameter	Beschreibung	Default
ServiceName	Name des SystemServer-Dienst	PROCON-WEB System Server
ServiceDebug		false
Dependencies	Abhängigkeiten von anderen Diensten
DependentService name	Dienstname (Der angegeben Dienst wird bei der Dienst-Installation als Abhängigkeit eingetragen)

<ReplicationConfiguration>

Parameter	Beschreibung	Default
User	SQL-Benutzer für Replikation im Redundanten Client/Server System
Password	Passwort des SQL-Benutzer für Replikation im Redundanten Client/Server System
Frequency_Master	Frequenz in Sekunden für Replikation der Datenbank GTIM	0
Frequency_Project	Frequenz in Sekunden für Replikation der Datenbank GTIP	0
Frequency_Runtime	Frequenz in Sekunden für Replikation der Datenbank GTIR	0
MergeTimeout	Timeout für zusammenführen der Datenbanken in Sekunden	0
SnapshotTimeout	Timeout für Erstellung von Snapschots der Datenbanken in Sekunden	0
RunTimeout	Timeout für Ausführung der Replikation in Sekunden	0
ConnectionTimeout	Timeout für Verbindungsaufbau der Replikation in Sekunden	0
Additionallist	Hier können zusätzliche Datenbanken für die Replikation angegeben werden mit frei wählbarer Frequenz in Sekunden	!–<Additional Database=“MMM“ Frequency=“55“/>–>

<system.serviceModel>

In diesem Abschnitt wird die Kommunikation der Server untereinander konfiguriert.

Important

Dieser Abschnitt darf nicht verändert werden!

TagServer allgemein¶

Der TagServer realisiert die Anbindung an die Steuerungskomponenten. Er kann, neben den bekannten spezifischen PROCON-WEB Treibern, auch mehrere OPC-Server bedienen. Der TagServer ist als Dienst realisiert.

AlertServer¶

Der AlertServer dient der zentralen Anbindung an die Datenbank für die Speicherung von Alarmen und dem AuditTrail. Als Datenbank wird über das Setup standardmäßig ein Microsoft SQL ServerExpress 2012/2016 installiert. Bei komplexeren Anwendungen kann auch ein vollwertiger Microsoft SQL Server eingesetzt werden. Der AlertServer ist als Dienst realisiert.

Er hat folgende Aufgaben:

Zentrale Handhabung aller Alarme in einem Client/Server-Visualisierungsprojekt

Verarbeitung von Alarmen mit lokaler und globaler Auslösung

Verwaltung des Alarmzustandes aller Client-Systeme

Verwaltung des Alarmprotokolls aller Client-Systeme

Verteilung der Alarmboxen an alle Client-Systeme (Anzeige der Alarmboxen)

Zentrale Handhabung der Logbucheinträge (AuditTrail)

Um diese Aufgaben zu erfüllen, kommuniziert der AlertServer mit dem TagServer und den WebServer.

PROCON-WEB_AlertServer.exe.config Die Konfigurationsdatei „PROCON-WEB_AlertServer.exe.config“ dient der Konfiguration des AlerServer-Dienstes und ist im Verzeichnis „PROCON-WEBRuntime“ zu finden. Diese wird bei der Installation über das Setup automatisch angepasst.

Es sind hier nur die wichtigen Einträge beschrieben.

<log4net>

Parameter	Beschreibung	Default
level	Loglevel für Systemserver, Default Ringprotokoll über 10 Dateien. Erlaubte Levels in aufsteigender Reihenfolge: OFF, Fatal, Error, Warn, Info, Debug	Error

<ServiceConfig>

Parameter	Beschreibung	Default
ServiceName	Name des SystemServer-Dienst	PROCON-WEB Alert Server
ServiceDebug		false
UseSystemServer	Steuerung des Dienstes erfolgt über SystemServer	true
Dependencies	Abhängigkeiten von anderen Diensten
DependentService name	Dienstname (Der angegeben Dienst wird bei der Dienst-Installation als Abhängigkeit eingetragen)

<system.serviceModel>

In diesem Abschnitt wird die Kommunikation der Server untereinander konfiguriert.

Important

Dieser Abschnitt darf nicht verändert werden!

Important

Die Konfiguration der Alarm-Datenbank und weiterer Parameter des AlertServers geschieht durch die ServerConfig.xml

DataServer¶

Der DataServer dient der zentralen Anbindung an die Datenbank für die Aufzeichnung von Daten bzw. Verwaltung von Datenbanken, Rezepten und Aufträgen. Als Datenbank wird über das Setup standardmäßig ein Microsoft SQL ServerExpress 2012/2016 installiert. Bei komplexeren Anwendungen kann auch ein vollwertiger Microsoft SQL Server eingesetzt werden. Der DataServer ist als Dienst realisiert.

Er hat folgende Aufgaben:

Zentrale Datenaufzeichnung der Datenlogger

Verwaltung von Datenbanken, Rezepten und Aufträgen

Bereitstellung einer ODBC-Schnittstelle

Um diese Aufgaben zu erfüllen, kommuniziert der DataServer mit dem TagServer und den WebServer.

PROCON-WEB_DataServer.exe.config Die Konfigurationsdatei „PROCON-WEB_DataServer.exe.config“ dient der Konfiguration des DataServer-Dienstes und ist im Verzeichnis „PROCON-WEBRuntime“ zu finden. Diese wird bei der Installation über das Setup automatisch angepasst.

<log4net>

Parameter	Beschreibung	Default
level	Loglevel für Systemserver, Default Ringprotokoll über 10 Dateien. Erlaubte Levels in aufsteigender Reihenfolge: OFF, Fatal, Error, Warn, Info, Debug	Error

<ServiceConfig>

Parameter	Beschreibung	Default
ServiceName	Name des SystemServer-Dienst	PROCON-WEB Data Server
ServiceDebug		false
UseSystemServer	Steuerung des Dienstes erfolgt über SystemServer	true
Dependencies	Abhängigkeiten von anderen Diensten
DependentService name	Dienstname (Der angegeben Dienst wird bei der Dienst-Installation als Abhängigkeit eingetragen)

<system.serviceModel>

In diesem Abschnitt wird die Kommunikation der Server untereinander konfiguriert.

Important

Dieser Abschnitt darf nicht verändert werden!

Important

Die Konfiguration der Datenablage-Datenbank und weiterer Parameter des DataServers geschieht durch die ServerConfig.xml

SkriptServer¶

Der SkriptServer dient zur zentralen Abarbeitung von Tasks und Skripte. Der SkriptServer ist als Dienst realisiert. Er hat folgende Aufgaben:

Zyklische Abarbeitung von Tasks

Eventgesteuerte Abarbeitung von Skripten

Um diese Aufgaben zu erfüllen, kommuniziert der SkriptServer mit dem TagServer, dem AlertServer, dem DataServer und dem WebServer.

PROCON-WEB_ScriptServer.exe.config Die Konfigurationsdatei „PROCON-WEB_ScriptServer.exe.config“ dient der Konfiguration des ScriptServer-Dienstes und ist im Verzeichnis „PROCON-WEBRuntime“ zu finden. Diese wird bei der Installation über das Setup automatisch angepasst. Es sind hier nur die wichtigen Einträge beschrieben.

<log4net>

Parameter	Beschreibung	Default
level	Loglevel für Systemserver, Default Ringprotokoll über 10 Dateien. Erlaubte Levels in aufsteigender Reihenfolge: OFF, Fatal, Error, Warn, Info, Debug	Error

<ServiceConfig>

Parameter	Beschreibung	Default
ServiceName	Name des SystemServer-Dienst	PROCON-WEB Script Server
ServiceDebug		false
UseSystemServer	Steuerung des Dienstes erfolgt über SystemServer	true
Dependencies	Abhängigkeiten von anderen Diensten
DependentService name	Dienstname (Der angegeben Dienst wird bei der Dienst-Installation als Abhängigkeit eingetragen)

<system.serviceModel>

In diesem Abschnitt wird die Kommunikation der Server untereinander konfiguriert.

Important

Dieser Abschnitt darf nicht verändert werden!

UserServer¶

Der UserServer dient der zentralen Anbindung an die Datenbank für die Benutzerverwaltung im PROCON-WEB. Als Datenbank wird über das Setup standardmäßig ein Microsoft SQL ServerExpress 2012/2016 installiert. Bei komplexeren Anwendungen kann auch ein vollwertiger Microsoft SQL Server eingesetzt werden. Der UserServer ist als Dienst realisiert.

Er hat folgende Aufgaben:

Verifikation von Benutzern, Gruppen und Rechten

Ändern, Hinzufügen, Löschen von Benutzern

Ändern, Hinzufügen, Löschen von Gruppen

Um diese Aufgaben zu erfüllen, kommuniziert der UserServer mit dem WebServer.

PROCON-WEB_UserServer.exe.config Die Datei „PROCON-WEB_UserServer.exe.config“ dient der Konfiguration des UserServer-Dienstes und ist im Verzeichnis „PROCON-WEBRuntime“ zu finden. Diese wird bei der Installation über das Setup automatisch angepasst.

Es sind hier nur die wichtigen Einträge beschrieben.

<log4net>

Parameter	Beschreibung	Default
level	Loglevel für Systemserver, Default Ringprotokoll über 10 Dateien. Erlaubte Levels in aufsteigender Reihenfolge: OFF, Fatal, Error, Warn, Info, Debug	Error

<ServiceConfig>

Parameter	Beschreibung	Default
ServiceName	Name des SystemServer-Dienst	PROCON-WEB User Server
ServiceDebug		false
UseSystemServer	Steuerung des Dienstes erfolgt über SystemServer	true

<system.serviceModel>

In diesem Abschnitt wird die Kommunikation der Server untereinander konfiguriert.

Important

Dieser Abschnitt darf nicht verändert werden!

HelpServer¶

Der HelpServer dient der zentralen Anbindung an die Datenbank zur Verwaltung der Hilfethemen. Als Datenbank wird über das Setup standardmäßig ein Microsoft SQL ServerExpress 2017 installiert. Bei komplexeren Anwendungen kann auch ein vollwertiger Microsoft SQL Server eingesetzt werden. Der HelpServer ist als Dienst realisiert.

Er hat folgende Aufgaben:

Verwaltung der Hilfethemen

Ändern, Hinzufügen, Löschen von Hilfeeinträgen

Um diese Aufgaben zu erfüllen, kommuniziert der HelpServer mit dem WebServer.

PROCON-WEB_HelpServer.exe.config Die Datei „PROCON-WEB_HelpServer.exe.config“ dient der Konfiguration des HelpServer-Dienstes und ist im Verzeichnis „PROCON-WEBRuntime“ zu finden. Diese wird bei der Installation über das Setup automatisch angepasst.

Es sind hier nur die wichtigen Einträge beschrieben.

<log4net>

Parameter	Beschreibung	Default
level	Loglevel für Systemserver, Default Ringprotokoll über 10 Dateien. Erlaubte Levels in aufsteigender Reihenfolge: OFF, Fatal, Error, Warn, Info, Debug	Error

<ServiceConfig>

Parameter	Beschreibung	Default
ServiceName	Name des SystemServer-Dienst	PROCON-WEB Help Server
ServiceDebug		false
UseSystemServer	Steuerung des Dienstes erfolgt über SystemServer	true

<system.serviceModel>

In diesem Abschnitt wird die Kommunikation der Server untereinander konfiguriert.

Important

Dieser Abschnitt darf nicht verändert werden!

Important

Die Konfiguration der Datenablage-Datenbank und weiterer Parameter des DataServers geschieht durch die ServerConfig.xml

ReportServer¶

Der ReportServer dient zur Anzeige vorkonfigurierter CrystalReports-Reporte in der Weboberfläche als HTML-Seite. Zudem kann der ReportServer aus den Reports ein PDF generieren. Der ReportServer ist als Dienst realisiert.

Er hat folgende Aufgaben:

Verwaltung der Reports und Anzeige als HTML-Seite

Export der Reports als PDF

PROCON-WEB_ReportServer.exe.config Die Datei „PROCON-WEB_ReportServer.exe.config“ dient der Konfiguration des ReportServer-Dienstes und ist im Verzeichnis „PROCON-WEBRuntime“ zu finden. Diese wird bei der Installation über das Setup automatisch angepasst.

Es sind hier nur die wichtigen Einträge beschrieben.

<log4net>

Parameter	Beschreibung	Default
level	Loglevel für Systemserver, Default Ringprotokoll über 10 Dateien. Erlaubte Levels in aufsteigender Reihenfolge: OFF, Fatal, Error, Warn, Info, Debug	Error

<ServiceConfig>

Parameter	Beschreibung	Default
ServiceName	Name des SystemServer-Dienst	PROCON-WEB Report Server
ServiceDebug		false
UseSystemServer	Steuerung des Dienstes erfolgt über SystemServer	true

<system.serviceModel>

In diesem Abschnitt wird die Kommunikation der Server untereinander konfiguriert.

Important

Dieser Abschnitt darf nicht verändert werden!

OPC UA-Server¶

PROCON-WEB kann für andere Komponenten auch als OPC UA-Server fungieren. Der OPC UA-Server stellt fest definierte Daten des PROCON-WEB-Systems nach außen zur Verfügung. Der OPC UA-Server ist als Dienst realisiert.

Er hat folgende Aufgaben:

Daten der PROCON-WEB-Systems als OPC-UA zur Verfügung zu stellen

PROCON-WEB_OpcServer.exe.config Die Datei „PROCON-WEB_OpcServer.exe.config“ dient der Konfiguration des OPC UA-Server-Dienstes und ist im Verzeichnis „PROCON-WEBRuntime“ zu finden. Diese wird bei der Installation über das Setup automatisch angepasst.

Es sind hier nur die wichtigen Einträge beschrieben.

<log4net>

Parameter	Beschreibung	Default
level	Loglevel für Systemserver, Default Ringprotokoll über 10 Dateien. Erlaubte Levels in aufsteigender Reihenfolge: OFF, Fatal, Error, Warn, Info, Debug	Error

<ServiceConfig>

Parameter	Beschreibung	Default
ServiceName	Name des SystemServer-Dienst	PROCON-WEB OPC UA Server
ServiceDebug		false
UseSystemServer	Steuerung des Dienstes erfolgt über SystemServer	true

<system.serviceModel>

In diesem Abschnitt wird die Kommunikation der Server untereinander konfiguriert.

Important

Dieser Abschnitt darf nicht verändert werden!

Important

Für den OPC UA-Server ist eine extra Lizenz der GTI erforderlich

Important

Der OPC UA-Server hat folgende URL: opc.tcp://localhost:16929/PROCON-WEB/OpcUaServer

Konfiguration OPC UA Server zur Laufzeit¶

Die Runtime-Konfiguration des OPC UA Servers kann aktuell nur manuell über ein XML-Konfigurationsfile vorgenommen werden (PROCON-WEB_OPCServer.Config.xml) Die meisten Einstellungen sollten auf ihren Standardeinstellungen belassen werden und sind für das zugrundeliegende OPC UA Toolkit von Softing relevant, auf dem der PROCON-WEB OPC UA Server basiert. Aktuell muss das Konfigurationsfile nur für die Zugriffssteuerung auf den OPC UA Server angepasst werden.

Authentifizierung des Clients¶

Zur Authentifizierung von Clients, die auf den OPC UA Server zugreifen können, wird mit Applikationszertifikaten gearbeitet. Das Einbinden von Zertifikaten ist hier im Kapitel weiter unten „Verschlüsselung für die Kommunikation zum Client“ beschrieben. Der OPC UA Server erzeugt beim ersten Start ein eigenes Zertifikat, das er zur Kommunikation mit Clients verwendet. Es wird abgelegt im Ordner: C:PROCON-WEBRuntimeOpcUaServerCertificateStoreown Standardmäßig ist der OPC UA Server so eingestellt, dass er allen Clients vertraut, egal welches Zertifikat der Client verwendet. Sollen nur bestimmte Clients verwendet werden, muss der folgende Eintrag im Config-File (PROCON-WEB_OPCServer.Config.xml) angepasst werden: `<AutoAcceptUntrustedCertificates>```false```</AutoAcceptUntrustedCertificates>` Dann lässt der OPC Server nur noch Verbindungen von Clients zu, deren Zeritifkat im Verzeichnis: C:PROCON-WEBRuntimeOpcUaServerCertificateStoretrustedcerts abgelegt ist. Wenn sich ein Client ohne akzeptiertes Zertifikat versucht anzumelden, wird dies vom OPC UA Server abgelehnt und das Zertifikat wird zur Verifizierung im Ordner C:PROCON-WEBRuntimeOpcUaServerCertificateStorerejectedcerts abgelegt. Von dort kann es vom Systemadministrator in den trusted Ordner verschoben werden um dem Client entsprechend Zugriff zu gewähren.

Gesicherte Datenübertragung¶

OPC UA bietet zum einen eine gesicherte Datenübertragung zwischen Server und Client. Im Konfigurationsfile können unterschiedliche Kommunikationsübertragungen ausgewählt werden: Die einzelnen Übertragungen sind in der offiziellen OPC UA Dokumentation zu finden: <https://profiles.opcfoundation.org/profilefolder/474> Standardmäßig sind alle Übertragungsmethoden aktiviert, der Client kann eine für ihn passende Kommunikation auswählen. In der Konfigurationsdatei sind als Referenz auch drei, inzwischen von der OPC Foundation als deprecated (veraltet) markierte Einträge vorhanden, die bereits auskommentiert sind. Diese dürfen aus Sicherheitsgründen NICHT MEHR aktiviert werden und dienen nur der Referenz.

<SecurityPolicies>
   <ServerSecurityPolicy>
      <SecurityMode>Sign_2</SecurityMode>
      <SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#Basic256Sha256</SecurityPolicyUri>
   </ServerSecurityPolicy>
   <ServerSecurityPolicy>
      <SecurityMode>None_1</SecurityMode>
      <SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#None</SecurityPolicyUri>
   </ServerSecurityPolicy>
   <ServerSecurityPolicy>
      <SecurityMode>SignAndEncrypt_3</SecurityMode>
      <SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#Basic256Sha256</SecurityPolicyUri>
   </ServerSecurityPolicy>
   <ServerSecurityPolicy>
      <SecurityMode>Sign_2</SecurityMode>
     <SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#Aes128_Sha256_RsaOaep</SecurityPolicyUri>
   </ServerSecurityPolicy>
   <ServerSecurityPolicy>
      <SecurityMode>SignAndEncrypt_3</SecurityMode>
      <SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#Aes128_Sha256_RsaOaep</SecurityPolicyUri>
   </ServerSecurityPolicy>
   <ServerSecurityPolicy>
      <SecurityMode>Sign_2</SecurityMode>
      <SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#Aes256_Sha256_RsaPss</SecurityPolicyUri>
   </ServerSecurityPolicy>
   <ServerSecurityPolicy>
      <SecurityMode>SignAndEncrypt_3</SecurityMode>
      <SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#Aes256_Sha256_RsaPss</SecurityPolicyUri>
   </ServerSecurityPolicy>
<!-- deprecated security policies for reference only>
  <ServerSecurityPolicy>
   <SecurityMode>Sign_2</SecurityMode>
   <SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#Basic256</SecurityPolicyUri>
  </ServerSecurityPolicy>
  <ServerSecurityPolicy>
   <SecurityMode>SignAndEncrypt_3</SecurityMode>
   <SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#Basic256</SecurityPolicyUri>
  </ServerSecurityPolicy>
  <ServerSecurityPolicy>
   <SecurityMode>Sign_2</SecurityMode>
   <SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#Basic128Rsa15</SecurityPolicyUri>
  </ServerSecurityPolicy>
  <ServerSecurityPolicy>
   <SecurityMode>SignAndEncrypt_3</SecurityMode>
   <SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#Basic128Rsa15</SecurityPolicyUri>
  </ServerSecurityPolicy>
-->
</SecurityPolicies>

Um eine Übertragungsmethode zu deaktivieren, muss die entsprechende Sektion <ServerSecurityPolicy> komplett auskommentiert werden, indem die Sektion in die Zeichenfolgen

 eingebettet wird:

Beispiel, bei der die unverschlüsselte Übertragung deaktiviert wurde:

Autorisierung des Clients¶

Zur Autorisierung von Clients, die auf den OPC UA Server zugreifen können, stehen drei Möglichkeiten zur Verfügung:

Anonym: Jeder Client im Netzwerk kann auf den OPC UA Server zugreifen, der Zugriffsschutz muss extern erfolgen
Benutzername / Passwort: Jeder Client muss sich mit einem Benutzernamen und Passwort authentifizieren. Aktuell erhält JEDER im Projekt angelegte Benutzer, der nicht deaktiviert ist Zugriff auf den OPC UA Server.
Zertifikat: Der Client muss ein vertrauenswürdiges User-Zertifikat besitzen, das dem OPC UA Server bekannt gemacht wird. Dafür muss das Zertifikat als Trusted User im Zertifikatstore des Rechners installiert werden!

Standardmäßig sind alle drei Autorisierungsmethoden aktiviert, der Client kann eine für ihn passende Autorisierung auswählen.

<!-- The SDK expects the server to support the same set of user tokens for every endpoint. -->
<UserTokenPolicies>
  <!-- Allows anonymous users -->
  <ua:UserTokenPolicy>
     <ua:TokenType>Anonymous_0</ua:TokenType>
     <ua:SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#None</ua:SecurityPolicyUri>
  </ua:UserTokenPolicy>

  <!-- Allows username/password -->
  <ua:UserTokenPolicy>
     <ua:TokenType>UserName_1</ua:TokenType>
     <!-- passwords must be encrypted - this specifies what algorithm to use -->
     <ua:SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#Basic256Sha256</ua:SecurityPolicyUri>
  </ua:UserTokenPolicy>

  <!-- Allows user certificates -->
  <ua:UserTokenPolicy>
     <ua:TokenType>Certificate_2</ua:TokenType>
     <!-- certificate possession must be proven with a digital signature - this specifies what algorithm to use -->
     <ua:SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#Basic256Sha256</ua:SecurityPolicyUri>
  </ua:UserTokenPolicy>
</UserTokenPolicies>

Um eine Authentifizierungsmethode zu deaktivieren. muss die entsprechende komplette Sektion <d3p1:UserTokenPolicy> auskommentiert werden, in dem die Sektion in die Zeichenfolgen

 eingebettet wird:

Beispiel bei der die anonyme Authentifizierungsmethode deaktiviert wurde:

<!-- The SDK expects the server to support the same set of user tokens for every endpoint. -->
<UserTokenPolicies>
<!--
  <!-- Allows anonymous users -->
   <ua:UserTokenPolicy>
      <ua:TokenType>Anonymous_0</ua:TokenType>
      <ua:SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#None</ua:SecurityPolicyUri>
   </ua:UserTokenPolicy>
-->
   <!-- Allows username/password -->
   <ua:UserTokenPolicy>
      <ua:TokenType>UserName_1</ua:TokenType>
      <!-- passwords must be encrypted - this specifies what algorithm to use -->
      <ua:SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#Basic256Sha256</ua:SecurityPolicyUri>
   </ua:UserTokenPolicy>

   <!-- Allows user certificates -->
   <ua:UserTokenPolicy>
      <ua:TokenType>Certificate_2</ua:TokenType>
      <!-- certificate possession must be proven with a digital signature - this specifies what algorithm to use -->
      <ua:SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#Basic256Sha256</ua:SecurityPolicyUri>
   </ua:UserTokenPolicy>
</UserTokenPolicies>

Installieren eines Trusted User Zeritifkats¶

Um als Benutzerauthentifizierung ein Zertifikat zu benutzen, muss dieses als Trusted User Zeritikat im Zertifikat-Store des Rechners installiert sein, auf dem der OPC UA Server läuft.

Durch einen Doppelklick auf das Zertifikat erhält man die Zertifikatsinformationen und kann dort durch den Button „Install Certificate“ das Zertifikat über einen Wizard installieren:

WCF-Portnummern der Server¶

Die zu PROCON-WEB gehörenden Server (SCADA-Variante) benutzen standardmäßig folgende Ports zur Kommunikation innerhalb der Windows-Anwendung:

	System Server	Tag- Server	Alert- Server	Data- Server	Skript- Server	Web- Server	Help- Server	User- Server	Report- Server	OPCUA- Server
Control- Session	16620	16621	16622	16623	16624	16625	16626	16627	16628	16629
Data- Session	16720	16721	16722	16723	16724	16725	16726	16727	16728	16729
Admin Session	16820
Data- Session2						16925
Data- Session Secure						17725
Web Socket						16825
Web Socket Secure						17825
OPCUA HTTP										16829
OPCUA TCP										16929
UPD Scan Request	16800
UPD Scan Request	16805
Project Transfer	16810

Laufzeit-Datenbank¶

In der Runtime wird nicht mehr die globale Runtime-Datenbanken im SQL Server verwaltet, sondern projektspezifische Runtime-Datenbanken. Diese sind zu finden im Ordner „SQLDB“. Der projektspezifische Datenbankname lautet: PWR_PROJECTNAME.

Note

Der Name für das Projekt „Messedemo_2016“ ist also „PWR_Messedemo_2016“.

Die Datenbank wird initial beim ersten Start der Runtime mit dem Projekt neu erzeugt. Um Datenverlust zu vermeiden, löscht die Runtime keine Datenbanken! Bestehende Datenbanken können über die SystemServer Konsole im Menü Configuration -> Runtime Databases aufgelistet und gelöscht werden. :::{important} Um zu verhindern, dass versehentlich Projekte mit gleichen Projektnamen auf falsche Datenbanken zugreifen, überprüft die Runtime beim Start eines Projekts anhand der Projekt-ID (Guid), die in der Datenbank eingetragen ist, ob es sich tatsächlich um das identische Projekt handelt. ::: Sollten ProjektID von Runtime und Datenbank nicht zusammenpassen, startet die Laufzeit nicht und der SystemServer meldet den Fehler:

Die Datenbank muss in diesem Fall entweder über die SystemServer Konsole gelöscht werden oder ein manuelles Eingreifen über das Microsoft SQL Server Management Studio ist notwendig.

VisuClient¶

Der Designer ist in der Lage eine Applikation für verschiedene Endgeräte anzufertigen. Diese Endgeräte werden in verschiedene Geräteklassen unterteilt wie Tablets oder Smartphone. Es sind standardmäßig drei Geräteklassen vordefiniert. Zum einen wird eine Default-Klasse mitgeliefert, zum anderen Klassen für Tablet und Smartphone. Weitere Klassen können individuell nach gewünschtem Gerät nachgepflegt werden.

Für jedes Gerät, das in der Projektierung berücksichtigt wurde, werden HTML-Seiten erzeugt. Diese Seiten werden dann, je nach Gerät, passend aufgerufen und im Browser angezeigt. Über die Vergabe individueller Schlüsselwörter können weitere Gerätetypen erkannt und mit eigenen Oberflächen versehen werden.

Zum Aufrufen eines Projektes in der Laufzeit muss als URL einfach der Name oder die IP des Servers in den Browser eingetragen werden:

http://ip-des-servers/

Note

Beispiel: http://localhost/

Mehrere Clients auf einem Rechner¶

Je nach Anwendungsfall kann es nötig sein, mehrere Clients auf einem Rechner starten zu wollen. Damit der WebServer diese Clients unterscheiden kann, müssen diese mit einer zusätzlichen Option in der URL gestartet werden. Diese Option besteht aus „?client=“ und der Nummer des Clients.

Note

Beispiel: http://192.168.10.20?client=1

Verschlüsselung für die Kommunikation zum Client¶

Dieses Kapitel beschreibt die Verschlüsselung von PROCON-WEB über https. In den nachfolgenden Abschnitten wird beschrieben, wie das System angepasst werden muss um den Datenverkehr sowie die Übertragung der Webseite zu verschlüsseln.

Zertifikat erstellen¶

Um die Verbindung zwischen Server und WebRuntime zu verschlüsseln, wird ein Zertifikat benötigt. Um Warnmeldungen im Browser zu vermeiden, muss das Zertifikat vertrauenswürdig sein.

Hier gibt es folgende Möglichkeiten:

Öffentliches Zertifikat (kostenpflichtig), z.B. VeriSign etc.

-> Auf allen Hosts im Internet vertrauenswürdig

Domänen Zertifikat (kostenlos)

-> Auf allen Hosts der Domäne vertrauenswürdig

Lokales Zertifikat (kostenlos)

-> Nur auf den gleichen Host vertrauenswürdig

Bei den meisten Anwendungsfällen für PROCON-WEB dürfte ein Domänen Zertifikat ausreichen. Hierfür muss der Administrator der Domäne kontaktiert werden. Es wird ein Zertifizierungs-Server benötigt (kann ein Windows Server sein), der Zertifikatanfragen beantwortet um diese für eine Domäne für vertrauenswürdig zu erklären.

Nachfolgend wird die Erstellung eines lokal vertrauenswürdigen Zertifikates über den IIS beschrieben:

IIS öffnen und Doppelklick auf „Server Certificates“

Aktion „Create Self-Signed Certificate…“

Der Zertifikatsname sollte genauso lauten wie der Rechnername!

Powershell Skript¶

Eine weitere Möglichkeit zur Erstellung eines lokalen, self-signed Zertifikats ist die Nutzung des folgenden Powershell Scripts:

#STEP 1
#Create a root CA certificate used to sign the localhost certificate
#will be created in Localmachine\My and need to be placed in LocalMachine\CA
$rootcert = New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My -DnsName "CACERTNAME" -TextExtension @("2.5.29.19={text}CA=true") -KeyUsage CertSign,CrlSign,DigitalSignature -NotAfter (Get-Date).AddYears(25)
[System.Security.SecureString]$rootcertPassword = ConvertTo-SecureString -String "PASSWORD" -Force -AsPlainText
[String]$rootCertPath = Join-Path -Path 'cert:\LocalMachine\My\' -ChildPath "$($rootcert.Thumbprint)"
Export-PfxCertificate -Cert $rootCertPath -FilePath 'RootCA.pfx' -Password $rootcertPassword
Export-Certificate -Cert $rootCertPath -FilePath 'RootCA.crt'

#STEP 2
# Certificate to be registered with PROCON-WEB Webserver
$testCert = New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My -DnsName "LOCALHOST" -KeyExportPolicy Exportable -KeyLength 2048 -KeyUsage DigitalSignature,KeyEncipherment -Signer $rootCert  -NotAfter (Get-Date).AddYears(25)
[String]$testCertPath = Join-Path -Path 'cert:\LocalMachine\My\' -ChildPath "$($testCert.Thumbprint)"
Export-PfxCertificate -Cert $testCertPath -FilePath testcert.pfx -Password $rootcertPassword
Export-Certificate -Cert $testCertPath -FilePath testcert.crt

Das Script erstellt zuerst ein Root CA(Certificate Authority) Zertifikat auf dessen Basis das eigentliche Zertifikat dann erstellt wird (# STEP 1), es sollte ein aussgekräftiger Zertifikatsname (Ersetzen von CACERTNAME im Script) und ein Passwort (Ersetzen von PASSWORD im Script) gewählt werden.

Dieses Zertifikat wird im Zertifikatstore (certlm) unter „Eigene Zertifikate“ gespeichert und muß zusätzlich in „Vertrauenswürdige Stammzertifikate“ kopiert werden

Anschließend wird das eigentliche Zertifikat dann erstellt wird (# STEP 2). Dabei sollte der DNS Name (Ersetzen von LOCALHOST im Script) auf den Rechnernamen gesetzt werden. Auch dieses Zertifikat wird unter „Eigene Zertifikate“ im Zertifikatstore (certlm) erstellt.

Damit später der Browser das Zertifikat als vertrauenswürdig einstufen kann muss es auch unter Vertrauenswürdige Stammzertifizierungsstellen kopiert werden. Soll der Zugriff von anderen Rechnern aus erfolgen muss dieses Zertifikat auch auf dem jeweiligen Rechner in den Zertifikatsstore installiert werden damit der Browser diesem Zertifikat vertraut

Zertifikat mit PROCON-WEB verknüpfen¶

Sobald ein Zertifikat vorhanden ist, muss dies mit PROCON-WEB verknüpft werden. Hier müssen zwei Schritte durchgeführt werden:

Das Zertifikat mit der Webseite verknüpfen¶

Das Zertifikat mit der Webseite verknüpfen

Binding für https mit dem Zertifikat verbinden

Important

ACHTUNG: Ein Zertifikat kann nur mit EINER Webseite verknüpft werden!

Das Zertifikat mit dem PROCON-WEB WebServer verknüpfen¶

Aus der Liste der Zertifikate das gewünschte Zertifikat öffnen und den „Thumbprint“ kopieren

Eingabeaufforderung als Administrator öffnen und folgenden netsh Befehl mit dem entsprechenden „Thumbprint“ (certhash) ausführen

http delete sslcert ipport=0.0.0.0:1700`

http add sslcert ipport=0.0.0.0:17725 certhash=3e49906c01a774c888231e5092077d3d855a6861 appid={4d76ee9e-7ef2-4530-b0d6-b725878671d8}

Der erste Befehl löscht ein ggf. bereits zugewiesenes Zertifikat und der zweite Befehl verknüpft das Zertifikat mit der PROCON-WEB Webserver Applikation (AppID: {4d76ee9e-7ef2-4530-b0d6-b725878671d8})

Durch die Angabe von 0.0.0.0 bei “ipport” wird jede verwendete Netzwerkkarte des Rechners gebunden, in diesem Fall auf den Port 17700, optional können die Befehle auch noch für den https Standard-Port 443 ausgeführt werden wenn auch dieser Port von PROCON-WEB verwendet werden soll.

Das Zertifikat über die GTI.CertApp verknüpfen¶

Anstelle der Kommandozeile kann auch die GTI.CertApp.exe aufgerufen werden. Das Tool wird als Administrator gestartet und führt die Kommandozeilen für den Benutzer aus, es muss nur das entsprechende Zertifikat aus der Kombobox ausgewählt werden und der Button „Mit PROCON-WEB verknüpfen“ betätigt werden:

Aufruf aus dem Browser¶

Je nach Vertrauenswürdigkeit des Zertifikats kann die Webseite nun per https ohne Warnmeldung aufgerufen werden. Damit keine Warnmeldung im Browser kommt, muss neben einem vertrauenswürdigen Zertifikat die Domain der URL korrekt sein.

Important

Wird eine Webseite mit einem Zertifikat außerhalb des Vertrauensbereichs (z.B. lokales Zertifikat von einem anderen Rechner der Domäne) aufgerufen, erscheint eine Warnmeldung.

Nach Bestätigung ist zwar die Kommunikation zum IIS erlaubt, nicht jedoch die Kommunikation zum PROCON-WEB WebServer. Workaround: Entsprechende URL direkt in die Adresszeile des Browsers eingeben.

Anschließend wieder zurück navigieren und PROCON-WEB nutzen.