Spécifications du système d’exploitation, de ​.NET Framework et de virtualisation

Cette section présente des détails supplémentaires sur les logiciels pris en charge avec un système InTouch HMI.

Notes sur la configuration logicielle requise

Notes sur les systèmes d’exploitation Windows

• Windows versions 8.1 et 10 prennent en charge les entrées tactiles. Dans la version 8.1 de Windows, si l'utilisateur fait un geste du doigt vers l'intérieur à partir du bord droit de l'écran tactile, un ensemble d'icônes Windows apparaîtra, dont Recherche, Partager, Démarrer, Périphériques et Paramètres. Déplacer le pointeur de la souris vers l'angle supérieur droit de l'écran affiche également les icônes Windows sur des écrans non tactiles.

  L'affichage du jeu d'icônes est une fonctionnalité standard des versions 8.1 de Windows qui ne peut être désactivée par un logiciel pour écran tactile. Les opérateurs peuvent donc accéder aux icônes Windows et éventuellement déverrouiller un poste de visualisation tactile dédié.

• Des Service Packs (SP) du système d'exploitation plus récents que ceux du tableau ne bloquent pas l'installation des produits. Un message d'avertissement peut s'afficher pendant le processus d'installation.

• Le Référentiel Galaxy (poste GR) peut être exécuté sur un client sous Windows uniquement dans une configuration de cinq postes maximum, équipés de produits System Platform. Pour des systèmes de plus de cinq postes, le référentiel Galaxy doit être installé sur un ordinateur avec système d'exploitation Windows Server.

• Les postes de développement et d'application sont considérés des clients du poste GR serveur.

• Lorsqu'un système d'exploitation est mis à niveau sur un ordinateur, les produits System Platform existants doivent être désinstallés avant la mise à niveau, puis réinstallés après. Il n’est pas nécessaire de désinstaller les produits System Platform en cas de mise à niveau de Windows 2012 vers Windows 2012 R2.

Notes sur .Net

• Les versions de .NET (autres que les versions 4.x) peuvent coexister, mais tout le code .NET, y compris les scripts QuickScript.net, s'exécute sous .NET 4.8.

  Pour plus d'informations sur les spécifications et la compatibilité avec .NET Framework, reportez-vous à la section Spécifications et compatibilité avec .NET Framework.

• .NET 3.5 est installé uniquement parce que les versions prises en charge de SQL Server le nécessitent. Aucune autre dépendance ne doit exister.

Notes relatives aux systèmes d’exploitation, communes à tous les produits AVEVA

Comportement des contrôles ActiveX sur les systèmes d’exploitation Windows pris en charge

La caractéristique DEP (Data Execution Prevention) sous Windows 7 et versions supérieures, entraînera la défaillance ou le comportement imprévisible des contrôles ActiveX générés avec ATL version 7.1 ou inférieure, sous InTouch 2017 UPDATE 1 aussi bien dans WindowMaker que dans WindowViewer. Pour plus d’informations, consultez la note technique 922 : « Some ActiveX Controls NOT Supported in InTouch 2012 R2 (Version 10.6) » (Certains contrôles ActiveX NON pris en charge par InTouch 2012 R2 (Version 10.6)) disponible sur le site du support technique.

Configuration des requêtes d’extraction d’alarmes distantes

Le processus permettant de configurer des requêtes d'extraction d'alarmes distantes a été modifié pour des applications interactives comme InTouch HMI, lorsqu'elles sont exécutées sur des systèmes d'exploitation Windows ou Windows Server.

Quand InTouch WindowViewer est lancé et génère des alarmes au cours de sessions de bureau Windows interactives, un contrôle AlarmViewer (exécuté dans InTouch HMI) doit être spécialement configuré sur un poste distant pour lancer les requêtes d'alarmes. Les alarmes de la source ne s'affichent pas à moins de configurer la requête d'alarmes du contrôle AlarmViewer.

Ce type de requête ne fonctionne que lorsqu'InTouch HMI est exploité comme producteur d'alarmes dans une session de services Terminal Server, et non pas quand InTouch s'exécute dans une session de console.

Pour configurer la requête d’alarmes d’AlarmViewer

