FR2898697A1 - Procede et dispositif de communication entre un equipement et un serveur - Google Patents

Abstract

Le procédé de communication entre un équipement et un serveur distant comporte :- une étape (205) d'association d'un module électronique doté d'un contrôleur programmable avec ledit équipement de telle manière que ledit module reçoive des signaux représentatifs d'états ou de paramètres de fonctionnement dudit équipement ;- une étape (210) d'implantation d'une application de serveur de communication sur ledit module électronique, ladite application de serveur de communication étant adaptée à communiquer avec ledit module ;- une étape (230) de transmission d'une requête depuis ledit serveur distant à destination dudit module et- une étape (235) de réponse à ladite requête, de la part dudit module et à destination dudit serveur distant, ladite réponse encapsulant des informations représentatives desdits états ou paramètres dudit équipement.

Description

PROCEDE ET DISPOSITIF DE COMMUNICATION ENTRE UN EQUIPEMENT ET UN SERVEUR

10 La présente invention concerne un procédé et un dispositif de communication entre un équipement et un serveur. Elle s'applique, en particulier, au contrôle et à la commande, à distance, d'équipements bureautiques, domestiques ou industriels, et de véhicules ou de bâtiments. Dans le domaine du contrôle et de la commande à distance d'un équipement, 15 généralement, un opérateur de surveillance fait régulièrement un passage de maintenance pour vérifier le bon fonctionnement de l'équipement et, en cas de défaut, alerter un service technique. Cette procédure présente de nombreux inconvénients. D'une part, le délai de détection d'une panne peut être important et, d'autre part, la qualité d'intervention du service technique est soumise à la qualité du rapport transmis par l'opérateur de surveillance. 20 Dans des systèmes plus automatisés, il est connu de munir l'équipement d'un module de communication à distance qui surveille l'état de l'équipement et qui, en fonction de franchissement de seuils, déclenche une alarme sur un terminal distant, par exemple en émettant un mini-message, connu sous le nom de SMS (pour short message system ou système de message court) à destination du téléphone mobile d'un responsable d'entretien. 25 Ces systèmes présentent de nombreux inconvénients. D'une part, ils ne permettent pas une gestion centralisée d'un ensemble d'équipements. D'autre part, ils sont soumis à la disponibilité du réseau de communication de l'alarme. De plus, ils demandent, pour leur programmation, l'intervention d'un informaticien qualifié. Enfin, ils ne peuvent pas être reprogrammés à distance. 30 La présente invention vise à remédier à ces inconvénients. A cet effet, selon un premier aspect, la présente invention vise un procédé de communication entre un équipement et un serveur distant, caractérisé en ce qu'il comporte : - une étape d'association d'un module électronique doté d'un contrôleur programmable avec ledit équipement de telle manière que ledit module reçoive des signaux 35 représentatifs d'états ou de paramètres de fonctionnement dudit équipement ; - une étape d'implantation d'une application de serveur de communication sur ledit module électronique, ladite application de serveur de communication étant adaptée à communiquer avec ledit module ; - une étape de transmission d'une requête depuis ledit serveur distant à destination dudit module et une étape de réponse à ladite requête, de la part dudit module et à destination dudit serveur distant, ladite réponse encapsulant des informations représentatives desdits états ou paramètres dudit équipement. Grâce à ces dispositions, on peut accéder aux paramètres et états de l'équipement en mettant en oeuvre un navigateur et on peut visualiser ces états et paramètres dans une page, sans formation préalable de l'opérateur. De plus, en prévoyant des requêtes émises par le serveur à destination du module à intervalle de temps régulier, ou en programmant le module pour qu'il initie une communication en cas de détection d'événements prédéterminés, on peut gérer, de manière centralisée, le contrôle dudit équipement.

