FR2950448A1

FR2950448A1 - Procede de mise en oeuvre d'un programme d'interface homme-machine

Info

Publication number: FR2950448A1
Application number: FR0956417A
Authority: FR
Inventors: Philippe Nappey; Marc Leconte; Herald Letoret
Original assignee: Schneider Electric Industries SAS
Current assignee: Schneider Electric Industries SAS
Priority date: 2009-09-18
Filing date: 2009-09-18
Publication date: 2011-03-25
Anticipated expiration: 2029-09-18
Also published as: FR2950448B1

Abstract

L'invention concerne un procédé de mise en oeuvre d'un programme d'interface homme-machine exécuté dans un poste client doté d'un navigateur Internet. Le procédé comporte une étape de découverte de plusieurs modules applicatifs de type gadget mémorisés dans plusieurs équipements d'automatisme connectés au poste client, l'étape de découverte étant exécutée à l'aide de services WEB conformes à la spécification WS-Discovery, une étape de mémorisation dans le poste client de modules applicatifs découverts, une étape d'agencement dans un conteneur WEB de modules applicatifs mémorisés dans le poste client pour former le programme d'interface homme-machine, et une étape d'exécution du programme d'interface homme-machine dans le poste client à partir du navigateur Internet.

Description

Procédé de mise en oeuvre d'un programme d'interface homme-machine

La présente invention se rapporte à un procédé de mise en oeuvre d'un programme d'interface homme-machine sur un poste client à partir de plusieurs modules applicatifs qui sont répartis dans différents équipements d'automatisme, connectés au poste client. Sous le terme "équipement d'automatisme", on désignera ci-après un automate programmable, une commande numérique, une station de 1 o contrôle/commande mais aussi tout équipement ou module d'automatisme possédant au moins une unité de traitement, capable de se connecter sur un réseau de communication, et capable d'offrir une ou plusieurs fonctions d'automatisme dans une application d'automatisme. Par exemple, on inclura dans cette définition un module métier ou un module d'entrées/sorties déportées d'un automate programmable, un 15 variateur de vitesse, un appareil de gestion et surveillance d'un réseau électrique, etc.... Un tel équipement d'automatisme peut être utilisé dans toute application d'automatisme appartenant notamment au domaine des automatismes industriels, des automatismes du bâtiment, des infrastructures ou du contrôle/commande des réseaux 20 électriques de distribution. Un tel équipement d'automatisme comporte des moyens de connexion à un réseau de communication IP, c'est-à-dire à un réseau de communication conforme au protocole IP (Internet Protocol). Le protocole IP est le protocole le plus couramment utilisé aujourd'hui dans les réseaux de communication de type Internet, Intranet ou Extranet, notamment en combinaison avec les protocoles 25 de couche transport TCP (Transmission Control Protocol) ou UDP (User Datagram Protocol). Pour pouvoir piloter, commander, configurer, surveiller, visualiser, superviser ou diagnostiquer efficacement une application d'automatisme, les utilisateurs ont besoin notamment de se connecter à différents équipements d'automatisme de 30 l'application d'automatisme, de collecter un certain nombre d'informations venant de ces équipements, d'envoyer éventuellement des informations/commandes vers ces équipements et de visualiser l'ensemble de ces données sous forme interprétable (graphique) à partir d'un poste client, tel que par exemple un ordinateur individuel, un téléphone mobile, un Smartphone ou un appareil de type PDA (Persona) Digital Assistant), connecté aux différents équipements d'automatisme via un réseau de communication IP.