1. Après avoir lancé InTouch WindowViewer (le producteur d'alarmes), ouvrez et recherchez dans Logger contrôle des opérations (Journal SMC) la plus récente des chaînes générées par AlarmMgr. Par exemple : « Registering AlarmMgr with SLSSVC as AlarmMgr 253.127.148.120 ». L'adresse IP indiquée correspondra à l'adresse unique du poste producteur des alarmes. Notez l'adresse IP pour l'étape 2.

2. Sur la machine distante, dans l'onglet Requête d'alarmes du contrôle AlarmViewer, paramétrez la requête d'alarmes en remplaçant « nomPoste » par le nom réel du poste InTouch HMI producteur d'alarmes ainsi que l'adresse IP retenue à l'étape précédente :

   \\nomPoste:adresseIP\intouch!$system

   où nomPoste est le nom du poste fournissant l'alarme InTouch et adresseIP est l'adresse IP déterminée à l'étape 1.

3. Vérifiez que les alarmes générées depuis le poste producteur des alarmes sont affichées avec précision par le contrôle AlarmViewer.

Utilisation du gestionnaire d'alarmes sur un poste unique fournisseur d'alarmes à la fois d'InTouch HMI et d'Application Server

À partir de Microsoft Windows Vista, le système d'exploitation impose un renforcement de sécurité par « Isolement de Session 0 ». Tous les services Windows et les programmes associés sont obligés de s'exécuter en mode session 0, et aucune application dotée d'interface utilisateur n'est autorisée à fonctionner dans ce mode.

Avant Windows Vista, Application Server et InTouch HMI WindowViewer s'exécutaient dans la même session Windows. L'isolation en mode session 0 exige ainsi une exécution d'Application Server et de WindowViewer sous des sessions différentes. Les alarmes renvoyées par le Galaxy sont gérées par une instance en Session 0 du gestionnaire d'alarmes (AlarmMgr), donc différente de la session de console utilisée par l'instance d'AlarmMgr qui gère les alarmes InTouch. Une simple requête d'alarme dans un affichage d'alarmes InTouch, comme par exemple

\InTouch!$System \Galaxy!Area_001

est désormais contrôlée par deux instances séparées AlarmMgr -- l'une s'exécute dans une session en mode Console dans le cas d'InTouch, l'autre dans une session 0 dans le cas du Galaxy.

Ce comportement, les comportements associés et les messages d'erreur qui résultent des changements liés à la Session 0 sous Windows, de même que les procédures pour configurer le Système d'alarmes distribuées et prendre en charge des alarmes provenant aussi bien d'InTouch que d'Application Server sur un même poste d'ordinateur exploité sous Windows Vista et versions supérieures, sont décrits en détail dans la TechNote 988, « AlarmMgr Support for InTouch and AppServer on Windows Vista and Later ». Vous pouvez télécharger cette TechNote depuis le site Web de Global Customer Support (GCS).

Comportement des services Bureau à distance (Terminal Server) sur les systèmes d’exploitation Windows Server

Windows Server 2008 R2 et les versions supérieures de Windows ne prennent plus en charge le paramètre /console pour configurer un client RDP de connexion du bureau à distance, également désigné comme Session 0 ou session de console de Terminal Server. Dans Windows Server 2008 ou version ultérieure, la Session 0 n'est plus une session interactive session, qui est réservée aux services Windows uniquement. Depuis Windows Server 2008, toutes les connexions distantes sont traitées comme des sessions RDP distantes, sans tenir compte des paramètres /console, /admin ou autres, utilisés pour établir la connexion.

Ceci affecte des caractéristiques d'InTouch HMI telles que le gestionnaire d'alarmes, qui dépend de la session de console de Terminal Server.

Dans un autre aspect du comportement de Terminal Services, des fonctions d'InTouch HMI comme TSEGetClientID() peuvent retourner une valeur null, quand InTouch s'exécute dans une session client de bureau à distance (RDP). Ce comportement s'explique parce que certains rôles déterminants ne sont pas installés sur le client RDP. Vous devez installer le rôle « Hôte de bureau à distance » pour que les fonctions comme TSEGetClientId() et d'autres associées puissent fonctionner correctement.

L'effet sur Application Server est minime dès lors que la plupart des processus de Application Server s'exécute en tant que service. Un effet sur Application Server est celui de reprendre la restriction introduite avec le système d'exploitation Windows Vista qui ne permet qu'un seul et unique producteur d'alarmes. Alors que Application Server et InTouch HMI peuvent tous deux être configurés comme producteurs d'alarmes, il ne peut y avoir qu'un seul producteur d'alarmes configuré à un moment donné.

Application Server et InTouch HMI détectent quand l'application est exécutée en mode console. Dans Windows Server, cela implique que l'application a été lancée par un utilisateur physiquement présent sur la machine. Cependant, ce comportement requiert de désactiver la stratégie de groupe permettant le changement rapide d'utilisateur.

Le logiciel détecte si une application est exploitée en mode console. Toutes les connexions distantes sont traitées comme des sessions de Bureau à distance, sans tenir compte des paramètres /console ou /admin dans la connexion mstsc.

Pour désactiver le changement rapide d'utilisateur depuis l'interface Stratégie de groupe

4. Cliquez Démarrer puis Exécuter. La boîte de dialogue Exécuter s'affiche.

5. Entrez gpedit.msc puis cliquez sur OK. La boîte de dialogue Stratégie de groupe apparaît.

6. Déployez l’entrée : Stratégie Ordinateur local > Modèles d’administration > Système > Ouverture de session.

7. Définissez Masquer les points d'entrée pour le changement rapide d'utilisateur à Activé. L'activation de cette stratégie permet de masquer l'option Changement d'utilisateur dans l'interface Ouverture de session, dans le menu Démarrer et dans le Gestionnaire de tâches.

8. Dans le menu Fichier, cliquez sur Quitter pour fermer la boîte de dialogue de Stratégie de groupe.

En activant cette stratégie, un administrateur peut masquer le bouton de changement d'utilisateur dans la fenêtre d'ouverture de session de Windows, dans le menu Démarrer et dans le Gestionnaire de tâches.

InTouch HMI – Notes sur le système d’exploitation

• Le client Windows (à partir de Windows 7) ne prend pas en charge une configuration serveur monoposte exécutant une ou plusieurs bases de données d'un système InTouch HMI.

• La fonction EnableDisableKeys() écrit dans le Registre de Windows pour activer ou désactiver certaines touches sur le poste hôte qui exécuteur une application in WindowViewer. Pour des raisons de sécurité, Windows 7 et postérieurs empêchent les utilisateurs standard ou avec pouvoirs d'écrire dans le Registre. Les administrateurs Windows peuvent écrire dans le Registre si cette possibilité n'est pas désactivée par des stratégies de sécurité du domaine local.

  Vous pouvez configurer les stratégies de sécurité du domaine Windows local qui interagissent avec la fonction de script EnableDisablekeys() pour contrôler l'accès utilisateur aux touches script depuis une application InTouch en exécution.

• À partir de System Platform 2014, un ordinateur exécutant Windows 7 ou version ultérieure du système d'exploitation peut être configuré à la fois comme un InTouch et un fournisseur d'alarmes de Application Server. Pour plus d'informations, reportez-vous à la section Utilisation du gestionnaire d'alarmes sur un poste unique exécutant à la fois InTouch HMI et des fournisseurs d'alarmes Application Server sur les systèmes d'exploitation Vista et versions ultérieures.

  Les fonctions de script existantes InTouch ci-après sont inopérantes sur les versions 64 bits de Windows : WWPoke(), WWExecute(), WWRequest(), ActivateApp() et SendKeys().

• Pour un fonctionnement correct, il peut être nécessaire de démarrer InTouch Extensibility Toolkit avec le bouton droit, puis de sélectionner Exécuter en tant qu'administrateur sur les systèmes d'exploitation Windows 11 ou supérieurs.

• Les options du clavier visuel ont été modifiées sous Windows 7 et Windows Server 2008 R2.

• Le mode pointage avec les touches du clavier Windows ne fonctionne plus dans les versions de Windows prises en charge.

Applications InTouch HMI View et prise en charge DDE

NetDDE n'est pas pris en charge pour les applications InTouchView.

De par sa conception, une application InTouchView ne fournit pas de données à d'autres sources, ni à InTouch HMI lui-même. Quand il démarre, WindowViewer vérifie si l'application est une application InTouchView. Si WindowViewer détecte une application InTouchView, il omet d'enregistrer les informations système qui lui permettent de se transformer en serveur DDE. Les graphiques industriels font usage de la couche client pour accéder aux variables InTouch, et ils apparaissent comme des clients d'un autre fabricant qui tentent d'accéder à WindowViewer en se présentant comme des serveurs de données. Il s'ensuit que les graphiques industriels ne peuvent pas communiquer avec les variables InTouch quand une licence InTouchView est utilisée.

Dans des graphiques industriels, la méthode InTouch:‹variable› est toujours acceptée pour se référer à une variable InTouch sur un poste local.

Prise en charge d’InTouch HMI pour le contrôle des comptes utilisateur Windows

System Platform 2026 avec InTouch HMI prend en charge les opérations de Contrôle de compte d'utilisateur autorisées sur les postes d'exploitation.

Spécifications et compatibilité avec .NET Framework

IMPORTANT : System Platform 2026 installe .NET 4.8 si la version actuellement installée de .NET est 4.7.2 ou inférieure. Si la version .NET 4.8 ou supérieure est installée, aucune modification n'est faite dans la configuration de .NET Framework. Avant de mettre à niveau vos applications existantes vers System Platform 2026, il est fortement recommandé de :

• Faire une sauvegarde de vos applications

• Se familiariser avec les changements apportés par Microsoft à .NET Framework

• Réviser vos scripts et contrôles .NET pour déterminer les modifications nécessaires

Après une mise à niveau vers System Platform 2026, il convient de tester le fonctionnement des scripts d'application et des bibliothèques de script utilisés par l'application pour s'assurer de son bon fonctionnement sous.NET 4.8. Nous recommandons également de tester la mise à niveau sur un système transitoire avant procéder à la mise à niveau de votre système de production.

System Platform 2026 fait usage de Microsoft .NET Framework 4. Le programme d’installation de System Platform installe .NET 4.8 si le système est équipé de .NET 4.7.2 ou inférieur. Aucune modification n'est faite dans le système s'il utilise .NET 4.8 ou supérieur. De multiples versions de .NET Framework peuvent coexister. Sur des postes équipés de SQL Server, la version .NET 3.5 est également installée par System Platform pour sa prise en charge. Dans ce scénario, les autres applications sur la même machine qui dépendent de .NET 3.5 continuent d’accéder à .NET 3.5.System Platform 2026 utilise .NET 4.7.1, 4.7.2 ou supérieur.

Tous les programmes de code utilisateur .NET qui s'exécutaient dans le contexte d'InTouch HMI et d'Application Server s'exécuteront désormais sous .NET Framework 4.8 ou supérieur. Bien que .NET Framework 4.5.1 (et supérieur) soit hautement compatible avec les applications produites sur des versions précédentes de .NET Framework, il peut s'avérer nécessaire de mettre à niveau vos scripts .NET créés sur une version antérieure à System Platform 2014. Ces modifications peuvent également affecter les contrôles .NET développés avec .NET 3.5.

Dans un script d'application, du code .NET n'utilisant pas un encodage de texte adéquat peut échouer et provoquer la fin du script avant terme. La fonction UTF8Encoder est le décodeur BinaryStream par défaut sous .Net 4.5. Pour permettre à un script d'application de décoder des données XML ASCII, par exemple, insérez la portion de code suivante :

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

Pour en savoir plus sur les changements introduits dans les différentes versions de .NET Framework, reportez-vous aux ressources suivantes de Microsoft :

Nouveautés dans .NET Framework :http://msdn.microsoft.com/en-us/library/ms171868%28v=vs.110%29.aspx

Parties obsolètes de la bibliothèque de classe .NET Framework : https://msdn.microsoft.com/en-us/library/ee461502%28v=vs.110%29.aspx

Guide de migration vers .NET Framework 4.6 et 4.5 : https://msdn.microsoft.com/en-us/library/ff657133%28v=vs.110%29

Problèmes de migrations de .NET Framework 4 : http://msdn.microsoft.com/en-us/library/ee941656%28v=vs.100%29

Prise en charge de l’hôte de virtualisation

Reportez-vous à la Matrice des technologies Global Customer Support (GCS) pour la prise en charge des environnements de virtualisation.