Brevet FR2971383A1 — publié le 20120810

DISPOSITIF ET PROCEDE DE COMMUNICATION DANS UN ENVIRONNEMENT TEMPS REEL DOMAINE TECHNIQUE L'invention concerne le domaine des réseaux et dispositifs communiquant par Services Web (ou Web Services), c'est-à-dire communiquant et échangeant des données, notamment en temps réel, entre applications et systèmes dans un environnement distribué tel qu'un réseau local ou sans fil. L'invention s'applique notamment à des dispositifs destinés à être utilisés dans des architectures orientées services (ou SOA : "Service Oriented 1 o Architecture"), tels que des capteurs, des actionneurs, des disjoncteurs, des appareils de mesure, des équipements d'entrées / sorties, des automates programmables, des équipements de dialogue homme-machine, des variateurs de vitesse, des concentrateurs de données, des ordinateurs (par exemple des PC), etc. 15 ÉTAT DE LA TECHNIQUE ANTÉRIEURE DPWS ("Device Profile for Web Services" - voir http://docs.oasisopen.org/ws-dd/ns/dpws/2009/01) est une pile de protocoles d'échange de données dans un réseau de communication, utilisée dans une architecture de type SOA, au niveau des dispositifs qui sont reliés au réseau de communication. En mettant en 20 oeuvre DPWS, ces dispositifs peuvent interagir et communiquer les uns avec les autres par l'intermédiaire de Services Web de manière aisée. La figure 1 représente schématiquement la pile de protocoles formant DPWS. DPWS repose sur les protocoles IP ("Internet Protocol") (référence 10), TCP ("Transmission Control Protocol") (référence 12), UDP ("User Datagram 25 Protocol") (référence 14) et HTTP (référence 16). DPWS fait appel également au protocole SOAP ("Simple Object Access Protocol"), correspondant à la référence 18, qui permet de définir les mécanismes d'échange d'informations entre des clients et des fournisseurs de Services Web. Les dispositifs mettant en oeuvre DPWS remplissent le rôle de client et/ou de fournisseur de Services Web. Les données générées (trames) 30 par SOAP sont de type XML qui est un langage au format textuel. Au-dessus de SOAP sont représentés les autres protocoles que comporte DPWS : - WS-Addressing (référence 20) : ce protocole permet aux dispositifs, grâce au protocole IP, de communiquer de manière bidirectionnelle les uns avec les autres avec un adressage des services indépendant des adresses IP. - WS-Discovery (référence 22) : ce protocole permet aux dispositifs présents sur le réseau de se découvrir les uns des autres. Ainsi, lorsqu'un dispositif client est ajouté sur le réseau, celui-ci émet par multicast, ou multidiffusion, et par l'intermédiaire de ce protocole, des données permettant d'informer les autres dispositifs des services proposés par celui-ci. Lorsqu'un dispositif de contrôle est par exemple ajouté sur le réseau, ce protocole permet l'envoi de requêtes permettant 1 o d'identifier les dispositifs destinés à coopérer avec ce dispositif de contrôle. Les trames envoyées lors de cette phase de découverte passent par le protocole UDP. - WS-Eventing (référence 24) : ce protocole permet l'échange de messages liés aux évènements entre Services Web. La référence 20 désigne également d'autres protocoles tels que WS- 15 Security, WS-Policy, WS-MetadataExchange, WS-Transfer, etc., mis en ceuvre par DPWS. Lorsque les dispositifs sont des dispositifs industriels, par exemple des capteurs, des actionneurs, des disjoncteurs, des appareils de mesure, des équipements d'entrées / sorties, des automates, des concentrateurs de données ou 20 encore des ordinateurs, utilisés notamment pour des applications d'automation temps réel industrielles, et du fait que leurs ressources matérielles de traitement des données sont généralement limitées, la mise en ceuvre de DPWS par ces dispositifs pose des problèmes de performances car les durées de transmission des évènements, tels que des commandes destinées à piloter certains dispositifs ou des mesures réalisées par 25 d'autres dispositifs, sont trop longues (par exemple égales à environ 10 ms en comptant le temps de transmission à travers le réseau et le temps de codage / décodage dans les dispositifs émetteur / récepteur) pour être compatibles avec ces applications temps réel. 30 EXPOSÉ DE L'INVENTION Un but de la présente invention est de proposer un nouveau type de dispositif pouvant être utilisé dans une architecture de type SOA et présentant de meilleures performances en termes de durées de transmission des évènements entre eux par rapport aux dispositifs de l'art antérieur. Pour cela, la présente invention propose un dispositif apte à fonctionner dans un environnement de type SOA temps réel, comportant des moyens de communication sur un réseau de communication par l'intermédiaire de Services Web conformes à une pile de protocoles de type DPWS, lesdits moyens de communication comportant des moyens de codage et/ou de décodage de trames de données selon un format XML binaire, caractérisé en ce que le dispositif comporte en outre des moyens mémorisant une ou plusieurs structures des trames de données destinées à être échangées sur le réseau de communication, le codage et/ou le décodage de trames de données selon le format XML binaire étant réalisé 1 o conformément aux structures des trames de données mémorisées. Le dispositif selon l'invention propose donc de combiner l'utilisation d'un langage XML binaire tout en conservant les caractéristiques d'une architecture SOA DPWS. Du fait que les structures des trames de données sont mémorisées et donc connues par le dispositif, il n'est donc plus nécessaire de transmettre des trames 15 de données XML complètes car le dispositif récepteur sait quel type de données est envoyé (une mesure, une commande, ...). L'utilisation d'un langage XML binaire permet de réduire la longueur des trames échangées par rapport aux trames XML textuelles qui ont une longueur importante (généralement supérieure à environ 1 ko) même lorsque la quantité 20 d'information du message est très faible (quelques octets). L'utilisation d'un langage XML binaire permet également de réduire la quantité de ressources matérielles nécessaire au dispositif pour réaliser le codage / décodage des trames. La durée de transmission de l'information est réduite d'environ un facteur 10. Ainsi, la durée de transmission d'une trame XML binaire atteinte, depuis le codage dans un premier 25 dispositif émetteur jusqu'au décodage dans un second dispositif récepteur, est égale à environ 1 ms. Avantageusement, le format XML binaire peut correspondre au standard EXI, qui représente un compromis idéal en termes de taille de trames et de performances. D'autres formats XML binaire peuvent être utilisés, comme par exemple 30 «Fast Infoset», ou bien les formats de compression de type zip. Le dispositif peut comporter en outre des moyens d'envoi et/ou de réception sur le réseau de communication des structures des trames de données aptes à envoyer et/ou recevoir ces structures préalablement à des échanges de trames de données selon le format XML binaire sur le réseau de communication. Les moyens de codage et/ou de décodage de trames de données selon un format XML binaire peuvent comporter une interface de programmation apte à lire et traiter des trames XML textuelles et des trames XML binaires. Le dispositif peut être un capteur ou un disjoncteur ou un automate. L'invention concerne également un procédé de communication entre au moins deux dispositifs aptes à fonctionner dans un environnement de type SOA temps réel et à communiquer sur un réseau de communication par l'intermédiaire de Services Web conformes à une pile de protocoles de type DPWS, comportant au moins les étapes de : - mémorisation, dans les dispositifs, de structures de trames de données destinées à être échangées sur le réseau de communication entre les dispositifs, - codage et/ou décodage de trames de données selon un format XML binaire conformément aux structures des trames de données mémorisées. 15 La mémorisation des structures de trames peut être réalisée lors de la programmation des dispositifs, les structures de trames formant une partie des programmes de fonctionnement des dispositifs. Dans une variante, la mémorisation des structures de trames peut 20 être réalisée en partie lors de la programmation des dispositifs et achevée lors de la mise en fonctionnement des dispositifs, préalablement aux échanges de trames de données selon le format XML binaire. Dans une autre variante, le procédé peut comporter en outre, préalablement à la mémorisation des structures de trames, au moins les étapes de : 25 - reconnaissance des dispositifs entre eux par des échanges de trames au format XML textuel sur le réseau de communication ; - échange, entre les dispositifs, d'informations relatives à un format choisi d'échange de trames ; - échange, entre les dispositifs, des structures de trames 30 correspondant au format choisi d'échange de trames. Dans cette dernière variante, les dispositifs peuvent donc négocier entre eux leur mode d'échange et le format des données échangées. Enfin, l'invention concerne également un système de communication comportant une pluralité de dispositifs selon l'invention reliés entre eux par 35 l'intermédiaire d'un réseau de communication. 10 BRÈVE DESCRIPTION DES DESSINS La présente invention sera mieux comprise à la lecture de la description d'exemples de réalisation donnés à titre purement indicatif et nullement limitatif en faisant référence aux dessins annexés sur lesquels : la figure 1 représente la pile de protocoles DPWS ; la figure 2 représente la pile de protocoles mise en ceuvre dans un dispositif objet de la présente invention ; la figure 3 représente schématiquement un système de communication, objet de la présente invention, comportant deux dispositifs, également objets de la 1 o présente invention, aptes à communiquer l'un avec l'autre à travers un réseau. Des parties identiques, similaires ou équivalentes des différentes figures décrites ci-après portent les mêmes références numériques de façon à faciliter le passage d'une figure à l'autre. Les différentes parties représentées sur les figures ne le sont pas 15 nécessairement selon une échelle uniforme, pour rendre les figures plus lisibles. Les différentes possibilités (variantes et modes de réalisation) doivent être comprises comme n'étant pas exclusives les unes des autres et peuvent se combiner entre elles. 20 EXPOSÉ DÉTAILLÉ DE MODES DE RÉALISATION PARTICULIERS On se réfère à la figure 2 qui représente une pile de protocoles 100 de type DPWS mise en ceuvre dans un dispositif selon l'invention. Cette pile 100 sera par exemple codée en langage C dans le dispositif. La pile de protocoles 100 se base sur un système d'exploitation 101 25 sur lequel reposent les protocoles Internet IP (référence 102), TCP (référence 104), UDP (référence 106) et HTTP (référence 108). La pile 100 utilise également les protocoles SOAP (référence 110), tel que SOAP 1.2, et WS-Addressing (référence 110) pour définir les mécanismes d'échanges d'informations entre les dispositifs. Au-dessus, les autres protocoles de Services Web, précédemment 30 décrits en liaison avec la figure 1, sont également présents dans la pile de protocoles 100: WS-Service Invocation (référence 114), WS-Eventing (référence 116), WSDiscovery (référence 112), etc. Chacun de ces protocoles est connu et n'est donc pas détaillé ici. Enfin, la couche 118 représente la couche d'application 35 correspondant aux logiciels fonctionnant sur le dispositif. 5 Ainsi, avec ces éléments, la pile de protocoles 100 permet au dispositif qui la met en ceuvre de réaliser toutes les fonctions et conserver toutes les caractéristiques d'une architectures orientée Services Web (interopérabilité, fonctionnalité «plug and play», ...). La pile de protocoles 100 autorise donc les dispositifs qui la mettent en ceuvre à réaliser des échanges de données XML. En plus de cela, la pile de protocoles 100 est conçue de manière modulaire et comporte des fonctions pouvant être ajoutées ou retirées selon les besoins. Ces fonctions sont représentées sur l'exemple de la figure 2 et désignées par la référence 120. 1 o Une de ces fonctions correspond à une fonction de binarisation des trames XML lues et/ou reçues par le dispositif, et permet de réaliser un encodage et décodage binaire des trames SOAP/XML. Le standard XML binaire utilisé est de préférence EXI ("Efficient XML Interchange"). En effet, l'utilisation d'EXI permet de réduire d'environ 14,5 fois le temps nécessaire pour le décodage d'une trame XML, et 15 de réduire d'environ 6 fois le temps de codage d'une trame XML. On améliore ainsi grandement les performances, en termes de durées de transmission et de traitement des trames, des dispositifs mettant en ceuvre la pile de protocoles 100. EXI fonctionne ici en mode "schema-informed". En effet, dans un environnement industriel, au niveau dispositifs, la plupart des échanges sont prédéfinis 20 (envoi d'une mesure par un capteur, d'une commande par un contrôleur, ...), la structure des données et le type d'encodage / décodage étant inchangés tout au long du processus. Dans l'invention, les dispositifs sont donc configurés pour émettre et recevoir des données dont la structure est déjà établie et mémorisée dans les dispositifs. Ainsi, on évite d'envoyer certaines données inutiles qui seraient 25 nécessairement envoyées si ces données étaient envoyées sous la forme de trames XML textuelles. En fonctionnement, les dispositifs s'échangent une référence de données, servant d'indicateur numérique, et la valeur binaire de la donnée échangée, ce qui permet de réduire la taille de la trame ainsi que les ressources matérielles 30 nécessaires au codage / décodage de ces trames. La figure 3 représente deux dispositifs 200a, 200b mettant chacun en ceuvre la pile de protocoles 100 précédemment décrite en liaison avec la figure 2. Les dispositifs 200a, 200b communiquent entre eux par l'intermédiaire d'un réseau 202, par exemple de type Ethernet, formant plus globalement un système de 35 communication 1000. Préalablement à un échange de données, les structures des trames de données (références 201a, 201b) destinées à être reçues et/ou émises par les dispositifs 200a, 200b, sont envoyées et mémorisées dans les dispositifs 200a, 200b afin que ces dispositifs sachent quels types de données seront reçus et/ou envoyés sur le réseau 202. Sur l'exemple de la figure 3, le premier dispositif 200a détecte l'arrivée de données (évènement physique, par exemple une température mesurée) sur une de ses entrées physiques 204. Ces données sont traitées par la pile DPWS 206a du dispositif 200a, et notamment codées par un encodeur EXI 208, en trames au format XML binaire. L'information est ensuite envoyée à travers le réseau 202 à destination du second dispositif 200b qui décode ces trames reçues par un décodeur 1 o EXI 210 de sa pile DPWS 206b. Le dispositif 200b peut ensuite retranscrire ces données sur une de ses sorties physiques 212 (par exemple un écran). Sur l'exemple de la figure 3, les deux dispositifs 200a, 200b utilisent donc DPWS associé à EXI pour réaliser un échange d'informations. Afin de réaliser le codage / décodage des trames EXI, et obtenir les 15 meilleures performances possibles, les dispositifs 200a, 200b ont reçu au préalable la syntaxe des informations qui sont destinées à être échangées entre eux sur le réseau 202. Cette syntaxe est donnée par des structures de trames de données 201a, 201b qui sont par exemple des fichiers de type .XSD pour la recommandation XML Schema ("XML Schema Definition"). De tels fichiers .XSD sont en effet des fichiers de 20 grammaire qui permettent de définir la structure et le type de contenu d'un document XML. Cette configuration préalable aux échanges de données EXI peut être réalisée de différentes façons : - lors de la programmation des dispositifs : la structure des informations étant alors fournie comme une partie du programme destiné à être 25 implémenté par les dispositifs ; - lors de la configuration des dispositifs : les structures des informations sont échangées sur le réseau 202 et utilisées pour configurer les dispositifs ; lors du fonctionnement des dispositifs : les structures des 30 informations sont dynamiquement échangées et négociées entre les dispositifs. Les structures des trames de données 201a, 201b peuvent être mémorisées par les dispositifs 200a, 200b lors de leur programmation lorsque la structures des informations échangées et le contenu des informations échangées sont connus dès la conception du dispositif. Une telle configuration des dispositifs 200a, 35 200b est par exemple réalisée lorsque l'un des dispositifs est un équipement de mesure, tel qu'une sonde de température, fournissant une information ayant une structure statique prédéterminée. Dans ce cas, le logiciel embarqué de l'équipement pourra être écrit en intégrant le fichier XSD dans le programme. Une telle configuration a notamment pour avantage d'être simple à mettre en ceuvre. Lorsque les informations échangées sont connues (nombre, type, ...) lors de la conception du système, mais que leur contenu exact peut évoluer, certains paramètres des structures des trames de données 201a, 201b (fichiers XSD) peuvent être amenés à être modifiés. Dans ce cas, la mémorisation de ces structures 201a, 201b peut être réalisée lors de la configuration des dispositifs 200a, 200b. Les valeurs des paramètres variables sont saisies et envoyées aux dispositifs 200a, 200b 1 o préalablement au démarrage du système. Ainsi, comme lorsque les structures des trames de données sont mémorisées par les dispositifs lors de leur programmation, le logiciel embarqué dans les dispositifs 200a, 200b peut être écrit en intégrant la structure des fichiers XSD, les valeurs des paramètres variables étant ultérieurement prises en compte, lors du démarrage du système. Une telle configuration a pour 15 avantage d'être simple à mettre en ceuvre et d'offrir une certaine flexibilité dans la configuration des dispositifs 200a, 200b. Lorsque les informations échangées ne sont pas connues lors de la conception du système, par exemple lorsque le dispositif est complexe (tel qu'un automate, un concentrateur de données ou encore un ordinateur) ou lorsque le 20 dispositif correspond à un équipement dont les services embarqués peuvent être déployés dynamiquement, l'échange et la mémorisation des structures des informations peuvent être réalisés lors du fonctionnement des dispositifs. Dans ce cas, le système comprenant les dispositifs 200a, 200b est démarré. Les dispositifs 200a, 200b se reconnaissent en utilisant DPWS en mode XML textuel, puis s'échangent les 25 informations sur le mode de communication souhaité (XML textuel, XML binaire type EXI ou autre, paramètre d'encodage, ...). Les dispositifs s'échangent alors les fichiers XSD correspondant aux informations qui seront échangées. Ces fichiers sont liés dynamiquement aux programmes des dispositifs. Une telle configuration avantageuse permet d'assurer une grande flexibilité au système tout en gardant les caractéristiques 30 d'auto-description des services Web. La binarisation des trames XML peut par exemple être réalisée par une interface de programmation (API) permettant de lire et traiter à la fois des trames XML textuelles et des trames XML binaires. REVENDICATIONS1. Dispositif (200a, 200b) apte à fonctionner dans un environnement de type SOA temps réel, comportant des moyens de communication sur un réseau de communication (202) par l'intermédiaire de Services Web conformes à une pile de protocoles de type DPWS (100, 206a, 206b), lesdits moyens de communication comportant des moyens (208, 210) de codage et/ou de décodage de trames de données selon un format XML binaire, caractérisé en ce que le dispositif (200a, 200b) comporte en outre des moyens mémorisant une ou plusieurs structures des trames de 1 o données destinées à être échangées sur le réseau de communication (202), le codage et/ou le décodage de trames de données selon le format XML binaire étant réalisé conformément aux structures des trames de données mémorisées. 2. Dispositif (200a, 200b) selon la revendication 1, dans lequel le format XML 15 binaire correspond au standard EXI. 3. Dispositif (200a, 200b) selon l'une des revendications précédentes, comportant en outre des moyens d'envoi et/ou de réception sur le réseau de communication (202) des structures des trames de données aptes à envoyer et/ou 20 recevoir ces structures préalablement à des échanges de trames de données selon le format XML binaire sur le réseau de communication (202). 4. Dispositif (200a, 200b) selon l'une des revendications précédentes, dans lequel les moyens (208, 210) de codage et/ou de décodage de trames de données 25 selon un format XML binaire comportent une interface de programmation apte à lire et traiter des trames XML textuelles et des trames XML binaires. 5. Dispositif (200a, 200b) selon l'une des revendications précédentes, le dispositif (200a, 200b) étant un capteur ou un disjoncteur ou un automate. 6. Procédé de communication entre au moins deux dispositifs (200a, 200b) aptes à fonctionner dans un environnement de type SOA temps réel et à communiquer sur un réseau de communication (202) par l'intermédiaire de Services Web conformes 30 à une pile de protocoles de type DPWS (100, 206a, 206b), comportant au moins les étapes de : - mémorisation, dans les dispositifs (200a, 200b), de structures de trames de données destinées à être échangées sur le réseau de communication (202) entre les dispositifs (200a, 200b), - codage et/ou décodage de trames de données selon un format XML binaire conformément aux structures des trames de données mémorisées. 7. Procédé selon la revendication 6, dans lequel le format XML binaire 1 o correspond au standard EXI. 8. Procédé selon l'une des revendications 6 ou 7, dans lequel la mémorisation des structures de trames est réalisée lors de la programmation des dispositifs (200a, 200b), les structures de trames formant une partie des programmes de 15 fonctionnement des dispositifs (200a, 200b). 9. Procédé selon l'une des revendications 6 ou 7, dans lequel la mémorisation des structures de trames est réalisée en partie lors de la programmation des dispositifs (200a, 200b) et achevée lors de la mise en fonctionnement des dispositifs (200a, 20 200b), préalablement aux échanges de trames de données selon le format XML binaire. 10. Procédé selon l'une des revendications 6 ou 7, comportant en outre, préalablement à la mémorisation des structures de trames, au moins les étapes de : 25 - reconnaissance des dispositifs (200a, 200b) entre eux par des échanges de trames au format XML textuel sur le réseau de communication (202) ; - échange, entre les dispositifs (200a, 200b), d'informations relatives à un format choisi d'échange de trames ; - échange, entre les dispositifs (200a, 200b), des structures de trames 30 correspondant au format choisi d'échange de trames. 11. Système de communication (1000) comportant une pluralité de dispositifs (200a, 200b) selon l'une des revendications 1 à 5 et reliés entre eux par un réseau de communication (202). 35