Une première solution connue pour répondre à ce besoin est l'implémentation d'un serveur web embarqué dans les différents équipements d'automatisme, comme indiqué dans le document US5805442. A partir d'un simple navigateur Internet sur le poste client, il est alors possible par exemple de télécharger une page WEB hébergée dans le serveur WEB de cet équipement d'automatisme. Cependant, l'interface 1 o Homme-Machine du poste client permet généralement de visualiser une seule page WEB à la fois, ce qui fait qu'un écran du poste client ne peut visualiser que des données provenant d'une page WEB d'un seul équipement à la fois. De plus, les pages d'écran sont difficilement personnalisables. Une autre solution classique pour répondre à ce besoin est d'installer une 15 application d'interface homme-machine dédiée sur le poste client, tel qu'une application de supervision de type SCADA (Supervisory Control And Data Acquisition). Cette application est alors un programme exécutable autonome qui est installé sur le poste client. Il est alors facile de disposer sur un même écran du poste client des données provenant de différents équipements. Cependant, chaque mise à jour de 20 l'application nécessite généralement l'installation ou le remplacement de composants logiciels sur le poste client avec les risques que cela implique en termes de compatibilité, fiabilité et support notamment. La technologie des services WEB est une technologie qui est largement 25 répandue dans les applications informatiques de niveau entreprise. Cette technologie est à la base des architectures orientées services (SOA), permettant de bâtir des applications plus rapidement mais aussi améliorant les capacités de maintenance et d'évolution. L'utilisation de cette technologie dans les applications d'automatisme permet d'embarquer dans les équipements d'automatisme plus d'intelligence, pour 30 notamment offrir des fonctions de diagnostic et de maintenance évoluées, mais simples pour l'utilisateur et avec un niveau d'interface plus élevé. Cette utilisation est rendue aujourd'hui possible grâce au profil de WEB Services «DPWS». La spécification DPWS (Devices Profile for WEB Services û voir htt•:/<s•ecs.xmisoa+.or./ ws/2006/02/devprof/) définit une architecture permettant de sécuriser et standardiser les échanges au moyen de services WEB entre des appareils ou équipements (devices). La spécification DPWS est basée notamment sur le protocole SOAP (Simple Object Access Protocol) et le langage WSDL (Web Services Description Language). Elle spécifie un certain nombre de spécifications et requêtes, telles que : WS-Adressing pour un mécanisme d'adressage des services WEB, WSDiscovery proposant un mécanisme de découverte d'équipements raccordés sur un réseau local IP, WS-Eventing pour la gestion d'événements, WS-Metadataexchange pour des échanges de données et de description de services, etc...

