Des IHM connectées et surtout, intelligentes

La technologie des moniteurs industriels pour le pilotage et le suivi des processus de production depuis une salle de contrôle ou directement sur le plateau est en pleine transformation. Désormais les IHM embarquent des couches logicielles qui leur permettent d’afficher des applications complexes exécutées à distance, en s’inspirant de très près, des technologies venues… du Web.


A l’origine, les écrans étaient reliés aux automates au travers d’une liaison câblée point-à-point supportée au moyen de ports de communication série de type RS-232, RS-422 ou RS-485. Si elle apporte d’indéniables garanties en matière de fiabilité, une telle solution présente un désavantage de taille : il est difficile de mutualiser les équipements sans alourdir l’infrastructure, sans complexifier son évolution ultérieure et dans une moindre mesure, sa maintenance.

La tendance a donc évolué ces dernières années en reliant les automates, les postes de contrôle et les écrans de commande à des réseaux de communication câblés au standard Ethernet (Lan) voire parfois, au travers de liaisons sans-fil de type WLan (IEEE 802.11a/b/g/n). si les réseaux Ethernet peuvent véhiculer localement des paquets d’information issus des protocoles de communication hétérogènes, ils peuvent aussi encapsuler ces données dans des trames routables avec TCP/IP. Partant, la distance entre le moniteur, la station de travail et le serveur informatique peut aujourd’hui s’affranchir des distances.

Cette modernisation significative au niveau des méthodes d’interconnexion, s’accompagne d’une évolution au moins aussi importante au niveau des écrans servant d’interface entre l’homme et ses machines. Désormais, les moniteurs intègrent des micrologiciels extrêmement sophistiqués qui s’exécutent directement sur la carte informatique dont ils sont équipés et où réside de plus en plus fréquemment, ce qu’on appelle un client léger.

Venue de l’informatique, la virtualisation est la dernière tendance à se répandre dans les grandes entreprises possédant de nombreux sites de production. Un voire plusieurs serveurs jouant le rôle d’hôtes peuvent héberger des dizaines de machines virtuelles. Chacune de ces dernières représente un serveur d’applications, une station de travail ou même, un automate sur base PC ; autant d’éléments constitutifs du système de contrôle des processus. Ces entreprises y gagnent une agilité nouvelle qui leur permet d’adapter les capacités de production de chaque site en fonction des réalités de la demande. Elles peuvent aussi plus facilement déployer leurs capacités opérationnelles sur une nouvelle installation avec l’assurance que les standards de qualité et les bonnes pratiques qui constituent leur biencommun, seront automatiquement respectés.

Une fenêtre bien réelle

Des moniteurs de plus en plus larges sont utilisés en lieu et place des terminaux opérateurs qui étaient précédemment installés directement sur les machines ou montés sur châssis au plus près des équipements opérationnels. Le recours à une connexion en réseau de type Ethernet permet de déployer un moniteur presque n’importe où sur un site et autorise même son déplacement ultérieur. Cette souplesse dans la mise en relation avec les ressources partagées en réseau prend une dimension totalement nouvelle dès lors que les moniteurs ont la capacité d’accéder à un large éventail d’applications.

Les moniteurs gardent leur rôle d’IHM mais ils sont aussi désormais capables de relayer les informations vers les opérateurs et dans le même temps, de servir de point d’entrée sur des applications sophistiquées et pointues s’exécutant sur des serveurs situés sur le réseau informatique local ou… à l’autre bout du monde. Il en découle des exigences nouvelles comme des affichages à haute résolution calés sur les standards informatiques (ex. : 1920 x 1080 pixels), des capacités de réaction aux commandes tactiles adaptées à l’environnement opérationnel (compatibilité avec le port de gants de protection, résistance aux ambiances humides voire corrosives, etc.), des présentations extérieures conformes aux normes du secteur visé (boitier en inox dans la pharmaceutique ou l’agro-alimentaire, connexions spécialement protégées dans les zones classées ATEX, etc.) et enfin, des exigences qui s’inscrivent dans les bonnes pratiques comme une faible consommation énergétique.

