The combination of recent technological advances in electronics, nanotechnology, wireless communications, computing, networking, and robotics has enabled the development of Wireless Sensor Networks (WSNs), a new form of distributed computing where sensors (tiny, lowcost and low-power nodes, colloquially referred to as ”motes”) deployed in the environment communicate wirelessly to gather and report information about physical phenomena. WSNs have been successfully used for a variety of applications, such as environmental monitoring, object and event detection or military surveillance. The increasing expectations and demands for greater functionality and capabilities from these devices often result in greater software complexity for applications. Sensor and actor programming is a tedious error-prone task usually carried out from scratch. In order to facilitate the software development of this kind of system new tools and methodologies must be proposed. Middleware can simplify the creation and configuration of WSAN applications offering a set of high level services. The component-oriented paradigm seems to be a good alternative to define middleware. Software components offer several features (reusability, adaptability, ...) very suitable for WSANs which are dynamic environments with rapidly changing situations. Moreover, there is an increasing need to abstract and encapsulate the different middleware and protocols used to perform the interactions between nodes. However, the classical designs of component models and architectures (.NET, COM, JavaBeans) either suffer from extensive resource demands (memory, communication bandwidth, ...) or dependencies on the operating system,protocol or middleware. For this reason we propose to use UM-RTCOM , a previous development focused on software components for real-time distributed systems adapted to the unique characteristics of WSANs. The model is platform independent and uses light-weight components which make the approach very appropiate for this kind of system. In addition UM-RTCOM uses an abstract model of the components which allows different analysis to be performed, including real-time analysis. In order to facilitate the development of WSAN applications we propose a novel middleware called MWSAN. It is specified with UM-RTCOM allowing us to define real time characteristics such as, establishing timing requirements (priority, periods,...) in the services and then to improve the temporal behavior of applications, attending to the most critical events first. MWSAN is composed of several components that provide a set of primitives related to sensor/actor interconnection, quality of service (QoS) and the actor coordination. These issues are very important and necessary and we think that high level primitives will simplify the work of the designers. The middleware is highly configurable in order to fit in with the limitations of sensorsand actors. For example, the middleware for motes does not include the component for actor coordination thereby reducing the required memory space. In order to implement our proposals, automatic tools will map the UM-RTCOM specification of MWSAN to RT Java source code using an implementation called jRate for actors. jRate allows us to meet the timing specifications of UM-RTCOM, implementing a priority based application where the highest priority events received by actors will be executed first. In the case of motes, due to the limited resources, tools will map MWSAN to nesC, a component language for sensorson TinyOS.
Some approaches have incorporated the componentoriented paradigm to deal with WSAN programming. The most used is possibly nesC. This is an event-driven component-oriented programming language for networked embedded systems. Our proposal, UM-RTCOM, presents a higher level concurrency model and a higher level shared resource access model. In addition, real-time requirements of WSAN applications can be directly supported by means of the model primitives and the abstract model provided,reflecting the component behavior, which allows real-time analysis to be performed. Other languages such as Esterel, Signal, and Lustre target embedded, hard realtime, control systems with strong time guarantees but they are not general purpose programming languages. Much work has targeted the development of coordination models and the supporting middleware in the effort to meet the challenges of WSNs. However, since the above listed requirements impose stricter constraints, they may not be suitable for application to WSANs. In UM-RTCOM is used to specify a coordination model based on tuple channels. The use of this component model allowed us to include real time characteristics in the tuple channels improving the application performance. 1.2 Operational Setting Our reference operational setting is based on an architecture where there is a dense deployment of stationary sensors forming clusters, each one governed by a (possibly mobile) actor. Communication between a cluster actor and the sensors is carried out in a single-hop way. Although singlehop communication is inefficient in WSNs due to the long distance between sensors and the base station, in WSANs this may not be the case, because actors are close to sensors. Our approach, however, does not preclude the possibility of having one of these sensors acting as the “root”of a sensor “sub-network” whose members communicate in a multi-hop way. Therefore, this root sensor cannot send only its sensor measurements to the actor but also the information collected from the multi-hop sub-network. On the other hand, several sensors may form a redundancy group inside a cluster. The zone of the cluster monitored by a redundancy group will still be covered in spite of failures or sleeping periods of the group members. Several actors may form a (super-)cluster which is governed by one of them, the so-called cluster leader actor. It takes centralized decisions related to the task assignment or QoS for the actors. Moreover, clustering together with the single-hop communication scheme minimizes the eventtransmission time from sensors to actors, which helps to support the real-time communication required in WSANs.
Some approaches have incorporated the componentoriented paradigm to deal with WSAN programming. The most used is possibly nesC. This is an event-driven component-oriented programming language for networked embedded systems. Our proposal, UM-RTCOM, presents a higher level concurrency model and a higher level shared resource access model. In addition, real-time requirements of WSAN applications can be directly supported by means of the model primitives and the abstract model provided,reflecting the component behavior, which allows real-time analysis to be performed. Other languages such as Esterel, Signal, and Lustre target embedded, hard realtime, control systems with strong time guarantees but they are not general purpose programming languages. Much work has targeted the development of coordination models and the supporting middleware in the effort to meet the challenges of WSNs. However, since the above listed requirements impose stricter constraints, they may not be suitable for application to WSANs. In UM-RTCOM is used to specify a coordination model based on tuple channels. The use of this component model allowed us to include real time characteristics in the tuple channels improving the application performance. 1.2 Operational Setting Our reference operational setting is based on an architecture where there is a dense deployment of stationary sensors forming clusters, each one governed by a (possibly mobile) actor. Communication between a cluster actor and the sensors is carried out in a single-hop way. Although singlehop communication is inefficient in WSNs due to the long distance between sensors and the base station, in WSANs this may not be the case, because actors are close to sensors. Our approach, however, does not preclude the possibility of having one of these sensors acting as the “root”of a sensor “sub-network” whose members communicate in a multi-hop way. Therefore, this root sensor cannot send only its sensor measurements to the actor but also the information collected from the multi-hop sub-network. On the other hand, several sensors may form a redundancy group inside a cluster. The zone of the cluster monitored by a redundancy group will still be covered in spite of failures or sleeping periods of the group members. Several actors may form a (super-)cluster which is governed by one of them, the so-called cluster leader actor. It takes centralized decisions related to the task assignment or QoS for the actors. Moreover, clustering together with the single-hop communication scheme minimizes the eventtransmission time from sensors to actors, which helps to support the real-time communication required in WSANs.
7 comments:
hey u havent mentioned anything about WSN using nano....
please give us some valuable info...
u r our hope
i am still not able to understand that is there any practical usage or the proposal is still laid on WSN using CNT...
well can anyone tell me whats is use of WSN, i m still unable to catch the point.
hey just tell me one thing that can we use MEMS devices to make humidity sensor for WSN to get the total radiation power required so that we can optimize the total power output....
please suggest some quality ebooks for this topic, i m an under-grad. student at MIT university...
i m regular visitor to ur blog. this is a very helpful blog for me. so please help me to get more into this topic.
sir is the WSN same as MEMS WSN network or they r different..
please guide me
hey yr......nice blog...gud job..
Post a Comment