FR 2938998 A1 20100528 FR 0806553 A 20081121 SYSTEME ET PROCEDE POUR LE DEPLOIEMENT DYNAMIQUE DE TRAITEMENTS DISTRIBUES L'invention concerne un système et un procédé permettant notamment le déploiement dynamique de tâches ou traitements, tels que des services distribués dans un réseau de capteurs sans fil. Le réseau de capteurs sans fil peut être un réseau ad hoc dans lequel chaque unité, par exemple un noeud communique directement avec son voisin. L'invention s'applique, notamment, dans des architectures mufti-niveaux. Elle est utilisée dans les réseaux filaires ou sans fil, de manière plus générale dans tout réseau comprenant des noeuds ayant des capacités de traitement limitées. Les réseaux de capteurs sans fils ou en abrégé RCS plus connus 15 sous l'abréviation anglo-saxonne WSN pour Wireless Sensor Networks sont composés de noeuds caractérisés par le fait qu'ils possèdent des capacités de communication radio, des capacités de mesure via l'utilisation de transducteurs ou de modules plus complexes, et des capacités de calcul plus ou moins élevées. Ces noeuds capteurs sont mis en réseau en utilisant le 20 plus souvent des fonctions d'auto-organisation à la manière des réseaux ad-hoc (plus connus sous la désignation anglo-saxonne MANET RFC2501). Dans ce cas, puisque la communication n'est a priori possible qu'entre les noeuds en portée radio, un protocole de routage connu de l'Homme du métier, assure alors le relayage de paquets de données pour garantir la 25 connectivité de bout en bout lorsque la topologie du réseau le permet. Dans les RCS, les noeuds peuvent être mobiles ou non. Les RCS ont des applications civiles pour la surveillance d'infrastructures critiques (usines classifiées, les ponts), la surveillance environnementale (risque sismique, agriculture, écologie), certaines applications médicales ou pour la logistique, 30 ou encore des applications militaires dans le cadre de missions de surveillance. Les capacités de traitement des noeuds capteurs rencontrés dans les réseaux RCS peuvent être très hétérogènes en fonction des équipements déployés. Il peut s'agir aussi bien de radars déployables nécessitant des 35 traitements de l'ordre de ceux que l'on trouve sur des gros serveurs, de caméras IP ayant la capacité d'un assistant personnel ou PDA (Personal digital Assistant) ou de petits capteurs appelés � motes � comme les MicaZ commercialisé par la société Crossbow, qui sont très limitées en capacités : en puissance de calcul, batteries de faible capacité, en bande passante limitée. Le procédé selon l'invention s'applique notamment aux réseaux RCS ayant de faibles capacités. Ces réseaux RCS sont le plus souvent reliés à un système d'information afin d'assurer la collecte de données, d'effectuer des traitements de fusion de données plus complexes, ou de garantir leur contrôle et leur reconfiguration. Du fait de la complexité et de l'hétérogénéité de ces systèmes d'information, les architectures orientées services, connues sous l'abréviation anglo-saxonne SOA (Service Oriented Architecture) sont de plus en plus populaires et déployées. L'ensemble des principes d'architecture définis dans le cadre des SOA permet de séparer les fonctions en unités distinctes et autonomes, appelées Services, qui peuvent être distribués dans le réseau, combinés, et réutilisés pour créer des applications ou d'autres services. Les avantages majeurs de cette approche sont la modularité, la flexibilité, le faible couplage et l'interopérabilité. Ainsi, l'utilisation de l'approche SOA est particulièrement bien adaptée dans les réseaux RCS. Cependant, alors que les principes d'architecture SOA sont souvent utilisés sur les équipements ayant des capacités au moins de l'ordre de celles d'un PDA, ils sont très peu présents dans les réseaux de capteurs sans fil à très basse capacité. L'expression � très basse capacité � vise dans la présente application des équipements tels que les MicaZ équipés d'un microcontrôleur de quelques kilobytes de RAM (i.e 4 kb), d'une interface radio basse consommation, de batteries limitées, par exemple, deux piles R6 ou tout autre type de système présentant des caractéristiques équivalentes. Dans le cadre d'opérations de fusion de données impliquant des RCS composés de noeuds ayant de très faibles capacités, économiser les ressources est vital pour assurer la survie du réseau. Ainsi, afin d'éviter que les capteurs envoient au travers d'un puits les données qu'ils collectent à un centre de fusion situé en dehors du RCS, il est préférable de distribuer au maximum les traitements sur les données afin de réduire les coûts en communication. Le fait de réduire les communications permet principalement de rallonger la durée de vie du réseau RCS en économisant les batteries des noeuds. Par exemple, dans le cadre de la recherche d'un maximum, les capteurs pourront de proche en proche trouver de manière distribuée cette valeur maximale. Les traitements intermédiaires utilisés dans le cadre d'un service de fusion distribué sont limités par la capacité des noeuds qui les accueillent. Ainsi, sur des MicaZ, des opérations de filtrage (e.g seuil, filtre de Kalman) d'agrégation (i.e moyenne, somme, max-min), de décisions conditionnelles (i.e, classification hiérarchique) peuvent être réalisées. Les approches orientées services pour les réseaux de capteurs sans-fil ont été le sujet de plusieurs études. Une spécification connue de l'Homme du métier a défini une couche applicative introduisant le concept de service hébergé. Des passerelles permettent l'interconnexion de réseaux d'équipement Zigbee (http://fr.wikipedia.org/wiki/zigbee) avec le monde des Web Services, notamment une pile protocolaire adaptée pour les services Web DPWS. D'autres auteurs ont proposé un protocole de communication au niveau applicatif appelé pSOA. Ce protocole permet via une passerelle d'accéder à des Web Services embarqués sur des capteurs sans fil. La pile protocolaire WSN-SOA J. Leguay, M. Lopez-Ramos, K. Jean-Marie, V. Conan. An Efficient Service Oriented Architecture for Heterogeneous and Dynamic Wireless Sensor Networks, IEEE SenseApp 2008 a été introduite dans le cadre d'une architecture multi-niveaux orientée service pour les réseaux de capteurs. Cette architecture s'applique aussi bien pour des capteurs ayant des capacités similaires à un PC, un PDA ou à un capteur MicaZ. La pile WSN-SOA permet le déploiement de services dans des réseaux à très faibles capacités. Elle permet donc le support d'échanges de données entre capteurs mais n'apporte aucune fonctionnalité spécifique pour la fusion et le déploiement dynamique de services. Le déploiement dynamique de traitements a lui aussi fait l'objet de propositions. Il est connu d'utiliser un système qui permet de reprogrammer intégralement des capteurs sans-fil en reflashant leur mémoire à distance. II est aussi connu un intergiciel pour les RCS permettant l'utilisation d'agents mobiles. Les agents mobiles sont définis sous la forme de programme, ayant une syntaxe d'une complexité semblable à celle de l'assembleur, interprété sur les capteurs. En dépit du fait que cet intergiciel offre une large gamme d'opérations, il prend 3191 octets en mémoire RAM dans les MicaZ équipés seulement de 4Kb, ce qui rend sa disponibilité incompatible avec des piles protocolaires orientées services comme celle de WSN-SOA ainsi qu'avec l'implémentation d'opérations servant à la fusion de données. L'architecture TENET O. Gnawali, B. Greenstein, K. Jang, A. Joki, J. Paek, M. Vieira, D. Estrin, R. Govindan, E. Kohler, The TENET Architecture for Tiered Sensor Networks, ln Proc. ACM Sensys 2006 permet de distribuer des traitements aux noeuds capteurs sous la forme de tâches. Cela permet de réduire les coûts de communication en effectuant des prétraitements sur les capteurs ainsi que de supporter des opérations simples de reconfiguration. Cependant, TENET ne permet pas aux capteurs de collaborer entre eux. La pile protocolaire Telnet se limite au déploiement de traitements simples sur les noeuds. Chaque noeud est vu de façon isolé et atomique. Telnet ne permet pas de définir la façon dont les tâches doivent interagir en distribué sur les différents noeuds présentant une faible capacité. En résumé, l'art antérieur connu du Demandeur ne permet pas de définir de façon simple et flexible la manière d'intégrer et de faire collaborer tous les traitements individuels déployés sur des noeuds capteurs en réseau. En particulier, leurs enseignements ne permettent pas de définir les opérations suivantes : de distribuer des traitements impliquant la collaboration des 20 noeuds RCS. de faire interopérer des mécanismes de distribution de traitements sur les noeuds RCS avec des mécanismes existants (ou bien faire intéropérer des logiciels existant pour le déploiement dynamique de traitements). 25 Quelques définitions et rappels utiles à la compréhension de la présente demande de brevet vont être donnés ci-après. La description vise des architectures multi-niveaux qui permettent d'intégrer toute l'hétérogénéité des capteurs, au sens de capacités variables 30 de traitement, présents dans un système complexe. Dans l'architecture multi-niveaux, trois catégories de noeuds en fonction de leurs capacités réseaux et de leur disponibilité vont être considérés : � noeuds à forte capacité � ; ces noeuds ont une grande 35 disponibilité dans la mesure où ils sont en permanence connectés au système d'information. Ils n'ont pas de problèmes d'alimentation et disposent d'une grande capacité de traitement. Comme exemple, on peut citer les serveurs d'information cartographique connectés à des réseaux d'infrastructure) ; � noeuds à capacité limitée � ; ces noeuds ont des capacités limitées en termes de stockage, de batteries, de puissance de calcul ou de connectivité réseau mais peuvent héberger des systèmes d'exploitation comme le logicile libre GNU/Linux (fr.wikipedia.org/wiki/Linux) ou VxWorks (fr.wikipedia.org/wiki/VxWorks) et peuvent réaliser des traitements complexes. II peut s'agir de passerelles, de systèmes capteurs plus ou moins puissants (optroniques, acoustiques,..) ; � noeuds RCS � ; ces noeuds ont des capacités extrêmement limités. Ils sont, par exemple, munis de quelques kilooctets de mémoire vive (Random Access Memory) ou RAM, n'ont qu'un micro-contrôleur et utilisent une technologie radio basse consommation comme le standard IEEE 802.15.4. Les MicaZ commercialisés par la société CrossBow sont un exemple de matériel que l'on retrouve dans cette catégorie. L'intégration d'un réseau RCS dans un système complexe se fait par l'utilisation de � noeuds maîtres � pouvant être des � noeuds à forte capacité � ou des noeuds à capacité limitée. Dans un système d'information complexe, un réseau RCS est vu au travers des noeuds maîtres comme un sous-système. Cette terminologie sera utilisée pour décrire l'objet de la présente demande de brevet. L'idée de la présente invention repose notamment sur le déploiement de manière dynamique des services de fusion de données dans des réseaux de capteurs à faible capacité, dont certains exemples ont été donnés précédemment. Le système présente notamment comme avantage de distribuer des traitements dans un réseau de capteurs sans fil afin de créer un service de fusion optimisée. L'invention concerne un système permettant le déploiement dynamique et/ou la création de tâches au sein d'un réseau comportant au moins un noeud maître et plusieurs noeuds capteurs Ni ayant des capacités de traitement limitées, le réseau supportant un logiciel de communication et un mécanisme de routage permettant de relayer les différents messages échangés entre au moins les noeuds capteurs du réseau caractérisé en ce qu'il comporte au moins les éléments suivants : Au niveau d'un noeud Ni de faible capacité du réseau : Un gestionnaire de déploiement de tâches ou de traitements, - Un module de stockage desdites tâches reçues via un gestionnaire de déploiement des tâches, Un module interpréteur desdites tâches, - Une interface avec des capteurs locaux. Ces différents éléments coopèrent entre eux afin de distribuer les tâches ou traitements dans le cadre d'un service distribué au sein du réseau, Au niveau d'un noeud maître : - Un gestionnaire de déploiement de tâches. Un noeud maître comporte, par exemple, au moins un module de mémorisation de fichiers, un module de prétraitement des tâches afin que lesdites tâches puissent être déployées au niveau des différents noeuds ayant de faibles capacités de traitement du réseau. Le système peut comporter une interface adaptée à assurer l'interopérabilité entre les tâches des noeuds du réseau et un service d'un 20 niveau supérieur. Un noeud Ni du réseau comporte, par exemple, au moins un module de localisation dudit noeud dans le cas où certains services doivent être déployés sur des noeuds situés dans une zone géographique donnée. Le logiciel de communication peut être un logiciel orienté service 25 et en ce que les noeuds de faibles capacités comprennent des services capteurs locaux, des opérations basiques et des modules de services déployés. Le système peut comporter des services capteurs locaux adaptés à exécuter une des opérations suivantes : obtenir une dernière valeur 30 mesurée par invocation, une valeur mesurée en cas de changement significatif en utilisant les capacités de gestion évènementielle propre à l'intergiciel orienté services. Le système comporte, par exemple, un module d'opérations basiques comprenant une bibliothèque de fonctions et d'opérations adaptés à traiter des données reçues au niveau des noeuds, telles que le filtrage des données, la moyenne, leur agrégation. Selon un mode de réalisation, un noeud capteur Ni est un noeud maître. Le système peut comporter ou plusieurs opérations de base déployées avec les tâches ou se présentant sous la forme de bibliothèques. D'autres caractéristiques et avantages du dispositif selon l'invention apparaîtront mieux à la lecture de la description qui suit d'un 10 exemple de réalisation donné à titre illustratif et nullement limitatif annexé des figures qui représentent : - La figure 1, un exemple de service de fusion distribué, - La figure 2, différents exemples de technologies orientées services pouvant être utilisées à différents niveaux d'une architecture, 15 - La figure 3, un exemple de mise en collaboration de ressources capteurs et de traitements dans un système d'information complexe, - La figure 4, un exemple de déploiement de services - La figure 5, un exemple de fichier maître, 20 - Les figures 6, 7 et 8 différents exemples de tâches, - La figure 9, un exemple d'implémentation du procédé dans les noeuds capteurs avec une pile WSN-SOA et un environnement TinyOS, - La figure 10, un exemple d'implémentation du procédé dans un 25 noeud maître du réseau, - La figure 11, un exemple de déploiement distribué de fusion modélisé à partir de chorégraphies et orchestrations. Afin de mieux faire comprendre le principe mis en oeuvre par 30 l'invention, la description qui suit est donnée à titre illustratif pour un réseau de capteurs sans-fil afin de créer un service de fusion optimisée. La figure 1 représente un exemple de service de fusion distribué dans un réseau comprenant un noeud maître 0 ou noeud puits et plusieurs 35 noeuds capteurs qui traitent de manière hiérarchique les données mesurées. Dans cet exemple, tous les noeuds Ni, numérotés de 1 à 8 mesurent un paramètre physique, par exemple la température, et se coordonnent pour remonter au noeud puits, aussi appelé noeud maître dans la présente description, la valeur maximale, ceci de manière distribuée. Ainsi, en appliquant un traitement hiérarchique déployé sur tous les noeuds capteurs, le noeud 4 va récupérer les valeurs mesurées par les noeuds 4, 5, 7 et 8 et va reporter au noeud 1 la valeur maximale parmi les valeurs de température mesurées par les noeuds 4, 5 , 7 et 8. Des services plus complexes peuvent bien entendu être mis en oeuvre. Par exemple, un algorithme de détection distribué basé sur un arbre de décision peut être utilisé. Dans ce cas, les décisions intermédiaires sont prises par les divers noeuds capteurs, ce qui permettra d'aboutir à une décision. Une telle manière de procéder permet d'éviter de nombreuses communications. La figure 2 représente un exemple d'architecture multi-niveaux et des exemples de technologies orientées services SOA pouvant être utilisées aux différents noeuds de l'architecture. Une pile Web Services peut être implémentée au niveau des noeuds à forte capacité, la pile DPWS (Devices Profile for Web Services) pour les noeuds à capacité limité, la pile WSN-SOA pour les noeuds RCS. L'architecture présentée à la figure 2 permet la mise en oeuvre de services distribués de fusion impliquant des ressources capteurs et de traitements dans un système d'information complexe comme il est schématisé à la figure 3. Cette figure 3 présente la mise en collaboration de ressources capteurs et de traitements dans un système d'information complexe. Un tel système permet de fusionner des données issues des ressources capteurs. L'architecture décrite à la figure 3 comprend un réseau étendu 10 ou WAN (wide area network) auquel peuvent être connectés différents éléments, tels que des services en ligne 11, différents utilisateurs 12, des passerelles vers un réseau de capteurs 13, permettant à un réseau de capteurs sans fil 15 de communiquer avec le reste du système d'information. Un réseau ad hoc sans fil 16 est aussi dans cet exemple en liaison avec 13. Les étapes du procédé selon l'invention, permettent à l'utilisateur 12 de mettre en collaboration les ressources hétérogènes du système d'information (capteurs du réseau de capteurs 15, caméra IP par exemple). Le procédé selon l'invention nécessite un certain nombre de 5 composants logiciels et protocolaires pour fonctionner : Dans le cas le plus générique, un intergiciel permettant la communication entre les différents noeuds du réseau et les différents éléments mis en oeuvre par le procédé selon l'invention, ainsi qu'un mécanisme de routage permettant de relayer des messages entre les io noeuds. L'intergiciel de communication comprend, par exemple, des fonctions permettant les échanges de données, par exemple, par invocation, pas abonnement ou encore par publication, la découverte de services, tels que l'annuaire ou le mécanisme de requêtes Dans une application de type orienté services, le système peut 15 comporter : - Un intergiciel plus connu sous le terme anglo-saxon � midleware � ayant notamment pour fonction de supporter des services dans le cadre d'une architecture orientée service ; - Un mécanisme de routage réseau afin de relayer les messages, en 20 multi-sauts radio par exemple ; - De manière optionnelle, pour des cas d'applications spécifiques, un système de positionnement lorsque les déploiements de tâches doivent être réalisés dans une zone géographique particulière, dans ce cas la position du noeud doit être connue. 25 L'exemple qui va suivre est donné dans le cadre d'une approche orientée services pour la fusion de données, dans le but de mieux faire comprendre l'invention sans limiter ses applications possibles. Dans le cadre d'un réseau de type RCS équipé d'un intergiciel 30 orienté service, trois types de composants intervenant dans la création dynamique de services ou de traitements distribués de fusion sont distingués et illustrés à la figure 4 : Les services capteurs locaux A, B, C : ces services sont disponibles par défaut sur les noeuds. Ils peuvent être fonctionnellement 35 rattachés à des modules capteurs, par exemple des transducteurs. Ces services peuvent être plus ou moins évolués. Ils permettent, par exemple d'obtenir : - la dernière valeur mesurée par invocation, - la valeur mesurée en cas de changement significatif en utilisant les capacités de gestion événementielle de l'intergiciel SOA, - Les opérations basiques 21a, 21b, 21c ; il s'agit par exemple d'une bibliothèque de fonctions et opérations permettant la manipulation ou le traitement des données, par exemple, le filtrage, la moyenne, l'agrégation, la combinaison, - Les � services déployés 22a, 22b, 22c � ; ces services ou tâches sont des composants déployés sur les noeuds RCS. Ils utilisent les deux types de composants précités, qu'ils soient en local sur le noeud ou sur un noeud distant ; ceci afin de mettre en oeuvre le service distribué de fusion dans le RCS. La disponibilité de la bibliothèque des � opérations basiques � n'est pas un pré-requis à la mise en oeuvre du procédé. Ceci est fortement dépendant de la nature des traitements qui peuvent être mis en oeuvre au sein des � services déployés �. En revanche, la présence de cette bibliothèque est utilisée lorsque le système d'exploitation sur les noeuds RCS ne permet pas de déployer � à chaud � ou en temps réel du code. La figure 4 illustre la manière dont ces composants interagissent. Ainsi, un service ou � tâche � de détection 22 déployé sur le noeud capteur C utilise le service de positionnement en local 24, un autre service déployé 22b sur le noeud B, ainsi que des opérations de traitement de données disponibles en local sur le noeud B. De même, le service déployé 22b sur le noeud B utilise le service offrant les ressources du magnétomètre 24a sur le noeud A, ainsi que des opérations de traitement de données disponibles en local. Les services requis sont schématisés sur la figure par un demi-30 croissant 25 et les services fournis par un rond 26. Découpage en tâches : Les tâches devant être réalisées par les noeuds capteurs peuvent être assemblées sous la forme de fichier maître dont un exemple est donné à la figure 5. Ce fichier maître permet d'affecter des tâches spécifiques aux noeuds capteurs en fonction de propriétés comme, par exemple, leur identifiant, leur position ou la zone géographique où ils se trouvent. La description des tâches se fait principalement de deux manières : - Code à exécuter sur les noeuds RCS si le système d'exploitation tournant sur ces noeuds permet un déploiement à chaud ou en direct du code, ou - Scripts à interpréter sur les noeuds RCS. Des exemples de scripts sont donnés aux figures 6, 7 et 8 à titre ~o illustratif. La figure 6 spécifie un script pour l'envoi d'une alerte si une modalité surveillée dépasse un seuil prédéterminé ; la figure 7, l'envoi d'une alerte si deux modalités, ou paramètres, surveillées (e.g., température et lumière) dépassent toutes les deux une valeur seuil. La figure 8 est un exemple de script lorsque l'on souhaite exposer un nouveau service aux 15 autres noeuds capteurs. Le système ou dispositif permettant la mise en oeuvre des étapes du procédé décrites ci-avant, et donc la distribution de traitements coopérants distribués dans les réseaux de capteurs sans-fil, par exemple, 20 dans le cadre de l'exemple concernant une approche orientée service, décrit à titre illustratif et nullement limitatif comporte, notamment, les éléments suivants illustrés sur la figure 9 : 40 - Gestionnaire de déploiement de tâches (en anglais, Task deployment manager) : Ce module permet de recevoir en provenance d'une 25 passerelle non représentée sur la figure pour des raisons de simplification (en anglais, sink ou gateway) les tâches à traiter sur un noeud. II permet de gérer le cycle de vie des tâches déployées. La passerelle permet la communication avec le monde extérieur au système selon l'invention. Une tâche peut se trouver dans différents états au cours de son cycle de vie : 30 Installée : lorsque le code a été correctement déployé dans le noeud à partir de la passerelle. Arrêtée : lorsque les éventuelles dépendances face à d'autres services ou composants ont été résolues, mais la tâche n'est pas en cours d'exécution. 35 Démarrée : lorsque la tâche est en cours d'exécution. Non installée : lorsque, une fois arrêtée, la tâche est effacée du gestionnaire de déploiement et les ressources associées libérées. 41 - Dépôt de tâches (en anglais, Task repository) : Ce module stocke les différentes tâches reçues via le gestionnaire de déploiement de tâches 40. 42- Mémoire allouée (en anglais, Allocated memory) : Ce module peut être utilisé pour stocker les variables utilisées par les tâches. L'allocation peut se faire dynamiquement mais dans le cadre de l'utilisation de noeuds capteurs a très faible capacité comme les MicaZ elle est réalisée de manière statique à priori par le noeud passerelle. Dans ce dernier cas, la taille de la mémoire allouée est bornée par un maximum. 43 - Interpréteur de tâches (en anglais, Task processor) : Ce module gère l'exécution des tâches se trouvant dans le module de dépôt de tâches 41. II exécute chacune des instructions en faisant appel aux opérations de base 44, en récupérant les valeurs de modalités locales ou distante en provenance des services capteurs locaux 45 du noeud courant ou d'autres noeuds du réseau, en récupérant la valeurs de modalités crées dynamiquement via le gestionnaire de services dynamique 46. 44 - Opérations de base (en anglais, Basic operations) : Ce 20 module contient les opérations de base que les différentes tâches peuvent utiliser de manière séquentielle. II peut s'agir par exemple d'opérations : D'accès à des modalités distantes ou locales De détection de seuil De filtrage 25 D'agrégation De décision De création de services dynamiques Ces opérations, étant connues de l'Homme du métier, ne seront pas réexplicitées dans la présente demande de brevet. 30 45 - Services capteurs locaux (en anglais, Local sensor services) : Ce module contient l'ensemble des services locaux exposant les modalités disponibles par défaut sur le noeud. 46 - Gestionnaire de services dynamiques (en anglais, Service broker) : Ce module gère les services créés dynamiquement permettant aux 35 noeuds d'échanger de nouvelles modalités. Ainsi, lorsqu'une nouvelle modalité est rendue disponible par une tâche localement, ce module crée un service permettant aux autres noeuds du réseau de la découvrir et d'y accéder. La présence et l'interaction entre eux de ces différents éléments et modules sur un noeud permet de distribuer des traitements dans le cadre d'un service de fusion. II permet donc de réduire les coûts en communication que nécessite un procédé centralisé dans lequel toutes les données sont rapatriées sur les noeuds passerelle. Les modules 43, 45, 46, 40 sont en relation avec une pile WSNSOA, elle-même en liaison avec le système d'exploitation TinyOS. Ce procédé offre une grande tolérance aux pannes. Dans le cas de la défaillance ou disparition d'un capteur, le service distribué de fusion peut être reconfiguré totalement ou partiellement afin de modifier le placement des traitements et des différentes modalités utilisées. Sans sortir du cadre de l'invention, certains ou tous les éléments décrits ci-dessus peuvent être mis en oeuvre dans des réseaux filaires. Comme il a été défini précédemment pour l'architecture multiniveaux de la figure 2, les noeuds maîtres sont généralement des équipements avec des capacités supérieures en termes de traitement, de connectivité et d'autonomie, tels que des dispositifs embarquant un système d'exploitation GNU/Linux ou encore une machine virtuelle Java. Dans ces environnements, les capacités en termes de traitement permettent l'utilisation de mécanismes de déploiement de tâches existants. Lorsque une machine virtuelle Java est disponible, des socles logiciels comme OSGi sont particulièrement bien adaptés, car ils permettent d'effectuer des mises à jour sans redémarrer le système et de gérer le cycle de vie des tâches déployées. Le rôle des � noeuds maîtres � est de recueillir les informations du traitement distribué déployé dans le réseau RCS et de le présenter comme une fonctionnalité de haut niveau au système d'information, en masquant la complexité sous-jacente. Le système de déploiement pouvant être mis en oeuvre sur un � noeud maître � est composé, par exemple, des modules ayant les 35 fonctionnalités élémentaires représentées à la figure 10 : 51 - Dépôt des fichiers maîtres (en anglais, Task master repository) : ce module stocke les différents � fichiers maîtres � contenant chacun des tâches à déployer. Ces fichiers sont déposés par les services de type Web Services hébergés ou déployés sur le � noeud maître �. 52 û Module de prétraitement des tâches (en anglais, Tasks preprocessor) : ce module prépare chacune des tâches stockées dans le dépôt des fichiers maîtres 51 afin de qu'ils soient déployés plus tard par le gestionnaire de déploiement de tâches 56. Ce module peut par exemple binariser � les scripts dans un format adéquat, pré-allouer la mémoire en utilisant le module de gestion de la mémoire 53 et spécifier l'adressage des services en utilisant le module de gestion des services 54. 53 û Module de qestion de la mémoire (en anglais, Memory Manager) : ce module peut être utilisé pour allouer la mémoire utilisée par les tâches dans le cadre de l'utilisation de noeuds capteurs ne supportant pas l'allocation dynamique de mémoire. Dans ce dernier cas, une zone mémoire, connue de ce module, a été pré-allouée sur les noeuds capteurs. 54 û Module de qestion des services (en anglais, Global Service Broker) : ce module permet de transformer l'adressage des services qui était globale dans le � fichier maître � en adressage dédié dans les tâches déployées. 55 û Module de localisation des noeuds (en anglais, Node Locator) : ce module a en charge de maintenir les informations relatives à la position de noeuds. Il assiste le gestionnaire de déploiement des tâches dans le déploiement, lui indiquant lorsque nécessaire sur quel capteur un tâche doit être déployée. 56 - Gestionnaire de déploiement de tâches (en anglais, Tasks Deployment manager) : ce module réalise le déploiement d'une tâche sur un capteur en communiquant avec son module homologue présent sur les noeuds capteurs. Notons que le déploiement des tâches peut également se faire de manière épidémique dans certains cas. 57 û Interface entre les services (en anglais, Service Interface) : cette interface permet, une fois le service distribué de fusion déployé dans le RCS, au service de plus haut niveau de communiquer avec celui-ci de manière bidirectionnelle. Le module interface 57 est en liaison avec la pile WSN-SOA et les services Web 50. Un module de stockage 58 pour les tâches prétraitées (tâches qui sont traitées en amont du système selon l'invention) peut être disposé en amont du gestionnaire de déploiement des tâches 56 dans le cas où les tâches exécutées sur le noeud maître proviennent de modules extérieurs au système selon l'invention. Le procédé et les équipements disposés au niveau des noeuds peuvent être également utilisés dans le cadre de besoins en orchestration, io c'est-à-dire lorsqu'un ou plusieurs noeuds maîtres imposent et gèrent le déroulement d'actions au niveau des noeuds capteurs d'un réseau. Par exemple, on peut avoir besoin que la détection d'une présence par un capteur déclenche l'allumage d'une lumière commandée par un autre capteur. En d'autres termes, ce procédé s'applique à des réseaux composés 15 d'entités à très faibles capacités pouvant aussi bien jouer un rôle de capteur ou d'effecteur. La partie suivante de la description illustre la manière dont des services distribués de fusion peuvent être déployés sur différents type de 20 noeuds, de préférence des noeuds à capacité limitée. L'exemple qui suit va utiliser la coordination par une entité maîtresse d'un enchaînement d'appels à différents services généralement distribués dans le réseau qui se nomme � orchestration � et au comportement commun et complémentaire entre les services intervenant dans un traitement distribué, sans qu'un seul noeud soit 25 coordinateur se nomme � chorégraphie �. La figure 11 montre un exemple de déploiement dynamique d'un système de fusion distribué simple : Chaque noeud de faible capacité A et B exécute un gestionnaire de déploiement de tâches 40 et un module de stockage 41 avec des 30 composants déployés par défaut dont font partie les � services élémentaires � que l'on souhaite pouvoir utiliser. Par exemple le noeud A comprend un système de positionnement du noeud 60, un système de détection 61 Le noeud B comprend un algorithme de fusion 63. Les ronds 65 symbolisent une fonctionnalité mise à disposition des autres composants 35 locaux (lorsqu'ils sont représentés à l'intérieur du noeud) ou exposée en tant que service à d'autres noeuds (lorsqu'ils sont représentés à l'extérieur). Les crochets ou demi-lune 66 symbolisent qu'une fonctionnalité est requise par un composant. Les traits relient les fonctionnalités fournies et requises. Les figures en pointillés symbolisent les nouveaux composants et relations qui sont le résultat du déploiement dynamique. Dans cet exemple de déploiement dynamique de traitement distribué, deux nouvelles tâches sont déployées : sur le noeud A, une nouvelle tâche de détection de cible 62 utilise les fonctionnalités de détection et de positionnement existantes et expose sa fonctionnalité comme un nouveau service qui est disponible sur requête à tous les autres noeuds ; sur le noeud B, une nouvelle tâche de détection de cible distribuée 64 utilise le module 63 et fait appel au service distant de détection de cible 62. Son résultat es exposé au reste du réseau comme un nouveau service qui masque la complexité du fonctionnement distribué sous-jacent. Le même exemple avec des noeuds à plus fortes capacités peut utiliser des technologies existantes telles qu'OSGi pour le déploiement à chaud de nouveaux composants et la gestion de leur cycle de vie et de mécanismes additionnels de communication comme le service précité DPWS pour exposer les fonctionnalités en tant que services afin de les découvrir et consommer à partir d'autres noeuds. La figure 12 décrit le procédé complet, depuis la phase de conception du traitement distribué jusqu'au déploiement sur le réseau de noeuds à capacités hétérogènes. Cette partie décrit un des mécanismes possibles pour adresser le déploiement de traitements distribués de fusion sur un système hétérogène combinant les noeuds à capacité limitée et des noeuds réseau RCS. L'approche choisie met en avant l'interopérabilité avec les standards et outils existants. La référence 70 représente un schéma d'orchestration, c'est-à-dire un exemple d'enchaînement de tâches à exécuter sur différents noeuds 1, ...8 accessibles via une passerelle. La première étape consiste à décrire le comportement du traitement distribué en partant d'une librairie de composants 71 encapsulant des fonctionnalités prédéfinies, que ce soit : Pour des noeuds à faibles capacités, par exemple, moyenne, détection 35 de seuil... - Pour des noeuds à plus fortes capacités, par exemple transformée de Fourrier rapide FFT, opérations sur bases de données. Ce comportement est décrit en utilisant des outils graphiques 71 existant ou adaptés pour la définition de chorégraphie et orchestrations. Une fois le traitement défini, les fichiers de sortie au format XML sont lus et traits par un compilateur 72 qui, en se basant sur la librairie de composants 71, crée les éléments de déploiement unitaire 731, 732, 733, 734 pour chaque noeud, par exemple, un script pour les noeuds à faibles capacités et un paquetage ou en anglo-saxon bundle OSGi pour les moins contraints. Une console 74 permet ensuite de gérer le processus de déploiement sur le réseau 75 de noeuds choisi. Une console de gestion 76 permet de gérer l'activation ou arrêt du traitement distribué en contrôlant de façon distante le cycle de vie des tâches 15 de chaque noeud à travers leurs gestionnaires de tâches déployées. Le procédé selon l'invention permet avantageusement de déployer sur un ensemble de noeuds capteurs des traitements pouvant collaborer entre eux afin de créer un service distribué de fusion de données. Le 20 traitement déployé dans chaque noeud est un enchaînement de différentes fonctions nommées � tâches �. II est exposé au reste des noeuds comme un service. Le comportement global de l'ensemble des capteurs, c'est-à-dire la succession des échanges entre les différentes tâches de chaque noeud se nomme � traitement distribué. Son résultat est présenté comme un service 25 de haut niveau fourni par un seul macrocapteur. Ceci permettant la mise en oeuvre d'une architecture multi-niveaux distribués pour la fusion de données. Le procédé selon l'invention offre notamment la possibilité : - de décrire les tâches attribuées aux noeuds capteurs en utilisant des primitives dédiées pour la fusion de données, 30 - de déployer et exécuter ces tâches sur les noeuds capteurs sans avoir besoin de réinitialiser les noeuds, - de supporter la collaboration des tâches entre elles en utilisant une approche orientée service, - de distribuer des traitements de fusion de données impliquant la collaboration de noeuds de réseau RCS en utilisant une approche orientée services, - de s'interopérer avec des approches orientées services existantes du monde IP ou d'autres mondes, dans le cadre d'une architecture multiniveaux de traitements distribués collaboratifs pour la fusion de données. REVENDICATIONS1 - Système permettant le déploiement dynamique et/ou la création de tâches au sein d'un réseau comportant au moins un noeud maître (0) et plusieurs noeuds capteurs Ni ayant des capacités de traitement limitées, le réseau supportant un logiciel de communication et un mécanisme de routage permettant de relayer les différents messages échangés entre au moins les noeuds capteurs du réseau caractérisé en ce qu'il comporte au moins les éléments suivants : io Au niveau d'un noeud Ni de faible capacité du réseau : - Un gestionnaire de déploiement de tâches (40) ou de traitements, - Un module de stockage (41) desdites tâches (40) reçues via un gestionnaire de déploiement des tâches (56), - Un module interpréteur (43) desdites tâches, 15 - Une interface avec des capteurs locaux (45), Ces différents éléments coopèrent entre eux afin de distribuer les tâches ou traitements dans le cadre d'un service distribué au sein du réseau, Au niveau d'un noeud maître : - Un gestionnaire de déploiement de tâches (56). 20 2 ù Système selon la revendication 1, caractérisé en ce qu'un noeud maître comporte au moins un module de mémorisation de fichiers (51), un module de prétraitement des tâches (52) afin que lesdites tâches (40) puissent être déployées au niveau des différents noeuds ayant de faibles 25 capacités de traitement du réseau. 3 ù Système selon l'une des revendications 1 ou 2, caractérisé en ce qu'il comporte une interface (57) adaptée à assurer l'interopérabilité entre les tâches des noeuds et un service d'un niveau supérieur. 4 ù Système selon l'une des revendications 1 à 3, caractérisé en ce qu'un noeud Ni du réseau comporte au moins un module de localisation (55) dudit noeud dans le cas où certains services doivent être déployés sur des noeuds situés dans une zone géographique donnée. 30 355 û Système pour la création dynamique de services ou de traitements distribués selon l'une des revendications 1 à 4, caractérisé en ce que le logiciel de communication est un logiciel orienté service et en ce que les noeuds de faibles capacités comprennent des services capteurs locaux (45), des opérations basiques et des modules de services déployés. 6 û Système selon la revendication 5, caractérisé en ce qu'il comporte des services capteurs (20a, 20b, 20c) locaux adaptés à exécuter une des opérations suivantes : obtenir une dernière valeur mesurée par invocation, une valeur mesurée en cas de changement significatif en utilisant les capacités de gestion évènementielle propre à l'intergiciel orienté services. 7 û Système selon l'une des revendications 1 à 6, caractérisé en ce qu'il comporte un module d'opérations basiques (44) comprenant une bibliothèque de fonctions et d'opérations adaptés à traiter des données reçues au niveau des noeuds, telles que le filtrage des données, la moyenne, leur agrégation. 8 - Système selon l'une des revendications 1 à 7, caractérisé en 20 ce qu'un noeud capteur Ni est un noeud maître. 9 û Système selon la revendication 1, caractérisé en ce qu'il comporte une ou plusieurs opérations basiques (44) déployées avec les tâches ou se présentant sous la forme de bibliothèques. 25