Selon des caractéristiques particulières, au cours de l'étape de transmission d'une requête depuis le serveur distant à destination du module, ladite requête est une requête de logiciel de navigation sur la toile. Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte, en outre, une étape d'affichage d'au moins une information représentative desdits états ou paramètres dudit équipement. Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une étape de comparaison desdits états ou paramètres avec des valeurs prédéterminées et, en fonction du résultat de ladite étape de comparaison, une étape de déclenchement d'une alarme.

Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une étape de sélection d'un canal de communication entre le module électronique et ledit serveur distant, en fonction de caractéristiques des données à transmettre et des canaux de communications disponibles, au moins l'une des étapes de transmission d'une requête et de réponse à ladite requête étant effectuée en mettant en oeuvre le canal de communication sélectionné. Selon un deuxième aspect, la présente invention vise un dispositif de communication entre un équipement et un serveur distant, caractérisé en ce qu'il comporte : - un contrôleur programmable associé avec ledit équipement de telle manière que ledit contrôleur reçoive des signaux représentatifs d'états ou de paramètres de fonctionnement dudit équipement ; - un moyen d'implantation d'une application de serveur de communication comportant : o un moyen de communication avec ledit équipement ; o un moyen de réception de requêtes depuis ledit serveur distant et o un moyen de réponse à ladite requête, à destination dudit serveur distant, ladite réponse encapsulant des informations représentatives desdits états ou paramètres dudit équipement.

Les avantages, buts et caractéristiques particulières de ce dispositif étant similaires à ceux du procédé tel que succinctement exposé ci-dessus, ils ne sont pas rappelés ici. D'autres avantages, buts et caractéristiques de la présente invention ressortiront de la description qui va suivre, faite, dans un but explicatif et nullement limitatif en regard des dessins annexés dans lesquels : - la figure 1 représente, schématiquement, une implantation d'un mode de réalisation particulier du dispositif objet de la présente invention, - la figure 2 représente, sous forme d'un logigramme, un mode de réalisation particulier du procédé objet de la présente invention et - la figure 3 représente, sous forme d'un logigramme, un mode de réalisation particulier d'un procédé de programmation du dispositif objet de la présente invention. On observe, en figure 1, un équipement à superviser 100, un module électronique 110 associé à l'équipement 100 et comportant un contrôleur 115 et, préférentiellement, au moins deux moyens de communication 120 et 125, deux canaux de communication 130 et 135, un serveur d'exploitation 140, comportant deux moyens de communication 155 et 160 et un contrôleur 170 et conservant une base de données 145, un terminal de programmation 150 comportant un moyen de communication 165 et un terminal client 180 comportant un moyen d'affichage (non représenté) des données reçues de la part du serveur 140. L'équipement à superviser 100 peut être fixe comme, par exemple, une chaudière, un équipement bureautique ou un panneau d'affichage électronique, ou mobile comme, par exemple, un équipement d'un véhicule d'une flotte de véhicules. Préférentiellement, l'équipement 100 comporte un contrôleur 101 et met en oeuvre des logiciels, en particulier pour contrôler l'état de capteurs 102 et/ou d'actionneurs 104 et pour communiquer par l'intermédiaire d'au moins un connecteur 103. Le module électronique 110 est adapté à recevoir, par l'intermédiaire du connecteur 103, des données de la part de l'équipement 100 et notamment des signaux représentatifs d'états ou de paramètres de fonctionnement dudit équipement 100. Le module électronique 110 est également adapté à envoyer des commandes à l'équipement 100, par l'intermédiaire du connecteur 103. Par ailleurs, les moyens de communication 120 et 125 permettent au module électronique 110 de communiquer, par l'intermédiaire des deux canaux de communication 130 et 135, avec le serveur 140 et, éventuellement, avec le terminal de programmation 150, sachant qu'un autre canal (non représenté) peut être utilisé pour la communication entre le module électronique 110 et le terminal de programmation 150. Les canaux de communication 130 et 135 sont, par exemple, des réseaux de téléphonie sans fil, par exemple de type GSM et GPRS, respectivement. Le module électronique 110 est adapté à télécharger des logiciels par l'intermédiaire de l'un, au moins, des réseaux 130 et 135 à partir du serveur 140 et/ou du terminal de programmation 150, sous commande extérieure, telle qu'un logiciel tiers ou un SMS. Le serveur 140 est de type connu et est adapté à interroger chaque module 110, à recevoir ses réponses, à agréger les données reçues et à déclencher des consignes ou des alarmes, en fonction des données reçues ou des données agrégées. Le serveur 140 est aussi adapté à fournir des données à des terminaux clients en se comportant comme serveur de la toile. Le terminal de programmation 150 est adapté à programmer des applications pour chaque module 110 et des applications pour chaque serveur 140. Le terminal de programmation 150 met en oeuvre une suite de développement détaillée plus loin dans la description. Le module électronique 110 et le serveur 140 et, plus précisément, les contrôleurs 115 et 170 sont adaptés à mettre en oeuvre, entre eux, le procédé de communication objet de la présente invention, tel que présenté en regard du logigramme de la figure 2, après une phase de programmation illustrée en figure 3.