Un conteneur WEB (ou WEB container) est une page WEB de framework capable d'héberger des gadgets. Ce conteneur WEB va servir de point d'entrée vers l'application d'automatisme pour l'utilisateur, il va également servir d'interface entre le navigateur Internet et les gadgets. Un gadget, ou widget, désigne une petite application graphique d'interface homme-machine qui est interactive. Dans le cadre du présent document, un gadget est également appelé module applicatif. Un gadget est capable de s'afficher et de s'exécuter sur une partie d'écran du poste client, et de proposer des animations en liaison avec différents paramètres ou informations d'un équipement d'automatisme. Pour communiquer avec un équipement d'automatisme, un gadget envoie à l'équipement d'automatisme des requêtes sous la forme de services WEB. Ces requêtes peuvent être mises en forme par le conteneur WEB, mais sont préférentiellement envoyées directement à partir du navigateur Internet du poste client vers l'équipement d'automatisme. Par ailleurs, un gadget s'appuie sur la technologie WEB 2.0 et peut par exemple faire appel à des bibliothèques graphiques mémorisées dans le poste client (telles que Flash Player d'Adobe ou Silverlight de Microsoft) pour présenter des animations graphiques évoluées sur le poste client. Le document «Bringing Internet Architectures into the Plant : the Case of HMI» - de Alessandro Bozzon, Marco Brambilla, Piero Fraternali et Paolo Speroni, October 16, 2006 - explore l'utilisation de technologies WEB issues du monde informatique pour l'interface homme-machine d'un système d'automatisme industriel. L'interface est téléchargée à partir d'un serveur WEB embarqué dans l'un des équipements; elle est configurable à l'aide d'un éditeur de configuration (topologie du système, variables à contrôler, présentation des pages,...) et personnalisable par l'utilisateur (préférences graphiques, périmètre applicatif,...). Cependant, le document ne fait pas référence à la découverte automatique de modules applicatifs dans des équipements d'automatisme ni à leur agencement dans un conteneur WEB pour former un programme d'interface homme-machine à partir de plusieurs modules applicatifs répartis. Un but de l'invention est donc de proposer un procédé de mise en oeuvre d'un programme d'interface homme-machine, qui évite les inconvénients décrits ci-dessus, c'est-à-dire qui ne nécessite pas d'installation d'un logiciel spécifique sur le poste client 1 o et qui soit suffisamment souple pour permettre facilement la personnalisation de l'interface homme-machine du poste client. Ce procédé permet de mettre en oeuvre un programme d'interface homme-machine de façon simple, à partir de modules applicatifs répartis dans plusieurs équipements d'automatisme. Pour cela, l'invention décrit un procédé de mise en oeuvre d'un programme 15 d'interface homme-machine exécuté dans un poste client doté d'un navigateur Internet. Le procédé comporte une étape de découverte de plusieurs modules applicatifs mémorisés dans plusieurs équipements d'automatisme qui sont connectés au poste client au travers d'un réseau local de communication IP, un module applicatif étant une application graphique interactive de type gadget, l'étape de découverte étant 20 exécutée à l'aide de services WEB conformes à la spécification WS-Discovery. Le procédé comporte également une étape de mémorisation dans le poste client de modules applicatifs découverts durant l'étape de découverte, une étape d'agencement dans un conteneur WEB de modules applicatifs mémorisés dans le poste client pour former le programme d'interface homme-machine, une étape d'exécution du 25 programme d'interface homme-machine dans le poste client à partir du navigateur Internet. Selon une caractéristique, l'étape de découverte est effectuée par un des équipements d'automatisme connectés au poste client, appelé équipement d'automatisme serveur, à l'aide de services WEB conformes à la spécification WS- 30 Discovery, l'équipement d'automatisme serveur fournissant au poste client une liste des modules applicatifs découverts. Selon une autre caractéristique, le procédé comporte également une étape initiale permettant de charger dans le navigateur Internet du poste client un conteneur WEB qui est mémorisé dans l'équipement d'automatisme serveur.

Pour l'utilisateur d'un poste client, la solution proposée par l'invention présente notamment les avantages suivants : Simplicité de l'interface homme-machine : il n'est plus nécessaire pour l'utilisateur d'installer et de maintenir une application spécifique sur chaque poste client. L'interface homme-machine s'appuie sur la standardisation des services WEB : plug-and-play, interopérabilité avec d'autres applications de services WEB,... Extensibilité de l'interface homme-machine : possibilité de prendre en compte 1 o automatiquement un nouveau module applicatif, suite à la mise à jour d'un module applicatif d'un équipement présent ou la connexion d'un nouvel équipement d'automatisme. Evolutivité de l'interface homme-machine : possibilité d'ajouter dynamiquement sur l'écran des modules applicatifs proposant des fonctionnalités évoluées afin 15 d'enrichir l'interface utilisateur. Personnalisation de l'interface homme-machine : possibilité pour chaque utilisateur de choisir les modules applicatifs qui lui sont utiles et de configurer sa propre interface homme-machine en fonction de ces modules applicatifs utiles. 20 D'autres caractéristiques et avantages vont apparaître dans la description détaillée qui suit en se référant à un mode de réalisation donné à titre d'exemple et représenté par les dessins annexés sur lesquels : la figure 1 montre une architecture d'une application d'automatisme, 25 la figure 2 représente de façon simplifiée la composition de l'interface homme-machine conforme à l'invention, à partir de modules distribués. En référence à la figure 1, un poste client 10, qui est à titre d'exemple un ordinateur individuel, un téléphone mobile, un Smartphone ou un appareil de type 30 PDA, est connecté, via un réseau local de communication IP 5, à plusieurs équipements d'automatisme 20, 30, 40 qui sont chargés de gérer une application d'automatisme quelconque. Le poste client 10 comporte un écran 11 et est destiné à être utilisé comme interface homme-machine (ou interface utilisateur). Le poste client 10 est doté d'un navigateur Internet (ou navigateur WEB tel que Internet Explorer de 35 Microsoft, Firefox de Mozilla ou Safari d'Apple) qui exécute un programme d'interface homme-machine permettant à un utilisateur de notamment piloter, commander, configurer, surveiller, superviser, visualiser ou diagnostiquer efficacement tout ou partie de l'application d'automatisme. Le programme d'interface homme-machine est composé de plusieurs modules applicatifs 21, 22, 31, 41 de type gadgets qui peuvent communiquer avec les équipements d'automatisme 20, 30, 40 au moyen de services WEB en utilisant le protocole TCP/IP sur le réseau local 5. Ces modules applicatifs permettent ainsi de lire et d'écrire des données et informations mémorisées dans les équipements d'automatisme 20, 30, 40, en lançant des requêtes applicatives définies en tant que services WEB. L'interface homme-machine est donc fragmentée en plusieurs modules applicatifs qui peuvent être positionnés à différents emplacements sur l'écran du poste client. Un module applicatif ou gadget est une petite application graphique interactive possédant les caractéristiques suivantes : elle est mémorisée dans une mémoire d'un équipement d'automatisme et est téléchargeable dans un poste client à partir de cet équipement d'automatisme; elle est indépendante pour son exécution de l'équipement d'automatisme à partir duquel elle a été téléchargée; elle est configurable, notamment pour choisir le ou les équipements d'automatisme avec lesquels elle va communiquer; elle s'exécute directement à partir du navigateur Internet du poste client au sein d'un conteneur WEB sans installation préalable de logiciel sur ce poste client et de manière indépendante et asynchrone par rapport à un autre module applicatif du poste client. Il pourrait s'agir par exemple d'un module de gestion des alarmes d'un disjoncteur ou encore d'un module de suivi des données de consommation électrique en temps réel d'un appareil de mesure.