Toutes ces caractéristiques matérielles revêtent bien sûr une grande importance pour les opérateurs, tout spécialement lorsque celles-ci répondent à des normes qui participent de leur sécurité. Alors que les prérequis physiques vont spécialiser l’équipement aux conditions rencontrées sur certaines installations industrielles et donc réduire en quelque sorte son domaine d’application, l’intégration de fonctions lui apportant une certaine intelligence, vont au contraire élargir considérablement ses possibilités d’utilisation.

Thin client versus Web client

Comme nous venons de le voir, le moniteur qui compose le coeur de l’IHM, est une fenêtre qui s’ouvre aujourd’hui sur un large horizon, c’està- dire, sur la myriade d’applications susceptibles de s’exécuter localement ou à distance sur tel serveur ou telle station de travail connecté au réseau.

Pour qu’un écran soit en mesure d’afficher des informations (textes, tableaux, jauges, graphiques, etc.) provenant éventuellement de différentes sources et de différentes applications, il est indispensable que ce dernier dispose d’un logiciel lui permettant de signaler aux sources distantes ce que sont, ses capacités matérielles (disponibilité, résolution, périphériques d’entrée, etc.). Mais il faut aussi que ledit logiciel propose un cadre formel pour l’exploitation des informations reçues par le moniteur, c’est-à-dire essentiellement, une manière de les disposer sur l’écran.

C’est typiquement le modèle clients serveur cher aux informaticiens. Pour que l’horizon de la fenêtre ne soit pas étriqué, il est primordial que le client s’appuie sur un modèle aussi ouvert que possible, supporté par de nombreux acteurs et qui dispose d’une large communauté d’utilisateurs. Il faut enfin, qu’un tel client puisse s’exécuter sur des configurations matérielles simples et relativement peu puissantes ; c’est pourquoi on parle le plus souvent de thin client ou en français, de client-léger.

Un client-léger est un logiciel qui nécessite moins de puissance de traitement que celle délivrée par un ordinateur personnel même d’entrée de gamme. Un client-léger est un dispositif d’entrée et de sortie simple qui s’en remet à la puissance de calcul embarquée dans le système (PC, station de travail, automate, etc.) qui lui sert de serveur pour la gestion et le traitement de données ainsi que pour leur stockage.

Les IHM équipées de d’un client-léger, offrent plus de fiabilité et plus de sécurité. Elles ne nécessitent qu’une maintenance réduite et consomme généralement beaucoup moins d’énergie qu’un poste de travail classique ; ce qui réduit très sensiblement le coût global de possession (TCO).

Retour vers le futur

Né à la fin des années 60, le terminal VT-52 faisant défiler des suites de lignes de texte est en quelque sorte l’ancêtre des clients-légers. Il appartient heureusement à l’histoire ancienne, les clients-légers actuels ayant heureusement adopté la couleur ainsi que les interfaces graphiques fenêtrées qu’ils permettent de piloter à la souris ou… au doigt. On fait entrer dans la catégorie des clients-légers, les terminaux embarquant un logiciel permettant de tirer parti à distance d’un bureau virtuel tel que celui d’un serveur Windows ou Linux au travers d’un protocole d’affichage. Dans les systèmes dérivés d’Unix tels que Linux Debian ou FreeBSD, le serveur d’interface X Window est une fonction de base.

Pour les applications s’exécutant sous Windows, il est presque incontournable de disposer d’un terminal supportant le protocole RDP (Remote Desktop Protocol). Reste que la seule présence de ce dernier, ne suffit pas. Il faut aussi disposer d’une couche d’affichage qui sera plus ou moins complexe et donc, plus ou moins lourde à exécuter. Deux PC fonctionnant sous Windows par exemple, pourront évidemment afficher les fenêtres correspondant aux applications exécutées sur celui qui est à l’autre extrémité du réseau ; il dispose en effet, de la totalité des éléments d’interface possibles et imaginables dans l’environnement graphique de Microsoft mais à condition bien sûr de disposer d’un processeur puissant et d’un volume de mémoire non négligeable.

