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’adress
nt 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.
