Anforderungen hinsichtlich Betriebssystem, ​.NET Framework und Virtualisierung

In diesem Abschnitt erhalten Sie zusätzliche Informationen zu Softwareanforderungen für InTouch HMI-Systeme.

Hinweise zu den Softwareanforderungen

Hinweise zum Windows-Betriebssystem

• Windows-Versionen 8.1 und 10 unterstützen Touchscreen-Gesten. Wenn der Benutzer in der Windows-Version 8.1 auf einem Touchscreen mit dem Finger vom rechten Rand über den Bildschirm wischt, wird die Charm-Leiste mit den Optionen Suchen, Teilen, Start, Geräte und Einstellungen eingeblendet. Diese Leiste wird auch auf normalen Monitoren angezeigt, wenn der Mauszeiger in die rechte obere Bildschirmecke bewegt wird.

  Die Anzeige der Charm-Leiste ist eine Standardfunktion der Windows-Version 8.1, die nicht mit einer Software für Touchscreens deaktiviert werden kann. Daher können Bediener in diesen Betriebssystemen auf die betreffenden Optionen zugreifen und auf diesem Wege möglicherweise umfangreicheren Zugriff auf den WindowViewer-Rechner erhalten, als für sie vorgesehen ist.

• Neuere Service-Packs (SPs) der aufgeführten Betriebssysteme blockieren nicht die Installation von Produkten. Es kann dann jedoch während der Installation eine Warnmeldung auftreten.

• Wenn das Galaxy-Repository (GR) unter einem Windows-Clientbetriebssystem ausgeführt wird, können die Komponenten von System Platform auf bis zu fünf Rechnern installiert werden. Bei einem System mit mehr als fünf Rechnern muss das Galaxy-Repository auf einem Rechner mit einem Windows-Serverbetriebssystem installiert werden.

• Die Entwicklungs- und Projektrechner gelten als Clients des Galaxy-Repositorys.

• Wenn das Betriebssystem auf einem Rechner aktualisiert wird, müssen alle dort installierten Komponenten von System Platform vorher deinstalliert und nach Abschluss der Aktualisierung erneut installiert werden. Die vorherige Deinstallation von System Platform ist bei folgenden Aktualisierungen nicht erforderlich: von Windows 2012 auf Windows 2012 R2.

Hinweise zu .NET

• Es können mehrere Versionen des .NET Framework (auch ältere als 4.x) gleichzeitig installiert sein. Der gesamte .NET-Code einschließlich der in QuickScript.NET entwickelten Skripte wird jedoch in .NET Framework 4.8 ausgeführt.

  Weitere Informationen zu den Anforderungen hinsichtlich .NET Framework und der Kompatibilität finden Sie im Abschnitt .NET Framework – Anforderungen und Kompatibilität.

• .NET 3.5 wird nur installiert, weil es eine Voraussetzung für den Betrieb der unterstützten SQL Server-Versionen ist. Weitere Abhängigkeiten dürfen nicht gegeben sein.

Allgemeine betriebssystembezogene Hinweise zu den AVEVA-Produkten

Verhalten von ActiveX-Steuerungen bei unterstützten Windows-Betriebssystemen

Aufgrund der Datenausführungsverhinderungsfunktion (DEP) von Windows 7 und neueren Betriebssystemen können ActiveX-Steuerungen, die mit ATL 7.1 oder früheren Versionen erzeugt wurden, nicht hosten, oder sie verhalten sich in InTouch 2017 UPDATE 1 entweder in WindowMaker oder in WindowViewer unvorhersehbar. Weitere Informationen finden Sie in Tech Note 922: „Some ActiveX Controls NOT Supported in InTouch 2012 R2 (Version 10.6)“ (verfügbar auf der Website des technischen Supports).

Konfigurieren von Remote-Alarmabfragen

Der Prozess der Konfiguration von Alarm-Fernsuchanfragen hat sich für interaktive Projekte wie InTouch HMI geändert, wenn sie auf aktuell unterstützten Windows- und Windows Server-Betriebssystemen laufen.

Wenn InTouch WindowViewer gestartet wird und Alarme von einer interaktiven Windows-Desktopsitzung erzeugt werden, muss eine AlarmViewer-Steuerelement (die in InTouch HMI läuft) auf einem entfernten Rechner speziell konfiguriert werden, dass sie die Alarme abfragt. Ein AlarmViewer-Steuerelement auf einem Remoterechner kann in einem solchen Fall nur dann Alarme von dieser Quelle abfragen, wenn die Alarmabfrage wie folgt konfiguriert wird.

(Diese Abfragen funktionieren nur, wenn die InTouch-Alarmquelle in einer Terminaldienste-Sitzung ausgeführt wird, nicht jedoch bei einer Konsolensitzung.)