Une IHM qui supportera le protocole RDP, devra en outre intégrer une couche logicielle lui permettant de reproduire les composants d’interface nécessaires à l’affichage des données et au pilotage de l’application. Il existe donc différents clients-légers supportant les applications s’exécutant sous Windows parmi lesquelles on peut notamment citer Citrix XenApp et Citrix XenDesktop ou encore VMware View.

Les saisies et les commandes de l’utilisateur entrées depuis l’IHM sont envoyées vers le poste de travail virtuel (serveur, station de travail, poste de commande, automate, etc.) pour leur traitement tandis que le client-léger embarqué affiche les résultats que ce dernier lui retourne. Les dernières technologies de virtualisation associée à des fonctions de contextualisation intégrées aux applications savent s’appuyer sur des technologies comme le streaming pour distribuer des séquences audio ou vidéo aux opérateurs.

Une opération de rechargement de machines sur une ligne d’assemblage, le contrôle obligatoire d’un dispositif donné ou une opération de maintenance programmée peut être associée à l’affichage d’une séquence vidéo qui servira de guide pas-à-pas avec pause en attente de validation à chaque étape cruciale. L’IHM n’est ainsi plus seulement le dispositif de suivi et de contrôlecommande que nous connaissons depuis des années mais elle se mue en un véritable relais des bonnes pratiques et participe au respect des procédures internes.

Microsoft a multiplié les plateformes dédiant des systèmes à différentes familles d’équipements tout en assurant la promotion de nouvelles solutions sans qu’une vraie stratégie soit toujours bien lisible pour les utilisateurs. C’est ainsi qu’on trouve dans différentes familles d’équipements industriels reposant sur Windows CE, Windows Embedded Standard (Win32), Windows Embedded 7 et encore plus récemment Windows 10 IoT… Si Windows est peu ou prou synonyme de compatibilité sur PC que l’on parle de serveurs ou de stations de travail, il en va tout autrement au niveau des applications s’adressant aux systèmes pour terminaux mobiles estampillés, Microsoft. C’est le clientléger associé au protocole RDP qui en quelque sorte, universalise les possibilités d’utilisation des applications.

Le navigateur Web, client-léger universel ?

Certes il existe une foule d’applications conçues pour s’exécuter sous Windows ou l’un de ses avatars et tout autant de programmes délivrant leurs informations vers des fenêtres X Window sous Linux ou MacOS X. Néanmoins c’est désormais l’interface Web/HTML5 qui est le champion toute-catégorie de l’affichage des données délivrée à distance par un serveur.

Si au départ le langage HTML n’est qu’un environnement permettant de codifier la présentation des données sous la forme d’une page, HTML5 (HyperText Markup Language 5) associe un ensemble de technologies issues de la Toile mondiale comme les feuilles de style en cascade en version CSS3 et le langage JavaScript, un langage permettant de créer des scripts en s’appuyant sur la force de la programmation orientée objets.

On peut alors délivrer des informations vers une IHM en ayant recours à des pages HTML dynamiques (DHTML) générées à la volée par le serveur ou les serveurs. Il faut donc que cette dernière intègre un navigateur Web ainsi qu’une machine virtuelle Java, lui permettant d’exécuter les scripts qui sont intégrés dans les pages HTML. Cette association permet d’effectuer des tâches complexes comme des mises en forme conditionnelles, la création d’objets graphiques en fonction des données collectées sur les machines ou reçues du serveur, la lecture de contenus enrichis (rich content) comme des séquences multimédias (vidéos, animations, etc.). Il est même possible de s’appuyer sur ces seules ressources numériques pour encapsuler les écrans et les éléments d’interface issus d’une application s’exécutant sous Windows. De cette manière, le couple HTML5/Java peut se transformer en client-léger Windows-RDP… l’inverse en revanche, n’est pas nécessairement vrai.