Pour mettre en oeuvre un programme d'interface homme-machine exécuté dans le poste client 10, l'invention prévoit une étape de découverte dont le but est de découvrir une liste de modules applicatifs qui sont mémorisés dans les différents équipements d'automatisme 20, 30, 40 connectés au réseau local IP 5. Avantageusement, l'étape de découverte est réalisée à l'aide de services WEB conformes à la spécification WS-Discovery, qui permet à des équipements connectés au sein d'un réseau local IP de se découvrir mutuellement. Contrairement à une application informatique classique, l'étape de découverte est tout à fait réalisable dans le contexte particulier d'un réseau local, par exemple dans le cadre d'une application d'automatisme industriel, puisque la découverte est alors limitée au voisinage du poste client (sous-réseau IP ou lien IP). Une telle étape serait en effet techniquement difficilement réalisable dans le cadre plus général d'équipements connectés à un réseau global Internet.

Cependant, le mécanisme de découverte d'équipements par des services WEB qui est décrit dans la spécification WS-Discovery s'appuie sur la couche transport UDP (User Datagram Protocol) afin de permettre la diffusion généralisée (multicasting) des requêtes de découverte. Or, un navigateur Internet standard ne peut utiliser uniquement que le protocole HTTP, lequel s'appuie sur la couche transport TCP (Transmission Control Protocol). Un navigateur Internet ne peut donc pas utiliser en standard la couche transport UDP et ne peut donc pas lancer directement une découverte d'équipements, selon la spécification WS-Discovery. Selon un premier mode de réalisation, l'étape de découverte est effectuée à partir du poste client en installant sur le poste client une application chargée de la découverte des modules applicatifs d'équipements d'automatisme connectés localement et chargée ensuite de partager les résultats de cette découverte avec le conteneur WEB, par exemple de préférence au travers du système de fichiers du poste client, ou éventuellement à travers un mécanisme d'interface logicielle tel que des sockets. L'inconvénient de ce premier mode de réalisation est la nécessité d'installer une application sur le poste client. Un deuxième mode de réalisation serait d'utiliser une technologie particulière d'application WEB appelée JavaFx, qui s'appuie notamment sur un environnement temps réel (JRE - Java Runtime Environment) capable de s'exécuter hors navigateur. Cela permettrait au conteneur WEB, qui est alors réalisé en JavaFx, de pouvoir lancer une requête de type WS-Discovery puis de partager les résultats de cette découverte avec les différents gadgets, eux-mêmes réalisés en JavaFx. L'inconvénient est que ce mode de réalisation nécessite l'installation de l'environnement JRE (Java Run-time Environment) sur le poste client et devient dépendant d'une technologie donnée (JavaFx).

