The invention relates to a system and a method that notably enables the dynamic deployment of tasks or processing operations, such as services distributed within a wireless network of sensors. The sensor network can be an ad hoc network within which each unit, for example a node, communicates directly with its neighbour.
The invention is notably applicable in multi-level architectures. It is used in wired or wireless networks, and more generally in any network comprising nodes having limited processing capacity.
Wireless sensor networks, known by the abbreviation WSN, are composed of nodes characterized by the fact that they have radio communications capability, measurement capabilities via the use of transducers or of more complex modules, and of varying degrees of computing capability. These sensor nodes are usually networked using self-organizing functions like ad-hoc networks (better known as MANET RFC2501). In this case, since communication is in principal only possible between nodes within radio range, a routing protocol, known to those skilled in the art, then provides the relaying of data packets in order to guarantee connectivity from end to end when the network topology permits it. In WSN networks, the nodes may be mobile or otherwise. WSN networks have civilian applications for surveillance of critical infrastructures (classified factories, bridges), environmental monitoring (earthquake risks, agriculture, ecology), certain medical applications or for logistics, or alternatively military applications relating to surveillance missions.
The processing capacities of the sensor nodes encountered in WSN networks can be very variable depending on the equipment deployed. This could be deployable radar equipment requiring processing capabilities similar to those found on large servers, IP cameras having the capacity of a PDA (Personal digital Assistant) of small sensors called ‘motes’, such as the MICAz marketed by the company Crossbow, which are very limited in capacity: in computation power, low-capacity batteries, in limited bandwidth. The method according to the invention is notably applicable to WSN networks having low capacities. These WSN networks are more often than not connected to an information processing system in order to provide the data acquisition, to carry out more complex data fusion processing operations, or to guarantee their control and their reconfiguration. Owing to the complexity and to the variability of these information processing systems, SOA (Service Oriented Architecture) architectures are becoming more popular and deployed more often. The set of architecture principals defined for SOAs allows the functions to be separated into individual autonomous units, called Services, which may be distributed within the network, combined, and reused in order to create applications or other services. The major advantages of this approach are modularity, flexibility, low-level coupling and interoperability. Thus, the use of the SOA approach is particularly well suited to WSN networks. However, although the SOA architecture principals are often used on equipment having capacities at least of the order of those of a PDA, they are rare in very low capacity wireless sensor networks. In the present application, the term ‘very low capacity’ is aimed at equipment such as MICAz fitted with a microcontroller using a few kilobytes of RAM (e.g. 4 kb), with a low-power radio interface, and with limited battery power, for example two R6 batteries or any other type of system with equivalent characteristics. In data fusion operations involving WSN networks composed of very low capacity nodes, saving resources is vital to ensuring the survival of the network. Thus, in order to avoid the sensors sending the data they collect through a sink to a fusion centre situated outside of the WSN, it is preferable to distribute the processing operations over the data as much as possible so as to reduce communications costs. Reducing the communications costs mainly allows the lifetime of the WSN network to be extended by saving the batteries of the nodes. For example, when looking for a maximum, the sensors will be able, from neighbour to neighbour, to find this maximum value in a distributed fashion. Intermediate processing operations, used in the framework of a distributed fusion service, are limited by the capacity of the nodes receiving them. Thus, on MICAz, operations for filtering (e.g. threshold, Kalman filter), aggregation (e.g. average, sum, max-min) and conditional decisions (e.g. hierarchical classification) can be performed.
Service oriented approaches for wireless sensor networks have been the object of several studies. One specification known to those skilled in the art has defined an application layer introducing the concept of hosting service. Gateways allow Zigbee equipment networks to be interconnected (http://fr.wikipedia.org/wiki/zigbee) with the Web Services environment, notably a protocol stack designed for DPWS Web Services. Other authors have proposed a communications protocol at the applications level called μSOA. This protocol allows wireless sensor onboard Web Services to be accessed via a gateway. The WSN-SOA protocol stack (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) was introduced in the framework of a service-oriented multi-level architecture for sensor networks. This architecture is just as applicable to sensors having capacities similar to a PC, a PDA or to a MICAz sensor. The WSN-SOA stack allows services to be deployed in networks with very low capacities. It therefore allows support for data exchange between sensors but does not provide any specific functionality for fusion and the dynamic deployment of services.
Dynamic deployment of processing operations has also been the subject of proposals. One known solution is a system allowing wireless sensors to be totally reprogrammed by remotely re-flashing their memories.
Another known solution is a middleware for WSN networks allowing the use of mobile agents. Mobile agents are defined in the form of a programme with a syntax of a complexity similar to that of the assembler, interpreted on the sensors. Despite the fact that this middleware offers a wide range of operations, it takes up 3191 bytes of RAM in the MICAz only equipped with 4 Kb, which makes its availability incompatible with service-oriented protocol stacks such as those of WSN-SOA and also with the implementation of operations used for data fusion.
TENET architecture, 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, In Proc. ACM Sensys 2006, allows the processing operations to be distributed to the sensor nodes in the form of tasks. This allows the communications costs to be reduced by carrying out pre-processing on the sensors and also simple reconfiguration operations to be supported. However, TENET does not allow the sensors to collaborate with each other. The Telnet protocol stack is limited to the deployment of simple processing operations on the nodes. Each node is seen in an isolated and atomic fashion. Telnet does not allow the manner in which the tasks are to interact in distributed mode on the various low-capacity nodes to be defined.
The DAViM system (a Dynamically Adaptable Virtual Machine for Sensor Networks) proposed by Michiels et al., IEEE DISTRIBUTED SYSTEMS ONLINE, IEEE SERVICE CENTER, NEW YORK, NY, US, vol. 8, no. 1, 1 Jan. 2008, page 1, XP011204623, ISSN: 1541-4922, enables the parallel execution of several programmes (or tasks) and the addition on the fly of new instructions (‘operation libraries’) in the virtual machine according to the operational requirements. This system allows developers to re-deploy, for re-configuration operations, very light applications. This proposal does not address the communications between sensor nodes aspects nor does it provide support for collaboration.
The RASA architecture (Resource-Aware Service Architecture for Mobile Services in Wireless Sensor Networks) proposed by Blumenthal et al., COMPUTING IN THE GLOBAL INFORMATION TECHNOLOGY, 2006,ICCGI 2006. INTERNATIONAL MULTI-CONFERENCE ON BUCHAREST, ROMANIA 01-03 AUGUST 2006, PISCATAWAY, N.J., USA, IEEE, 1 Jul. 2006, XP031056602, ISBN: 978-0-7695-2629-4, allows new code to be injected on the fly into a sensor network in the form of ‘mobile agents’, small programmes that propagate from node to node in a viral fashion and are executed on all the nodes. With the aim of being reused, the basic functionalities are separated into ‘modules’ that can be concatenated in order to accomplish tasks (that they name ‘services’). In the case of the method of the present invention, the nodes have non-uniform functionalities (for example detection and warning) and each one executes a different code, while at the same time collaborating in order to accomplish a single global mission. The SOA approach of the method according to the invention allows, in changing environments, nodes having different functionalities to be uncovered and to dynamically concatenate their functionalities according to the context in order to accomplish a task in a collaborative manner.
In summary, the prior art known to the Applicant does not allow the way of integrating and establishing collaboration between all the individual processing operations deployed on networked sensor nodes to be defined in a simple and flexible manner. In particular, their teaching does not allow the following operations to be defined:
Some definitions and reminders useful for the understanding of the present Patent application will be given herein below.
The description is aimed at multi-level architectures allowing the integration of all the non-uniformity of the sensors, in terms of their variable processing capacities, present in a complex system.
In the multi-level architecture, three categories of nodes according to their network capacities and to their availability will be considered:
‘high capacity nodes’; the availability of these nodes is high given that they are permanently connected to the information processing system. They have no power supply problems and have a large processing capacity. (As an example, cartographic information servers connected to infrastructure networks may be mentioned.);
‘limited capacity nodes’; these nodes have limited capacities in terms of storage, batteries, computation power or network connectivity but can host operating systems such as the open software GNU/Linux (fr.wikipedia.org/wiki/Linux) or VxWorks (fr.wikipedia.org/wiki/VxWorks) and can carry out complex processing operations. These can be gateways, or sensor systems of variable performance (optronics, acoustics, etc.);
‘WSN nodes’; these nodes have extremely limited capacities. They are, for example, equipped with a few kbytes of RAM (Random Access Memory), only have one micro-controller and use a low-power radio technology such as the IEEE 802.15.4 standard. MICAz systems marketed by Crossbow are one example of equipment found in this category.
The integration of a WSN network into a complex system is achieved by using ‘master nodes’ that can be ‘high-capacity nodes’ or limited capacity nodes. In a complex information processing system, a WSN network is seen through master nodes as a sub-system. This terminology will be used to describe the subject of the present Patent application.
The idea of the present invention rests notably on the dynamic deployment of the data fusion services within low-capacity sensor networks, some examples of which have been previously given. The system notably offers the advantage of distributing processing operations within a wireless sensor network in order to create an optimised fusion service.
The invention relates to a system enabling the dynamic deployment and/or the creation of tasks within a network comprising at least one master node and several sensor nodes Ni having limited processing capacities, the network supporting a communications software application exposing the functionalities of each sensor node Ni as services on the said network and a mediation mechanism allowing communications between the services of various sensor nodes of the said network to be established, characterized in that it comprises at least the following elements:
The module for the basic operations of a node Ni of the network comprises at least one operation allowing a task executed on the said node to dynamically create a new service which will be exposed across the said network.
The said global mediation module for the services of a node Ni of the network comprises at least one module for uncovering the new services offered by one or more of the other nodes of the network.
The invention also relates to a system for the dynamic creation of services or of distributed processing operations according to the method described hereinabove, characterized in that it comprises a tool allowing a description of the behaviour of a distributed processing operation to be globally generated starting from a library of basic functions and a module transforming the said description into a set of individual tasks designed to be deployed on each of the sensor nodes Ni.
According to one variant embodiment, at least one node comprises a service gateway designed to ensure interoperability between the tasks being executed on sensor nodes Ni having limited processing capacities and services or tasks being executed on unconstrained nodes or on an information processing system.
The system for global description of the distributed processing operation and the library of basic functions allow tasks to be defined that are designed for nodes having non-uniform processing capacities, and the associated deployment module allows individual tasks generated to be deployed over nodes with non-uniform capacities, communicating via the said service gateway.
The system comprises, for example, a module for supervision and management of the tasks deployed, allowing the execution of the tasks deployed over the sensor nodes to be simulated, tested, supervised and reconfigured using the description of the global behaviour of the distributed processing operation.
According to one embodiment, the service oriented network communications module is a stack of the WSN-SOA type.
Other features and advantages of the device according to the invention will become more apparent upon reading the description that follows of one non-limiting exemplary embodiment, to which are appended the figures which show:
In order to facilitate understanding of the principal implemented by the invention, the following description is presented by way of example for a wireless network of sensors in order to create an optimised fusion service.
More complex services may of course be implemented. For example, a distributed detection algorithm based on a decision tree can be used. In this case, the intermediate decisions are taken by the various sensor nodes, which will allow a decision to be reached. Such a way of operating allows many communications to be avoided.
The architecture presented in
The architecture described in
The method according to the invention requires a certain number of software and protocol components in order to function:
In the most generic case, a middleware application enables communications between the various nodes of the network and the various elements implemented by the method according to the invention, together with a routing mechanism enabling messages to be relayed between the nodes. The communications middleware comprises, for example, functions enabling data to be exchanged, for example, by invocation, by subscription or alternatively by publication, and the exposure of services, such as the directory or the mechanism for requests.
In one application of the service oriented type, the system can comprise:
The example that follows is presented in the framework of a service oriented approach for data fusion with the aim of facilitating the understanding of the invention without limiting its possible applications.
For a network of the WSN type equipped with a service oriented middleware application, three types of components involved in the dynamic creation of services or of distributed fusion processing operations are identified and illustrated in
The local sensor services A, B, C: these are the default services available on the nodes. They may be functionally associated with sensor modules, for example transducers. These services can be of varying sophistication. For example, they allow the following to be obtained:
The availability of the library of ‘basic operations’ is not a pre-requisite to the implementation of the method. This is highly dependent on the nature of the processing operations that may be implemented within the ‘deployed services’. On the other hand, the presence of this library is used where the operating system on the WSN nodes does not allow code to be deployed ‘live’ or in real time.
The requested services are represented schematically in the figure by a half-crescent 25 and the services provided by a circle 26.
The tasks to be carried out by the sensor nodes can be assembled in the form of a master file an example of which is given in
The description of the tasks is done in two main ways:
Examples of scripts are given in
The system or device enabling the implementation of the steps of the method described hereinabove, and hence the distribution of distributed cooperating processing operations in the wireless sensor networks, for example, in the framework of the example relating to a service oriented approach, described by way of example and in a non-limiting manner, notably comprises the following elements illustrated in
40—Task deployment manager: This module allows the tasks to be processed on a node to be received from a gateway not shown in the figure for reasons of simplification. It allows the life cycle of the deployed tasks to be managed. The gateway allows communications with the world outside of the system according to the invention. A task can be in various states in the course of its life cycle:
Installed: when the code has been correctly deployed in the node using the gateway.
Halted: when any potential dependences vis-à-vis other services or components have been resolved, but the task is not being run.
Started: when the task is being run.
Uninstalled: when, once halted, the task is deleted from the deployment manager and the associated resources freed up.
41—Task repository: This module stores the various tasks received via the task deployment manager 40.
42—Allocated memory: This module can be used to store the variables used by the tasks. The allocation can be carried out dynamically but, where very low capacity sensor nodes such as the MICAz are used, it is carried out statically in principal by the node gateway. In this latter case, the size of the allocated memory is bounded by a maximum.
43—Task processor: This module manages the execution of the tasks located in the task repository module 41. It executes each of the instructions by making use of the basic operations 44, by recovering the local or remote modality values coming from the local sensor services 45 of the current node or other nodes of the network, by recovering the modality values created dynamically via the dynamic services manager 46.
44—Basic operations: This module contains the basic operations that the various tasks can use in a sequential fashion. These can for example be operations for:
45—Local sensor services: This module contains all of the local services exposing the default modalities available on the node.
46—Dynamic services manager or Service broker: This module manages the services created dynamically allowing the nodes to exchange new modalities. Thus, when a new modality is made available locally by a task, this module creates a service allowing the other nodes of the network to discover it and to access it. The service notably establishes contact between the tasks of the various nodes delivering and consuming services via the service oriented communications module 47. This module or manager comprises at least one module for discovering new services offered by one or more of the other nodes of the network.
47—A service oriented communications module exposing the internal functionalities of other nodes of the network through input and output interfaces formally described in the form of an ‘interface contract’ and allowing services on other nodes of the network to be controlled. In one non-limiting application example, the communications module is a stack of the WSN-SOA type.
The presence and the mutual interaction of these various elements and modules on a node allow processing operations to be distributed in the framework of a fusion service. This therefore allows the communication costs to be reduced that are required by a centralised method in which all the data are downloaded over the gateway nodes.
The modules 43, 45, 46, 40 are in contact with a WSN-SOA stack, itself in communication with the operating system TinyOS.
This method offers a high tolerance to faults. In the case of the failure or disappearance of a sensor, the distributed fusion service can be totally or partially reconfigured in order to modify the placement of the processing operations and of the various modalities used.
Without straying from the scope of the invention, some or all the elements described hereinabove can be implemented in wired networks.
As has been previously defined for the multi-level architecture in
The role of the ‘master nodes’ is to collect information from the distributed processing operation deployed in the WSN network and to present it as a high-level functionality to the information processing system, while masking the underlying complexity.
The deployment system that can be implemented on a ‘master node’ is composed, for example, of the modules with the elementary functionalities shown in
51—Task master repository: this module stores the various ‘master files’ each containing tasks to be deployed. These files are deposited by the services of the Web Services type hosted or deployed on the ‘master node’.
52—Tasks pre-processor: this module prepares each of the tasks stored in the task master repository 51 so that they are deployed later by the task deployment manager 56. This module can for example ‘binarise’ the scripts in a suitable format, pre-allocate the memory using the memory manager 53 and specify the addressing for the services using the service management module 54.
53—Memory Manager: this module can be used to allocate the memory used by the tasks in the case where sensor nodes are used that do not support the dynamic allocation of memory. In this latter case, a memory space, known to this module, has been pre-allocated on the sensor nodes.
54—Global Service Registry: this module keeps a list of the nodes and of their services up to date and allows the addressing of the services, which was global in the ‘master file’, to be transformed into dedicated addressing in the deployed tasks.
55—Node Locator: this module is responsible for maintaining the information relating to the node positions. It assists the task deployment manager in the deployment, telling it, where necessary, on which sensor a task must be deployed.
56—Task Deployment manager: this module carries out the deployment of a task on a sensor by communicating with its peer module present on the sensor nodes. It should be noted that the deployment of the tasks can also be carried out in an epidemic manner in some cases.
57—Service Gateway: once the distributed fusion service has been deployed in the WSN, this module allows the highest level service to communicate with the latter in a bi-directional manner. The gateway module notably has the function of ensuring the interoperability between the tasks running on sensor nodes Ni having limited processing capacities and services or tasks running on unconstrained nodes or on an information processing system.
The service gateway 57 is in communication with the service oriented communications module 47, which can be a WSN-SOA stack, and the Web services 50.
58—A storage module for the pre-processed tasks (tasks that are processed upstream of the system according to the invention) can be disposed upstream of the mediation module 56 in the case where the tasks executed on the master node originate from modules external to the system according to the invention.
59—A service oriented communications module, equivalent to the module 47 for ‘master nodes’.
The method and the devices disposed at the nodes can also be used for orchestration needs, in other words when one or more master nodes impose(s) and manage(s) the sequence of actions on the sensor nodes of a network. For example, it may be required that the detection of a presence by a sensor triggers the switching on of a light controlled by another sensor. In other words, this method is applicable to networks composed of entities with very low capacities that can equally well play the role of sensor transforming the physical phenomena into electrical signals or of effecter allowing electrical signals to be transformed into physical phenomena.
The following part of the description illustrates the manner in which distributed fusion services may be deployed on various types of nodes, preferably nodes with limited capacity. The following example will use the coordination by a master entity of a succession of calls to various services generally distributed within the network which is referred to as ‘orchestration’ and the common and complementary behaviour between the services involved in a distributed processing operation, without one single node being coordinator, which is referred to as ‘choreography’.
Each low-capacity node A and B runs a task deployment manager 40 and a storage module 41 with components deployed by default which include the ‘elementary services’ that it is desired to be able to use. For example, the node A comprises a positioning system for the node 60, a detection system 61, and the node B comprises a fusion algorithm 63. The circles 65 symbolise a functionality made available to the other local components (when they are shown inside the node) or exposed as a service to other nodes (when they are shown outside). The brackets or half-moons 66 symbolise that a functionality is requested by a component. The lines connect the functionalities delivered and requested. The dashed-line figures symbolise the new components and relationships that are the result of the dynamic deployment.
In this example of dynamic deployment of distributed processing operation, two new tasks are deployed: on the node A, a new target detection task 62 uses the existing functionalities of detection and of positioning and exposes its functionality as a new service which is available upon request to all the other nodes; on the node B, a new distributed target detection task 64 uses the module 63 and calls upon the remote target detection task service 62. Its result is exposed to the rest of the network as a new service which masks the complexity of the underlying distributed operation.
The same example with higher capacity nodes can use existing technologies such as OSGi for the live deployment of new components and the management of their life cycle and of additional communication mechanisms, such as the aforementioned DPWS service, in order to expose the functionalities as services so as to uncover and consume them using other nodes.
The first step consists in describing the behaviour of the distributed processing starting from the library of basic functions 70 encapsulating pre-defined functionalities, whether this be:
This behaviour is described using existing graphics tools 70 or tools designed for the definition of choreography and orchestrations.
Once the processing has been defined, the output files in XML format are read and processed by a compiler 72 which, based on the library of components 70, creates individual tasks 731, 732, 733, 734 for each node; for example, a script for the low-capacity nodes and an OSGi bundling for those with lesser constraints.
A terminal 74 then allows the process of deployment onto the chosen network 75 of nodes to be controlled.
A module for supervision and management of the deployed tasks 76 allows the execution of the tasks deployed on the sensor nodes to be simulated, tested, supervised and reconfigured based on the description of the global behaviour of the distributed processing 71.
The method according to the invention advantageously allows processing operations able to collaborate with one another to be deployed on an array of sensor nodes in order to create a distributed data fusion service. The processing operation deployed within each node is a succession of various functions called ‘tasks’. It is exposed to the rest of the nodes as a service. The global behaviour of the array of sensors, in other words the succession of the exchanges between the various tasks of each node, is named ‘distributed processing’. Its result is presented as a high-level service delivered by a single macro sensor. This allows a distributed multi-level architecture to be implemented for data fusion.
The method according to the invention notably offers the possibility:
Number | Date | Country | Kind |
---|---|---|---|
08/06553 | Nov 2008 | FR | national |