Le terminal client 180, de type quelconque, téléphone mobile, assistant personnel numérique, ordinateur personnel ou serveur de réseau, par exemple, permet à un utilisateur, ou opérateur, d'accéder à la base de données 145 conservée par le serveur 140 et, en particulier, aux données concernant chacun des modules 110, après authentification et d'afficher ces données. Dans cette communication, le serveur 140 se comporte comme serveur de la toile pour permettre l'accès aux données avec une interface bien connue de tout utilisateur, c'est à dire un logiciel de navigation sur internet. On observe, en figure 2, une étape 205 d'association, selon des techniques connues, du module électronique 110 doté du contrôleur programmable 115 avec ledit équipement 100 de telle manière que ledit module électronique 110 reçoive des signaux représentatifs d'états ou de paramètres de fonctionnement dudit équipement 100. Puis, au cours d'une étape 210, on implante une application de serveur de communication, par exemple de serveur de la toile, sur le module électronique 110. Par exemple, le serveur embarqué est programmé en Java (marque déposée) et possède une taille très réduite. On observe que ce serveur embarqué, caractéristique de la présente invention, permet la supervision et le contrôle à distance du module 110 et de l'équipement associé 100. A partir de l'étape 210, le module électronique 110 se comporte comme un serveur de communication, par exemple un serveur de la toile, ou serveur web . On rappelle qu'un serveur de communication comporte un logiciel qui répond à des requêtes provenant de clients, par exemple avec des moyens de communication dits http (acronyme de hypertext transfer protocol pour protocole de transfert hypertexte) ou des minimessages, connus sous le nom de SMS (acronyme de Short Message System, pour système à messages courts). On observe que, préférentiellement, le module électronique 110 ne fournit pas de page mais des données à insérer dans des pages fournies aux clients par le serveur 140. Ces données peuvent être fournies, par exemple, en SMS. Un déclenchement de communication entre le module 110 et le serveur 140 peut avoir lieu dans différentes circonstances : - en cas de détection d'événements déclenchant, par le module 110, par exemple en fonction de seuils appliqués à des capteurs associés à l'équipement 100, étape 212 ; par exemple, le module électronique 110 effectue une étape de comparaison des états ou paramètres de l'équipement 100 avec des valeurs prédéterminées qu'il conserve en mémoire et, en fonction du résultat de l'étape de comparaison, il déclenche une alarme sous forme d'une requête émise au serveur distant 140, - en fonction d'un calendrier prédéterminé de communications entre le module 110 et le serveur 140, ce calendrier pouvant être gérer par le module 110 ou par le serveur 140 (cas exposé en figure 2, en étape 255), - en fonction de requêtes transmises par le terminal client 180, au cas où le données conservées dans la base de données 145 seraient considérées comme obsolètes au vu de la requête reçue, étapes 250. Au cours d'une étape 215, le serveur qui veut initier une communication avec l'autre serveur, c'est à dire soit le serveur de communication du module 110, soit le serveur 140, détermine le meilleur support de communication entre le module électronique 110 et le serveur 140. Au cours de cette étape 215, on considère les critères suivants dans l'ordre de priorité décroissante : la disponibilité des canaux de communication, l'urgence de transmission du flux de données à transmettre, la tarification des opérateurs qui gèrent les différents canaux de communication. Grâce à cette étape, on garantit pratiquement le maintien de la capacité de communication entre le module électronique 110 et le serveur 140, même si l'un des canaux est indisponible. En fonction du canal de communication sélectionné au cours de l'étape 215, au cours de l'étape 220, on effectue la commutation de protocole de communication correspondant, le cas échéant.