Selon un troisième mode de réalisation préféré, le navigateur Internet du poste client 10 est capable de pointer sur l'adresse URL (Uniform Resource Locator) de l'un des équipements d'automatisme connecté au poste client par le réseau de communication IP et nommé par la suite "équipement d'automatisme serveur" 20 ou "équipement serveur". L'étape de découverte est alors effectuée par cet équipement d'automatisme serveur 20 à l'aide de services WEB conformes à la spécification WSDiscovery. Une fois que l'équipement d'automatisme serveur 20 a découvert les différents modules applicatifs mémorisés dans les équipements d'automatisme 20, 30, 40 connectés au réseau local 5, il fournit au poste client une liste de ces modules applicatifs découverts. Ainsi, le navigateur du poste client 10 délègue à l'équipement serveur 20 la tâche de découvrir au moyen de WS-Discovery les modules applicatifs disponibles, en utilisant le protocole UDP. De plus, cet équipement d'automatisme serveur 20 peut mémoriser un 1 o conteneur WEB, qui est une page WEB capable d'héberger des gadgets. Dans le cas où le poste client 10 ne mémorise pas déjà un tel conteneur WEB, le procédé comporte alors une étape initiale, durant laquelle l'utilisateur du poste client 10 pointe son navigateur Internet vers l'adresse URL de l'équipement serveur 20, et charge le conteneur WEB dans le navigateur Internet du poste client, de façon classique à l'aide 15 du protocole HTTP. L'étape de découverte peut être effectuée automatiquement après l'étape initiale. De plus, cette étape de découverte peut également être lancée automatiquement de façon périodique ou être lancée à l'initiative d'un utilisateur du poste client 10, de manière à obtenir une mise à jour régulière des modules applicatifs 20 disponibles. Le procédé comporte ensuite une étape de mémorisation dans le poste client 10 de plusieurs modules applicatifs découverts durant l'étape de découverte. La liste des modules applicatifs découverts dans les différents équipements d'automatisme 20, 25 30, 40 est dans un premier temps affichée sur l'écran du poste client, de façon à ce que l'utilisateur puisse effectuer une étape de sélection, parmi les modules applicatifs découverts, de ceux qu'il souhaite utiliser pour mettre en oeuvre son programme d'interface homme-machine. L'étape de mémorisation d'un module applicatif n'est donc préférentiellement effectuée que pour les modules applicatifs qui sont 30 sélectionnés par l'utilisateur durant l'étape de sélection. Si un module applicatif sélectionné n'est pas déjà mémorisé dans le poste client, l'étape de mémorisation comprend une étape de chargement de ce module applicatif dans la mémoire du poste client. Si un module applicatif sélectionné est déjà mémorisé dans le poste client, l'étape de mémorisation conserve ce module applicatif, il n'est pas chargé une nouvelle fois. Une fois que les modules applicatifs sélectionnés sont mémorisés dans la mémoire du poste client 10, le procédé prévoit une étape d'agencement dans le conteneur WEB de ces modules applicatifs mémorisés pour former le programme d'interface homme-machine. L'agencement permet de faire l'agrégation de plusieurs modules applicatifs sur un même écran, en utilisant les technologies WEB 2.0. L'agencement est fait par l'utilisateur qui peut ainsi librement et facilement positionner sur chaque page d'écran du poste client les différents modules sélectionnés, de façon à personnaliser son interface homme-machine. Le procédé prévoit enfin une étape d'exécution du programme d'interface homme-machine dans le poste client à partir du navigateur Internet. Une même page d'écran permet ainsi de visualiser plusieurs modules applicatifs provenant de différents équipements d'automatisme et capables de dialoguer de façon indépendante avec différents équipements d'automatisme à l'aide de services WEB. Les appels de services WEB peuvent être effectués directement à partir du navigateur Internet du poste client puisque ce sont des appels HTTP nativement supportés par les navigateurs. La figure 2 montre un exemple simplifié d'une page WEB qui est susceptible de s'afficher sur l'écran 11 du poste client 10. Différents modules applicatifs 21, 22, 31, 41 sont agencés sur une même page WEB. Ces modules applicatifs proviennent des équipements d'automatisme 20, 30, 40. Ils ont donc été découverts durant une étape de découverte, puis mémorisés dans une mémoire du poste client 10 durant une étape de mémorisation, puis agencés dans un conteneur WEB du poste client pour former le programme d'interface homme-machine qui s'exécute à partir du navigateur Internet du poste client. Les modules applicatifs 21, 22, 31, 41 peuvent alors communiquer avec les différents équipements d'automatisme 20, 30, 40 à l'aide de services WEB. Lorsqu'un utilisateur veut mettre à jour la liste des modules applicatifs des équipements d'automatisme connectés, il peut utiliser une fonction de mise à jour du conteneur WEB. Cette action a pour effet d'envoyer une requête Service WEB classique du poste client vers l'équipement serveur qui répond avec la liste mise à jour. Par contre, la stratégie de mise à jour à partir de l'équipement serveur lui-même est un choix d'implémentation : l'équipement serveur peut soit effectuer une étape de découverte de façon synchrone lorsqu'il reçoit du poste client la requête Service WEB de mise à jour, soit effectuer cette étape de découverte régulièrement et maintenir cette liste en mémoire dans l'équipement serveur. Ainsi, lorsqu'un nouvel équipement d'automatisme se connecte sur le réseau local IP 5 (ou lorsqu'un équipement d'automatisme déjà connecté propose un nouveau module applicatif), les modules applicatifs mémorisés dans ce nouvel équipement d'automatisme sont découverts durant une étape de découverte. Les nouveaux modules applicatifs découverts peuvent ensuite être affichés sur l'écran du poste client 10 et l'utilisateur peut alors sélectionner ceux qu'il souhaite intégrer dans son programme d'interface homme-machine, pour qu'ils soient téléchargés dans le poste 1 o client. L'utilisateur pourra alors agencer ces modules applicatifs sélectionnés au sein du conteneur WEB pour former le nouveau programme d'interface homme-machine.