Konfigurieren der Alarmabfrage im AlarmViewer

1. Nach dem Start von InTouch WindowViewer (Alarmauslöser), öffnen Sie Operations Control Logger und suchen Sie dann nach dem neuesten von AlarmMgr erzeugten Zeichenfolge. Beispiel: „Registering AlarmMgr with SLSSVC as AlarmMgr 253.127.148.120“. Die angegebene IP-Adresse benötigen Sie zur Identifikation des Alarmquellen-Rechners. Notieren Sie sich die angezeigte IP-Adresse für Schritt 2.

2. Konfigurieren Sie auf der Registerkarte Alarmabfrage das Steuerelement AlarmViewer am Remotecomputer. Konfigurieren Sie die Alarmabfrage wie folgt, und setzen Sie den Rechnernamen des Alarms in InTouch HMI unten bei „Rechnername“ und Ihre IP-Adresse, die Sie im vorangehenden Schritt notiert haben, ein:

   \\Rechnername:IP-Adresse\intouch!$system

   Rechnername ist dabei der Hostname des InTouch-Alarmquellenrechners, IP-Adresse ist die im ersten Schritt notierte IP-Adresse.

3. Testen Sie die korrekte Anzeige der Alarme von der Alarmquelle im AlarmViewer-Steuerelement.

Verwenden von Alarm Manager auf einem Rechner, auf dem die Alarmquellen von InTouch HMI und Application Server gleichzeitig ausgeführt werden

Ab Microsoft Windows Vista wird aus Sicherheitsgründen die Sitzung 0 isoliert. Das bedeutet, dass alle Windows-Dienste und damit zusammenhängenden Programme in Sitzung 0 ausgeführt werden müssen. Projekte mit grafischer Oberfläche sind dagegen in Sitzung 0 nicht zulässig.

Vor Windows Vista wurden Application Server und InTouch HMI WindowViewer in derselben Windows-Sitzung ausgeführt. Aufgrund der Isolierung von Sitzung 0 ist dies nun nicht mehr möglich. Galaxy-Alarme werden daher jetzt von der Alarm Manager-Instanz in Sitzung 0 gemeldet, während für InTouch-Alarme eine Alarm Manager-Instanz in der Konsolensitzung zuständig ist. Eine einfache InTouch-Alarmabfrage wie

\InTouch!$System \Galaxy! Area_001

wird daher jetzt von zwei separaten Alarm Manager-Instanzen bedient: einer in der Konsolensitzung für die InTouch-Alarme und einer weiteren in Sitzung 0 für die Galaxy-Alarme.

Zu dieser Thematik wurde die Tech Note 988 mit dem Titel „AlarmMgr Support for InTouch and AppServer on Windows Vista and Later“ veröffentlicht. Sie beschreibt dieses Verhalten sowie damit zusammenhängende Hinweise und Fehlermeldungen infolge der Isolierung der Windows-Sitzung 0. Darüber hinaus wird erklärt, wie das verteilte Alarmsystem unter Windows Vista und neueren Betriebssystemen so konfiguriert wird, dass Alarme von InTouch und Application Server auf demselben Rechner unterstützt werden. Diese Tech Note ist auf der Website Global Customer Support (GCS) verfügbar.

Verhalten von Remotedesktopdiensten (Terminaldienste) bei Windows Server-Betriebssystemen

Windows Server 2008 R2 und neuere Windows-Versionen unterstützen den Parameter /console zum Aufruf einer Terminalserver-Konsolensitzung („Sitzung 0“) über den Remotedesktopclient (RDP) nicht mehr. „Sitzung 0“ ist unter Windows Server 2008 und höher keine interaktive Sitzung mehr, sondern für Windows-Dienste reserviert. Versionen ab Windows Server 2008 behandeln daher alle Remoteverbindungen als normale RDP-Sitzungen, auch wenn dem Remoteclient der Schalter /console oder /admin übergeben wird.

Diese Änderung hat Auswirkungen auf InTouch HMI-Funktionen wie den Alarm-Manager, die auf die Remotedesktop-Sitzung (Terminalserver-Konsole) angewiesen sind.

Außerdem kann es vorkommen, dass InTouch-Funktionen wie TSEGetClientID() einen NULL-Wert zurückgeben, wenn InTouch in einer Remotedesktopclient-Sitzung (RDP) ausgeführt wird. Ursache dieses Verhaltens ist, dass die relevanten Rollen nicht auf dem RDP-Client installiert sind. Die Rolle „Remote Desktop Host“ muss installiert sein, damit TSEGetClientId() und andere ähnliche Funktionen richtig funktionieren.