Puis, au cours d'une étape 225, on met en communication le module électronique 110 et ledit serveur distant 140, par exemple en mettant en oeuvre le protocole de transfert hypertexte http.

Au cours d'une étape 230, le serveur 140 transmet une requête à destination du module 110 qui la reçoit, par exemple en mettant en oeuvre le protocole de transfert hypertexte http. Préférentiellement, pour chaque requête reçue, le module électronique 110 vérifie, pour des raisons de sécurité, au cours de l'étape 230, l'adresse du serveur émetteur de la requête. Au cours d'une étape 235, le module électronique 110 analyse la requête reçue, récupère les données requises, notamment auprès de l'équipement 100, traite ces données et émet une réponse à destination du serveur 140. Cette réponse encapsule ainsi des informations représentatives des états ou paramètres de l'équipement 100.

Pour la description des étapes 230 et 235, on a considéré le cas où le serveur 140 initie la communication. Dans l'autre cas, dans lequel c'est le serveur de communication du module 110 qui initie la communication, l'étape 230 n'a pas lieu et, au cours de l'étape 235, le module électronique 110 récupère les données à transmettre, notamment auprès de l'équipement 100, traite ces données et émet un message à destination du serveur 140.

Cette réponse encapsule ainsi des informations représentatives des états ou paramètres de l'équipement 100. Au cours d'une étape 240, le serveur 140 agrège et distribue les données collectées depuis les différents modules électroniques 110 vers les personnes, terminaux clients, bases de données et applications informatiques concernées. Cette agrégation comporte au moins la constitution d'un historique d'états des équipements 100 associés aux modules électroniques 110 et le déclenchement d'alerte en cas de panne, de besoin de maintenance préventive, par exemple de besoin de fourniture de consommable. Ces alertes sont déterminées en fonction des informations représentatives des états ou paramètres de l'équipement 100 reçues au cours de l'étape 235 ou agrégées au cours de l'étape 240.

Lors d'une requête arrivant au serveur 140 de la part d'un terminal client 180, une base de données ou une application, au cours d'une étape 245, on vérifie que l'émetteur de cette requête est autorisé à l'émettre, selon des techniques connues. On observe que la requête émise par le terminal client 180 est une requête émise par un navigateur, le serveur 140 agissant alors en serveur de la toile.

Puis, au cours d'une étape 250, on détermine si une requête à l'équipement 110 est nécessaire, en fonction de la requête reçue et de la durée écoulée depuis la dernière mise à jour des données concernant ce module et d'au moins un paramètre de configuration du serveur. Ainsi, on évite la lecture de la mémoire du module de l'équipement ou la mémoire de l'équipement si on dispose d'information suffisamment récente, par exemple dans le cas d'une requête concernant des données dont on connaît la valeur et l'évolution possible. Par exemple, un rafraîchissement de l'état du niveau de toner chaque semaine peut suffire.

Si le résultat de l'étape 250 est positif, une requête à l'équipement 100 étant nécessaire, on passe à l'étape 215. Sinon, on passe à l'étape 255 au cours de laquelle on détermine la prochaine échéance d'une requête à adresser à l'équipement 100, on effectue la lecture des données requises par l'utilisateur, dans la base de données 145 et/ou on réalise une extrapolation des données récentes conservées dans la base de données et on fournit au terminal client 180, sous forme d'une page de la toile, les données requises par le terminal client, le terminal client affichant alors ces données. En réponse aux requêtes qu'il reçoit, le serveur 140 agrége des données provenant de bases de données et des données dynamiques physiques transmises par les modules électroniques 110, pour, par exemple, définir des fiches clients qu'il transmet à l'émetteur de la requête reçue au cours de l'étape 245. Au cours d'une étape 255, on détermine la prochaine date de requête à adresser au module électronique et lorsque cette date survient, on passe à l'étape 212. Préférentiellement, la durée considérée comme suffisante entre deux mises à jour est paramétrable. On observe, en figure 3, la mise en oeuvre d'un procédé de développement de logiciel rapide et facile pour développer, générer et déployer des applications machine à machine et programmer, connecter et gérer les équipements lointains 100 et des serveurs applicatifs 140.