Claims

REVENDICATIONS1. Procédé de mise en oeuvre d'un programme d'interface homme-machine exécuté dans un poste client (10) qui est doté d'un navigateur Internet, caractérisé en ce que le procédé comporte : une étape de découverte de plusieurs modules applicatifs mémorisés dans plusieurs équipements d'automatisme (20,30,40) qui sont connectés au poste client (10) au travers d'un réseau local de communication IP (5), un module applicatif étant une application graphique interactive de type gadget, l'étape de découverte étant exécutée à l'aide de services WEB conformes à la spécification WS-Discovery, une étape de mémorisation dans le poste client (10) de modules applicatifs découverts durant l'étape de découverte, une étape d'agencement dans un conteneur WEB de modules applicatifs (21,22,31,41) mémorisés dans le poste client (10) pour former le programme d'interface homme-machine, une étape d'exécution du programme d'interface homme-machine dans le poste client (10) à partir du navigateur Internet.
2. Procédé de mise en oeuvre selon la revendication 1, caractérisé en ce que l'étape de découverte est effectuée par un des équipements d'automatisme connectés au poste client, appelé équipement d'automatisme serveur (20), à l'aide de services WEB conformes à la spécification WS-Discovery, l'équipement d'automatisme serveur (20) fournissant au poste client (10) une liste des modules applicatifs découverts.
3. Procédé de mise en oeuvre selon la revendication 2, caractérisé en ce que le procédé comporte également une étape initiale permettant de charger dans le navigateur Internet du poste client (10) un conteneur WEB qui est mémorisé dans l'équipement d'automatisme serveur (20).
4. Procédé de mise en oeuvre selon la revendication 3, caractérisé en ce que l'étape de découverte est effectuée automatiquement après l'étape initiale.
5. Procédé de mise en oeuvre selon l'une des revendications précédentes, caractérisé en ce que l'étape de découverte est effectuée de façon périodique.
6. Procédé de mise en oeuvre selon l'une des revendications précédentes, caractérisé en ce que l'étape de découverte est effectuée à la demande d'un utilisateur du poste client.
7. Procédé de mise en oeuvre selon l'une des revendications précédentes, caractérisé en ce que les modules applicatifs découverts durant l'étape de découverte sont affichés sur le poste client.
8. Procédé de mise en oeuvre selon la revendication 7, caractérisé en ce que le procédé comporte une étape de sélection, par un utilisateur du poste client, de plusieurs modules applicatifs découverts durant l'étape de découverte.
9. Procédé de mise en oeuvre selon la revendication 8, caractérisé en ce que l'étape de mémorisation d'un module applicatif n'est effectuée que pour les modules applicatifs sélectionnés durant l'étape de sélection.
10. Procédé de mise en oeuvre selon la revendication 9, caractérisé en ce que l'étape de mémorisation d'un module applicatif sélectionné comporte une étape de chargement qui n'est effectuée que lorsque le module applicatif sélectionné n'est pas déjà mémorisé dans la mémoire du poste client.