Die Auswirkungen auf Application Server sind dagegen minimal, da die meisten Prozesse von Application Server als Dienste ausgeführt werden. Zu beachten ist hier die bereits seit Windows Vista bestehende Einschränkung, dass nur eine Alarmquelle zur gleichen Zeit möglich ist. Application Server und InTouch können daher nicht gleichzeitig als Alarmquelle konfiguriert werden.

Application Server und InTouch HMI erkennen, wenn ein Projekt in der Konsole ausgeführt wird. In Windows Server bedeutet das, dass das Projekt physisch von einem Benutzer am Gerät gestartet wurde. Dieses Verhalten kann aber das Deaktivieren von Fast User Switching erfordern.

Die Software erkennt, wenn ein Projekt in der Konsole ausgeführt wird. Alle Remoteverbindungen werden von Windows Server als RDP-Remotesitzung behandelt, unabhängig von den Schaltern /console oder /admin bei der mstsc-Verbindung.

So wird Fast User Switching auf der Group Policy-Oberfläche deaktiviert

4. Klicken Sie auf Start und dann auf Ausführen. Das Dialogfeld Ausführen wird angezeigt.

5. Geben Sie gpedit.msc ein und klicken Sie auf OK. Das Fenster Lokaler Gruppenrichtlinien-Editor wird angezeigt.

6. Navigieren Sie zum folgenden Speicherort: Richtlinien für Lokaler Computer > Administrative Vorlagen > System > Anmelden.

7. Setzen Sie die Richtlinie Einstiegspunkte für die schnelle Benutzerumschaltung ausblenden auf Aktiviert. Hiermit wird die Option Benutzer umschalten im Menü Start und im Task-Manager aktiviert.

8. Klicken Sie im Menü Datei auf Beenden, um das Fenster Lokaler Gruppenrichtlinien-Editor aufzurufen.

Durch Aktivieren der Richtlinien können Administratoren die Schaltfläche Benutzerschaltungs bei der Windows-Anmeldung, im Start-Menü und im Task-Manager ausblenden.

Betriebssystembezogene Hinweise zu InTouch HMI

• Windows-Clients (beginnend mit Windows 7) unterstützen keine dedizierte Einzelknoten-Serverkonfiguration mit einer oder mehreren Datenbanken für ein InTouch HMI-System.

• Die EnableDisableKeys()-Funktion schreibt in die Windows-Registrierung, um bestimmte Tasten auf dem Hostcomputer zu aktivieren oder deaktivieren, auf dem ein Projekt in WindowViewer läuft Aus Sicherheitsgründen verhindern Windows 7 und neuere Versionen von Windows, dass Standard- oder Hauptbenutzer in die Registrierung schreiben können. Windows-Administratoren können in die Registrierung schreiben, sofern dieses nicht von lokalen Domain-Sicherheitsrichtlinien deaktiviert ist.

  Sie können lokale Windows-Sicherheitsrichtlinien konfigurieren, die in Verbindung mit der Skriptfunktion EnableDisablekeys() den Benutzerzugriff auf Tasten in einem laufenden InTouch-Projekt regeln.

• Ab der System Platform 2014 können Rechner mit Windows 7 oder höher gleichzeitig als InTouch- und Application Server-Alarmquelle konfiguriert werden. Weitere Informationen finden Sie im Abschnitt Verwenden von Alarm Manager auf einem Rechner, auf dem die Alarmquellen von InTouch und Application Server gleichzeitig ausgeführt werden, unter Windows Vista und späteren Betriebssystemen.

  Die folgenden veralteten InTouch-Skriptfunktionen funktionieren nicht auf 64-Bit-Versionen von Windows: WWPoke(), WWExecute(), WWRequest(), ActivateApp() und SendKeys().

• Damit das InTouch Extensibility Toolkit unter Windows 11 (oder höher) mit einem Rechtsklick korrekt funktioniert, muss es eventuell mit dem Befehl Als Administrator ausführen gestartet werden.

• Unter Windows 7 und Windows Server 2008 R2 gibt es andere Optionen für die Bildschirmtastatur.

• Die Zeicheneingabe durch Verweilenlassen des Zeigers über einem Zeichen der Windows-Tastatur funktioniert nicht bei unterstützten Windows Betriebssystemen.

Unterstützung für View-Projekte und DDE in InTouch HMI

NetDDE wird für InTouchView-Projekte nicht unterstützt.

InTouchView-Projekte sind so konzipiert, dass sie nicht als Datenquelle dienen (auch nicht für andere InTouch-Projekte). Beim Start von WindowViewer wird geprüft, ob das Projekt ein InTouchView-Projekt ist. Wenn dies der Fall ist, wird WindowViewer nicht als DDE-Server registriert. Industriegrafiken verwenden die Clientschicht, um auf InTouch-Variablen zuzugreifen, und erscheinen daher als externer Client, der versucht, auf WindowViewer als Datenserver zuzugreifen. Industriegrafiken können daher nicht mit InTouch-Variablen kommunizieren, wenn InTouch mit einer InTouchView-Lizenz verwendet wird.