Le procédé est mis en oeuvre dans un environnement de développement graphique et puissant afin de développer, générer et déployer des applications machine à machine beaucoup plus rapidement qu'avec une approche développement traditionnel et sans connaissance des langages de programmation. On minimise ainsi les coûts de développement et on maximise la productivité.

Au cours d'une étape 305, on sélectionne le module de communication 110 qui va être programmé, étant entendu que l'interfaçage physique de ce module avec un équipement 100 a été réalisé préalablement, par exemple ou cours de son installation physique. Au cours d'une étape 310, on définit un modèle de données logiques de l'application destinée à s'exécuter sur le module de communication 110. Ce modèle se réalise en définissant des équipements logiques manipulés par l'application, puis en leur ajoutant des variables représentatives de leurs caractéristiques logiques. Cette définition se fait au moyen d'écran graphique guidant l'utilisateur en lui proposant des choix pour certains paramètres et en le laissant libre pour d'autres. Ce modèle de données logiques est totalement indépendant de la physique d'acquisition des données réelles existantes. Par exemple une centrale d'alarme sera représentée par ses variables logiques Etat (booléen représentant l'état marche ou arrêt de l'alarme) et EnAlarme (booléen représentant le déclenchement ou non de l'alarme). On met en oeuvre un éditeur qui permet de créer, modifier et supprimer des équipements logiques (sans référence à sa réalisation électronique) en définissant ses variables, au travers de paramètres tels que type de données (chaîne de caractère, numérique ou booléen), mode d'accès (écriture et/ou lecture), limites de variation (valeur ou longueur maximum et minimum). Cette définition de variables et paramètres est contrainte par la compatibilité avec les fonctionnalités offertes par l'éditeur. Par exemple, le type de données peut être limité aux trois exemples donnés ci-dessus et donc ne pas permettre un tableau. Au cours d'une étape 315, on effectue un Mapping ou une mise en correspondance pour que chaque variable du modèle de données logiques de l'application puisse être acquise (lecture) et/ou commandée (écriture) sur des supports physiques ou logiciels. Par ailleurs, cette configuration se réalise au moyen d'interfaces graphiques contraignant l'utilisateur par rapport à la réalité physique du module de communication 110 qu'il utilise. On met en oeuvre un éditeur qui permet d'associer chaque variable définie au cours de l'étape 310 avec un moyen d'acquisition ou de commande supporté par l'environnement. Cet éditeur limite les choix en fonction des paramètres des variables prédéfinis et des fonctionnalités offertes par le module 110 qui est programmé. Par exemple, la variable Etat de la centrale d'alarme pourra être associée à la broche GPIO (General Purpose Input Output) n 4 du module de communication, l'utilisateur ne pouvant pas choisir les broches 0 à 3 car celles-ci n'existent pas sur le module utilisé. On constitue donc, ici, une association spécifique au module électronique et équipements concernés par la programmation. Au cours d'une étape 320, on définit la logique événementielle, c'est-à-dire le fonctionnement de l'application informatique et les conditions de réalisation de ses actions. Par exemple, cette logique événementielle indique quelles combinaisons d'états de l'équipement provoquent quelles actions de la part du module électronique associé. Cette définition se fait de manière graphique en sélectionnant les données logiques à contrôler (représentées par des rectangles), en associant une notion de logique binaire (représentées par des relations entre les rectangles précédemment sélectionnés) et finalement en choisissant une action à exécuter parmi celles disponibles (représentées par des icônes). Ainsi, les données logiques à contrôler, les relations de logique binaire et les actions à exécuter sont préférentiellement représentées par des éléments graphiques spécifiques. Au cours d'une étape 325, on définit les paramètres de configuration du module de communication 110 qui permettront son interfaçage avec l'équipement 100.

Cette configuration se réalise au travers d'interfaces graphiques limitant l'utilisateur par rapport aux réalités physiques des composants du module de communication 110. Par exemple, on pourra configurer la vitesse de communication d'un port série existant sur le module.

Au cours des étapes 330 à 345, on effectue les mêmes étapes que les étapes 310 à 325, respectivement, pour la programmation de l'application de communication à implanter du côté serveur considéré comme présélectionné car commun à différents modules 110. Ainsi, au cours de l'étape 330, on définit un modèle de données logiques de l'application destinée à s'exécuter sur le serveur 140. Ce modèle se réalise en définissant des matériels et logiciels logiques manipulés par l'application, puis en leur ajoutant des variables représentatives de leurs caractéristiques logiques. Cette définition se fait au moyen d'écran graphique guidant l'utilisateur en lui proposant des choix pour certains paramètres et en le laissant libre pour d'autres. Ce modèle logique est totalement indépendant de la physique de traitement ou de stockage des données réelles existantes. Cette définition de variables et paramètres est contrainte par la compatibilité avec les fonctionnalités offertes par l'éditeur. Au cours d'une étape 335, on effectue un Mapping ou une mise en correspondance pour que chaque variable du modèle de données logiques de l'application puisse être acquise (lecture) et/ou commandée (écriture) sur des supports physiques ou logiciels. Par ailleurs, cette configuration se réalise au moyen d'interfaces graphiques contraignant l'utilisateur par rapport à la réalité physique du serveur 140 et de ses périphériques qu'il utilise. On met en oeuvre un éditeur qui permet d'associer chaque variable définie au cours de l'étape 330 avec un moyen d'acquisition ou de commande supporté par l'environnement.

Cet éditeur limite les choix en fonction des paramètres des variables prédéfinis et des fonctionnalités offertes par le serveur 140 qui est programmé. On constitue donc, ici, une association spécifique au serveur 140 et à ses périphériques concernés par la programmation. Au cours d'une étape 340, on définit la logique événementielle, c'est-à-dire le fonctionnement de l'application informatique et les conditions de réalisation de ses actions. Par exemple, cette logique événementielle indique quelles combinaisons d'états provoquent quelles actions de la part du serveur 140 ou de ses périphériques. Cette définition se fait de manière graphique en sélectionnant les données logiques à contrôler (représentées par des rectangles), en associant une notion de logique binaire (représentées par des relations entre les rectangles précédemment sélectionnés) et finalement en choisissant une action à exécuter parmi celles disponibles (représentées par des icônes).

Au cours d'une étape 345, on définit les paramètres de configuration du serveur 140 et de ses périphériques qui permettront son interfaçage avec le module 110. Cette configuration se réalise au travers d'interfaces graphiques limitant l'utilisateur par rapport aux réalités physiques du serveur 140 et de ses périphériques. Par exemple, on pourra configurer la vitesse de communication d'un port série existant sur le serveur. Puis, au cours d'une étape 365, on définit la communication entre le module et le serveur. On met en oeuvre un éditeur qui permet de sélectionner les moyens de communication en fonction des capacités de communication offertes par le module de communication 110.

Si au moins deux canaux de communication ont été définis, l'étape 365 permet également d'organiser le choix dynamique du canal de communication à utiliser. Cette organisation vise à conserver un lien entre le module électronique et le serveur, même si un moyen de communication était défaillant. Par exemple, le choix dépend des canaux disponibles et/ou des prix des canaux de communication. Au cours de cette étape, les choix sont effectués graphiquement grâce notamment à des boites à choix multiples, des champs textes et des interfaces se rafraîchissant en fonction des choix faits précédemment. Puis, au cours d'une étape 370, on génère l'application qui s'exécutera sur le module 110 et celle qui s'exécutera sur le serveur 140. Cette application est un assemblage de briques ou composants logicielles génériques, par exemple le serveur de communication, de serveur de la toile ou web , ou spécifiques. Les briques et composants logiciels sont sélectionnés en fonction des choix effectués précédemment, de manière déterministe. Ces choix faits précédemment contraignent aussi l'ordre d'exécution de ces briques ou composants, ce qui assure le bon fonctionnement de l'application générée. Par exemple, les briques concernent l'une le serveur de communication, serveur de la toile ou serveur SMS, l'autre la communication GPRS, ... L'application générée destinée à être exécutée sur le module de communication 110 est générée dans le langage natif de celui-ci.