In Industriegrafiken ist der Zugriff auf InTouch-Variablen auf dem lokalen Rechner weiterhin über einen Verweis der Form InTouch:‹Variablenname› möglich.

Unterstützung für die Windows-Benutzerkontensteuerung in InTouch HMI

Die System Platform 2026 mit InTouch HMI unterstützt auf Laufzeitrechnern den Betrieb mit aktivierter Benutzerkontensteuerung.

.NET Framework – Anforderungen und Kompatibilität

WICHTIG: Bei der Installation von System Platform 2026 wird automatisch .NET 4.8 installiert, wenn aktuell .NET 4.7.2 oder niedriger installiert ist. Wenn bereits .NET Framework 4.8 oder höher installiert ist, wird keine Änderung an .NET Framework vorgenommen. Wir raten dringend dazu, vor der Aktualisierung mit System Platform 2026 folgende Schritte durchzuführen:

• Sichern Sie Ihre vorhandenen Projekte.

• Machen Sie sich mit den Änderungen von Microsoft am .NET Framework vertraut.

• Überprüfen Sie Ihre .NET-Skripte und .NET-Steuerelemente daraufhin, ob Änderungen vorgenommen werden müssen.

Nach dem Upgrade auf die System Platform 2026 sollten Sie die Projektskripte und verwendeten Skriptbibliotheken auf korrekte Funktion unter dem .NET 4.8 testen. Außerdem empfiehlt es sich, das aktualisierte Projekt vor dem Upgrade der Produktivsysteme in einer Staging-Umgebung zu testen.

System Platform 2026 Greift auf Microsoft .NET Framework 4 zu. Bei der Installation der System Platform wird NET 4.8 installiert, wenn auf dem System die Version 4.7.2 oder niedriger läuft. Wenn bereits das .NET Framework 4.8 oder höher installiert ist, wird keine Änderung vorgenommen. Es können gleichzeitig mehrere Versionen des .NET Framework installiert sein. Auf Rechnern mit SQL Server wird zusätzlich .NET Framework 3.5 zusammen mit System Platform installiert, um SQL Server zu unterstützen. In diesem Fall wird .NET Framework 3.5 auch von anderen Projekten auf dem Rechner verwendet, die von .NET 3.5 abhängig sind. .NET 3.5 System Platform 2026 verwendet .NET 4.7.1, 4.7.2 oder höher.

Für den gesamten, in InTouch HMI und Application Server ausgeführten benutzerdefinierten .NET-Code wird .NET Framework 4.8 oder höher benötigt. Das .NET Framework 4.5.1 (und höher) ist weitestgehend kompatibel mit Projekten, die mit früheren .NET Framework-Versionen entwickelt wurden. Allerdings können Änderungen an .NET-Skripten nötig sein, die mit Wonderware-Versionen vor Wonderware System Platform 2014 erstellt wurden. Auch .NET-Steuerelemente, die mit dem .NET Framework 3.5 entwickelt wurden, können hiervon betroffen sein.

In Projekt-Skripten kann es zu Fehlern und Abbrüchen im .NET-Code kommen, wenn nicht die korrekte Textcodierung verwendet wird. Standardmäßig wird im .NET Framework 4.5 für BinaryStream-Objekte der Decoder UTF8Encoder verwendet. Wenn ein Projekt-Skript beispielsweise ASCII-codierte XML-Daten decodieren soll, fügen Sie den folgenden Aufruf ein:

BinaryReader streamReader = new BinaryReader(ms, new ASCIIEncoding());

Weitere Informationen zu den Änderungen in den verschiedenen Versionen des .NET Framework finden Sie in den folgenden Microsoft-Artikeln:

Neues in .NET Framework: http://msdn.microsoft.com/en-us/library/ms171868%28v=vs.110%29.aspx

Veraltete Elemente in der .NET Framework-Klassenbibliothek: https://msdn.microsoft.com/en-us/library/ee461502%28v=vs.110%29.aspx

Migrationshandbuch zu .NET Framework 4.6 und 4.5: https://msdn.microsoft.com/en-us/library/ff657133%28v=vs.110%29

Migrationsprobleme in .NET Framework 4: http://msdn.microsoft.com/en-us/library/ee941656%28v=vs.100%29

Unterstützte Virtualisierungshosts

Unterstützte Visualisierungsumgebungen finden Sie bei Global Customer Support (GCS) Technology Matrix