Au cours d'une étape 375 on télécharge chacune des applications sur le module et le serveur, on lance ses applications, avec ou sans réinitialisation. Les avantages principaux de ce procédé de développement sont les suivants : 1/ sa facilité d'utilisation : une approche de programmation graphique guidant les choix de développement de l'utilisateur ; une approche de programmation de haut niveau : o utilisation de briques de modèle de données efficaces pour définir la logique de l'application et la lier à un dispositif de communication ; outilisation d'un dispositif d'association des paramètres logiques et physiques (moyen d'acquisition) de l'application ; o mise à disposition d'un assistant de configuration pour définir tous les paramètres de communication entre le module 110 et le serveur 140 ; - une génération de code informatique automatique ; un ensemble de composants d'application prêts à l'emploi : o un serveur web embarqué ; o une librairie de protocoles applicatifs (Modbus, Nmea, par exemple) pour une interconnexion aisée avec des équipements spécifiques tels que PLC (acronyme de Programmable Logic Controller pour, en français, automate programmable), dispositif de télémétrie, modules GPS (acronyme de Global Positioning System pour système de positionnement global), par exemple ; o un serveur web classique permettant d'accéder aux informations métier de l'application développée ; o des modèles d'applications, des pages de présentation, des composants graphiques (connus sous le nom de widgets). 2/ Une connexion d'une extrémité à l'autre pour développer et déployer une solution machine à machine complète depuis les équipements éloignés jusqu'aux serveurs applicatifs, permettant la communication par l'intermédiaire de réseaux, par exemple GSM (acronyme de Global System for Mobile communication pour, en français, système de communication globale pour équipements mobiles), GPRS (acronyme de Global Packet Radio Service pour, en français, système de communication radio par paquets), Edge, Wifi (acronyme de Wireless Fidelity pour, en français, Fidélité sans fil), LAN (Local Area Network pour, en francais réseau local). 3/ La sécurité par le biais de mécanismes de sécurité intégrés : la mise en oeuvre du protocole de transfert de données sécurisé https, de dispositifs d'authentification de personnes, de terminaux ou d'applications, de gestion de profils d'utilisateurs ; 4/ Les performances grâce à : - l'optimisation de codes embarqués pour une emprise minimale sur les ressources, en particulier, ressources de mémoire, des modules électroniques et une fiabilité maximale et l'optimisation de bande passante utilisée sur les réseaux de communication, par compression de données pour minimiser les coûts de trafic de données entre les modules électroniques 110 et les serveurs 140 ; 5/ Maintenance et mise à jour : fourniture, diagnostic, maintenance et téléchargement d'applications à distance, grâce à des capacités de communication à distance fournies par le module 110 et 6/ Récupération de données depuis les modules électroniques distants 110 pour stockage dans le système de traitement d'information (serveur 140), pour réalisation de rapports, facturation, base de connaissance, par exemple. Grâce à la mise en oeuvre de cet environnement de développement, on développe une solution globale et centralisée. Pratiquement, la suite de développement organise le développement et s'abstrait de la forme d'exécution. Un macro-langage graphique permet de s'affranchir de connaissance de langage informatique. On observe que les éléments et la programmation sont conservés en mémoire du terminal de programmation 150 et peuvent être édités et téléchargés à distance sur le module 110 et/ou sur le serveur 140 à tout moment. Le macro-langage graphique et l'environnement graphique utilisent ainsi, à la fois, des parties génériques et des parties spécifiques pour des modules particuliers. Grâce à ces caractéristiques, le langage de programmation est indépendant du module électronique et de son fournisseur, des BSP (acronyme de Board Support Package pour, en français, ensemble de support de bureau) ou MSP (module support package pour, en français, ensemble de support de module) ou de l'ensemble de pilotes permettant leur commande. 20

Claims (10)

REVENDICATIONS

1 û Procédé de communication entre un équipement (100) et un serveur distant (140), caractérisé en ce qu'il comporte : - une étape (205) d'association d'un module électronique (110) doté d'un contrôleur programmable (115) avec ledit équipement de telle manière que ledit module reçoive des signaux représentatifs d'états ou de paramètres de fonctionnement dudit équipement ; - une étape (210) d'implantation d'une application de serveur de communication sur ledit module électronique, ladite application de serveur de communication étant adaptée à communiquer avec ledit module ; - une étape (230) de transmission d'une requête depuis ledit serveur distant à destination dudit module et une étape (235) de réponse à ladite requête, de la part dudit module et à destination dudit serveur distant, ladite réponse encapsulant des informations représentatives desdits états ou paramètres dudit équipement.

2 û Procédé selon la revendication 1, caractérisé en ce que, au cours de l'étape (230) de transmission d'une requête depuis le serveur distant à destination du module, ladite requête est une requête de logiciel de navigation sur la toile.

3 û Procédé selon l'une quelconque des revendications 1 ou 2, caractérisé en ce qu'il comporte, en outre, une étape (255) d'affichage d'au moins une information représentative desdits états ou paramètres dudit équipement.

4 û Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comporte une étape (212) de comparaison desdits états ou paramètres avec des valeurs prédéterminées et, en fonction du résultat de ladite étape de comparaison, une étape de déclenchement d'une alarme.

5 û Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce qu'il comporte une étape (215) de sélection d'un canal de communication (130, 135) entre le module électronique et ledit serveur distant, en fonction de caractéristiques des données à transmettre et des canaux de communications disponibles, au moins l'une des étapes de transmission d'une requête et de réponse à ladite requête étant effectuée en mettant en oeuvre le canal de communication sélectionné.

6 - Dispositif de communication entre un équipement (100) et un serveur distant (140), caractérisé en ce qu'il comporte : - un contrôleur programmable (115) associé avec ledit équipement de telle manière que ledit contrôleur reçoive des signaux représentatifs d'états ou de paramètres de fonctionnement dudit équipement ; un moyen d'implantation (115) d'une application de serveur de communication comportant : o un moyen de communication (103) avec ledit équipement ; o un moyen de réception (120, 125) de requêtes depuis ledit serveur distant et o un moyen de réponse (120, 125) à ladite requête, à destination dudit serveur distant, ladite réponse encapsulant des informations représentatives desdits états ou paramètres dudit équipement.

7 ù Dispositif selon la revendication 6, caractérisé en ce que le moyen de réception de requête (120, 125) est adapté à ce que ladite requête soit une requête de logiciel de navigation sur la toile.

8 ù Dispositif selon l'une quelconque des revendications 6 ou 7, caractérisé en ce qu'il comporte, en outre, un moyen d'affichage d'au moins une information représentative desdits états ou paramètres dudit équipement.

9 ù Dispositif selon l'une quelconque des revendications 6 à 8, caractérisé en ce qu'il comporte un moyen (115) de comparaison desdits états ou paramètres avec des valeurs prédéterminées et un moyen (115) de déclenchement d'alarme adapté à déclencher une alarme en fonction du résultat de ladite étape de comparaison.

10 ù Dispositif selon l'une quelconque des revendications 6 à 9, caractérisé en ce qu'il comporte un moyen (115, 170) de sélection adapté à sélectionner un canal de communication (130, 135) entre le module électronique et ledit serveur distant en fonction de caractéristiques des données à transmettre et des canaux de communications disponibles, au moins l'un des moyens (120, 125) de réception d'une requête et de réponse à ladite requête étant adapté à mettre en oeuvre le canal de communication sélectionné.25