This leads to the recent boom of simulator development. However, obtaining solid conclusions from a simulation study is not a trivial task. There are two key aspects in WSNs simulators: 1 The correctness of the simulation models and 2 the suitability of a particular tool to implement the model. The fundamental tradeoff is: precision and necessity of details versus performance and scalability. In the rest of this survey, several main-stream WSNs simulators are described and compared in more detail.
However, Trace-Driven Simulation [Jain91] provides different services. This kind of simulation is commonly used in real system. The simulation results have more credibility. It provides more accurate workload; these detail information allow users to deeply study the simulation model. Usually, input values in this simulation constant unchanged. However, this simulation also contains some drawbacks.
For example, the high-level detail information increases the complexity of the simulation; workloads may change, and thus the representativeness of the simulation needs to be suspicious. In this survey, seven main-stream simulation tools are categorize into this two types, the detail information are described in section 3.
However, this simulator has some limitations. Firstly, people who want to use this simulator need to familiar with writing scripting language and modeling technique; the Tool Command Language is somewhat difficulty to understand and write. Secondly, sometimes using NS-2 is more complex and time-consuming than other simulators to model a desired job. Fourthly, due to the continuing changing the code base, the result may not be consistent, or contains bugs. The NRL sensor network extension provides a flexible way of modeling physical phenomena in a discrete event simulator.
Physical phenomena are modeled as network nodes which communicate with real nodes through physical layers. Basic components in ns-2 are the layers in the protocol stack. They implement the handlers interface, indicating that they handle events. Events are communication packets that are passed between consecutive layers within one node, or between the same layers across nodes. The key advantage of ns-2 is its rich libraries of protocols for nearly all network layers and for many routing mechanisms.
These protocols are modeled in fair detail, so that they closely resemble the actual protocol implementations. The key design decisions on building TOSSIM were to make it scalable to a network of potentially thousands of nodes, and to be able to use the actual software code in the simulation.
To achieve these goals, TOSSIM takes a cross-compilation approach that compiles the nesC source code into components in the simulation. The simulator event queue delivers the interrupts that drive the execution of a node. The upper-layer TinyOS code runs unchanged. A network is a directed graph, where each vertex is a sensor node and each directed edge has a bit- error rate.
Each node has a private piece of state representing what it hears on the radio channel. By setting connections among the vertices in the graph and a bit-error rate on each connection, wireless channel characteristics, such as imperfect channels, hidden terminal problems, and asymmetric links can be easily modeled.
Wireless transmissions are simulated at the bit level. If a bit error occurs, the simulator flips the bit. TinyViz also provides mechanisms to control a running simulation by, for example, modifying ADC readings, changing channel properties, and injecting packets. Beside the default visual interfaces, users can add application- specific ones easily. Deeply rooted in these applications is the notion of states of physical phenomena and models of their evolution over space and time.
Some of these states may be represented on a small number of nodes and evolve over time, as in the target tracking problem, while others may be represented over a large and spatially distributed number of nodes, as in tracking a temperature contour. A distinctive property of physical states, such as location, shape, and motion of objects, is their continuity in space and time.
Their sensing and control is typically done through sequential state updates. This formulation is broad enough to capture a wide variety of algorithms in sensor fusion, signal processing, and control e.
However, in distributed real-time embedded systems such as sensor networks, the formulation is not as clean as represented in the above equations. The relationships among subsystems can be highly complex and dynamic over space and time. The following issues which are not explicitly tackled in the above equations must be properly addressed during the design to ensure the correctness and efficiency of the system. Is it a constant? These issues, addressing where and when, rather than how, to perform sensing, computation, and communication, play a central role in the overall system performance.
State-centric programming aims at providing design methodologies and frameworks that give meaningful abstractions for these issues, so that system designers can continue to write algorithms on top of an intuitive understanding of where and when the operations are performed. A collaborative group is such an abstraction. A collaborative group is a set of entities that contribute to a state update.
These entities can be physical sensor nodes, or they can be more abstract system components such as virtual sensors or mobile agents hopping among sensors. These are all referred to as agents. Intuitively, a collaboration groups provides two abstractions: its scope to encapsulate network topologies and its structure to encapsulate communication protocols. A software agent that hops among the sensor nodes to track a target is a virtual node, while a real node is physical sensor.
Limiting the scope of a group to a subset of the entire space of all agents improves scalability. Grouping nodes according to some physical attributes rather than node addresses is an important and distinguishing characteristic of sensor networks. Are all members in the group equal peers? Do members in the group form a tree with parent and children relations? For example, a group may have a leader node that collects certain sensor readings from all followers.
By mapping the leader and the followers onto concrete sensor nodes, one can effectively define the flow of data from the hosts of followers to the host of the leader.
The notion of roles also shields programmers from addressing individual nodes either by name or address. Furthermore, having multiple members with the same role provides some degree of redundancy and improves robustness of the application in the presence of node and link failures. It is implemented in a mixed Java-Matlab environment. A principal is the key component for maintaining a piece of state. Typically, a principal maintains state corresponding to certain aspects of the physical phenomenon of interest.
The role of a principal is to update its state from time to time, a computation corresponding to evaluation function f. To update its portion of the state, a principal may gather information from other principals. To achieve this, a principal creates port agents and attaches them onto itself and onto the other principals.
A port agent may be an input, an output, or both. Observers may be active and passive. An active observer pushes data autonomously to its destination s0, while a passive observer sends data only when a consumer requests for it. A principal typically attaches a set of observers to other principals and creates a local input port agent to receive the information collected by the remote agents.
Thus port agents capture communication patterns among principals. The execution of principals and port agents can be either time-driven or event-driven, where events may include physical events that are pushed to them i.
Principals maintain state, reflecting the physical phenomena. How often the principal states need to be updated depends on the dynamics of the phenomena or physical events.
The executions of observers, however, reflect the demands of the outputs. If an output is not currently needed, there is no need to compute it.
To ensure consistency of state update over a distributed computational platform, PIECES requires that a piece of state, say x s, can only be maintained by exactly one principal.
Note that this does not prevent other principals from having local caches of x s for efficiency and performance reasons; nor does it prevent the other principals from locally updating the values of cached x s.
However, there is only one master copy for x s. This asymmetric access of variables simplifies the way shared variables are managed. References [1] J. Hill, R. Szewcyk, A. Woo, D. Culler, S. Hollar, and K. Savvides and M. Chandrakasan, R.
Min, M. Bhardwaj, S-H Cho, and A. Kahn, R. Katz, and K. Rabaey, J. Ammer, J. Patel, and S. Silberschatz, P. Galvin, and G. Gay, P. Levis, R. Welsh, E. Brewer, and D. Cagali, J-P Hubaux, and C. Levis, N. Lee, M. Welsh, and D. We examine for each approach its modeling language, scopes, and elements. The system is modeled as a collection of processes and channels.
The SDL approach provides the modeling of node behaviors and does not permit the modeling of the network architecture. Moreover, the generated code is created manually by the designer. Authors proposed the Insense language in [ 39 ] for supporting a component-based model for WSN applications. Components can be hardware or software entities of sensor nodes, and they communicate synchronously via directional channels which abstract over communication and synchronization.
This technique does not support the modeling of a WSN system architecture. Authors introduced the SensorML [ 40 ] language in order to provide support for modeling sensor specifications such as physical location, hardware, and sensor type. In the SensorML model, components are represented as processes linked together through inputs and outputs.
The model includes physical elements such as sensors and actuators and nonphysical components such as mathematical equations. SensorML supports the modeling of different elements of the network.
But it lacks support for testing and validating the design before its real deployment. The UM-RTCOM model, which is developed in [ 41 ], presents a component framework for developing wireless sensor and actor network applications. This model contains sensors, actors, and a coordinator. The communication between sensors and actors and between actors and a coordinator is via channels which are modeled as a tuple that allows one-to-many and many-to-one communication.
Authors proposed in [ 42 ] a framework for modeling, simulation, and generation of code for WSN applications based on MathWorks tools. Sensor nodes are modeled by using Stateflow and Simulink blocks. Connectivity between sensor nodes is represented by a communication medium block which is implemented on the C language.
MathWorks provides analysis tools such as animated state charts, chart displays, and scopes to perform WSN analysis.
SystemC-AMS models the system behavior using a data flow diagram. However, this technique does not support the network architecture modeling. Another related work was proposed in [ 45 ]. Each node is captured as a module which contains methods and variables describing the node behavior, power consumption, memory, and communication capabilities. The network is modeled by using communicating finite-state machines. A component-based architecture for adaptive WSN was developed in [ 47 ].
Authors used middleware development to enable adaptability in service-oriented WSNs. The reference architecture is created based on layer architectural style, component-based and service-oriented architectural style, and decorator pattern. In this work, verification and test phases are absent. The reviewed component-based techniques enable designers to represent the WSN design at higher abstraction levels, which facilitates testing and verification of errors before the real deployment.
They used different modeling languages to capture WSN features. They tackle either the node behavior or the WSN system architecture. Despite its benefits, none of the presented techniques have presented standard modeling languages to address the behavior and the structure of the WSN design at a much higher level of abstraction. In this context, MDE design methodologies are relatively leveraged. MDE affords many of the benefits to software engineering. An overview of the MDE paradigms will be accurately described in the following section.
Then, we provide a view on design pattern-based approaches. The MDE [ 12 ] paradigm is a software engineering approach based on exploiting models in order to address the complexity of embedded systems. This software development methodology deals with the shortcomings of complex system development and reduces the system development costs and time. The MDE has widely contributed to supporting the development life cycle of embedded systems in many fields such as WSN design and development [ 48 — 50 ], energy supply designs for WSN [ 51 ], and self-adaptive system development [ 52 , 53 ].
The MDE has several advantages. First, this approach is aimed at increasing the abstraction level of development and at discarding the low-level details. Second, MDE permits being less prone to error, because it enables the system analysis at an early design stage, which permits revealing errors before the real network deployment. Third, MDE permits a set of model transformations and refinements in order to generate codes or analyze systems. Therefore, the code generation task becomes easier than in traditional software techniques.
The MDE is based on several basics and concepts [ 54 ], namely, the model, the metamodel, the model transformation concept, and the UML extension mechanisms. It helps in reducing the design complexity of WSN applications through its principles of abstraction, separation of concerns, reuse, and automation.
We are interested in power supply modeling, on the one hand, and in reconfiguration modeling for WSN, on the other hand. Energy efficiency represents a primary key for most research studies, so does the need for abstracting energy details.
In this context, an MDE-based framework methodology is proposed in [ 49 ]. It is aimed at defining an architecture for WSN and focuses on energy consumption analysis. This framework proposed three modeling languages that allow modeling separately the software architecture of the WSN application Software Architecture Modeling Language , the low-level details of each type of nodes used in the network Node Modeling Language , and the physical environment where the WSN nodes are deployed Environment Modeling Language.
The proposed metamodel of the Node Modeling Language is composed of stereotypes permitting defining the node features. It uses EnergySource and HarvestedEnergySource stereotypes to model energy information, the RadioCommunicationDevice stereotype to present the transceiver unit, the Sensor stereotype to model sensors, and the Node stereotype and the NodeSpecification stereotype to represent sensor nodes.
An analysis step is also performed through automatic code generation. Another high-level application model was introduced in [ 55 ], which is composed of a feature model and a class diagram annotated with the WiSeN profile to support WSN modeling. First, the model defines different features related to application, network, programming language, hardware, and communication in the WSN.
This profile has extended the MARTE profile by a set of stereotypes in order to allow the specification of complementary information for WSN features, such as the Sensor stereotype extending «HwSensor» to map sensors and their characteristics and the Synchronize stereotype extending «SynchronizationResource» used to model synchronization between sensor nodes.
It uses the MsgPackage stereotype extending «MessageComResource» to give information about the structure of message. It uses the Gateway stereotype to assist in the communication with the external system. The WiSeN profile can be refined and extended to address the power supply section where the limited energy is the most important constraint in WSNs.
Four main elements are defined in the design: energy scavenging device, energy accumulating device, consumption of the node, and recharging energy. This methodology provides an extension to support harvesting done by a solar panel so we can extend the MARTE profile to support more energy harvesting such as vibration.
In addition, the WSN requirements e. To address the design of adaptive WSN, multiple works have been proposed. Authors provided in [ 56 ] a model-driven approach for designing and verifying autonomic network behaviors. They used a generic control loop based on the decision-making element for establishing the autoconfiguration in the network.
They proposed a model-driven methodology based on metamodeling, structural modeling, and behavioral modeling methods. Then, they provided an evolvable and holistic model for autonomic networking and autoconfiguration.
But still the autonomic code generation is not defined for validation and verification purposes. Another work was proposed in [ 57 ], which deals with adaptive sensor networks.
Matilda permits the automatic code generation through M2T transformation from the proposed UML profile. The BiSNET consists of agents and middleware platforms in order to achieve adaptability requirements. In [ 58 ], authors proposed an MDE approach to develop WSN application, which allows the flexibility and reusability of their designs. They considered three levels of abstraction: domain-specific models, platform-independent models, and platform-specific models.
Then, automatic model transformations are refined until the final code is produced. To achieve the autonomic adaptation, authors used the MAPE loop model [ 17 ]. MAPE loop modules are used to monitor the different sensor states in order to enable the system functionalities.
To deal with the increasing complexity of WSN systems, several works have proposed the use of high-level methodologies to fulfill the strict WSN constraints and facilitate the development process.
Most reviewed approaches used high-level modeling concepts to specify several WSN basics. In other cases, some approaches proposed a whole development cycle that starts with a modeling step to lead to a validation step through a set of model transformation rules.
Nonetheless, the relevant existing studies still present some limitations. There is a lack of adaptation process that designs and validates WSN models. In addition, most adaptive works address the node-level-based reconfiguration scenario. They deal with hardware reconfiguration such as sensor node adaptation and software reprogramming such as OS programming. However, architectural reconfiguration is not well tackled in high-level modeling.
In addition, MAPE loop modules are not considered in the modeling phase. On the other hand, explicit support for power requirement modeling is absent.
Accordingly, there is a lack of high level abstraction modeling of energy harvesting modules. Moreover, NFP verification and validation steps are not well performed. The use of high-level modeling languages and methodologies helps designers to cope with the growing complexity of WSN systems. Nevertheless, there is still a great need for generic and reusable models to help designers to easily model their systems.
In this regard, design patterns [ 14 ] represent a promising solution since they promote generic models used to propose solutions for recurrent problems. We give in the following some basic definitions on design patterns, and we recall existing pattern-based works for WSN development. Design patterns [ 14 ] are widely affirmed as a potential approach towards software design. A design pattern is used to capture the application flow and the design components at a higher abstraction view that guarantees the reusability of the design.
Indeed, a design pattern is a general and reusable solution to a recurrent problem in software design. It has been proven to be highly effective in modeling and representing complex systems. In addition, it facilitates the reuse of software models and improves the quality of software. Each design pattern is described by essential elements following the pattern template proposed in [ 14 ].
A pattern name is a handle that helps in identifying the pattern, its intent, and its solution. The pattern intent describes the goal behind the design pattern.
The pattern problem consists in defining the context of pattern application. Lastly, the pattern structure is a graphical representation of the pattern where class and sequence diagrams can be used. With the growing development of WSNs and the programming challenges of sensor nodes, software designers have shown a significant interest in representing design patterns for WSN development.
In this context, a design pattern for a sensor node was developed in [ 60 ]. The proposed pattern described the architecture of a sensor node which includes sensors, a power source, communication channels, and memory.
Authors presented the static and dynamic aspects of the proposed pattern using, respectively, the UML class diagram and UML sequence diagram. Another related work is proposed in [ 61 ] that used the previous pattern to design the structure of the network and connections between devices in order to achieve performance objectives. Authors presented dynamic diagrams of several use cases which include network reconfiguration, data gathering, and others. Another software design pattern is described in [ 62 ] for the TinyOS operating system which is well described in WSN applications.
They presented two behavioral design patterns, dispatcher and decorator, and three structural design patterns. In [ 63 ], authors presented a set of design patterns using UML diagrams that help designers in defining a software design of middleware and hardware modules for a WSN system in order to optimize analysis for power consumption at an early stage of development. Several design patterns are defined in [ 64 ] for unifying different abstractions and middleware such that users can manipulate various WSNs using different programming languages.
In [ 65 ], authors proposed a programming pattern named sMapReduce for enabling sensor network applications targeting applications with complex data aggregation. A set of design patterns is developed in [ 66 ] towards the self-adaptability for RTES.
The proposed patterns are described following the pattern template [ 14 ]. They used class diagrams to present the structural views of the patterns and sequence diagrams to explain the behavioral views. The authors combined the four patterns based on integration rules in order to form the design of the MAPE adaptation loop and enable its application. The RTE Monitor pattern allows continuous monitoring to reflect the current state of the system in order to detect trigger events and relevant changes.
It considers the system stability problem by minimizing the events triggered through the choice of the significant context variations.
It also deals with concurrency and real-time specifications associated with the control tasks. It handles concurrency and real-time specifications associated with the control tasks. It provides adaptation policies.
It also defines what elements to modify and how to meet constraints and requirements. The adaptation strategy can be based on changeable parameters or the modification of the structure of the RTE system. The RTE Actor pattern permits the final adaptation plan within a set of adaptation actions, which are related to the relative changeable element of a system. It specifies the effector responsible for an adaptation action. According to the previous study, research works based on design patterns are still limited in the WSN domains.
Most existing approaches focus on either sensor node components or network architecture. Few works dealt with reconfiguration scenarios. Nevertheless, the studied works do not cope with WSN requirements such as power consumption or real-time constraints. Moreover, they do not offer explicit support for architectural reconfiguration in WNS. They offer limited support for modeling of WSN systems and most research does not explore high-level modeling languages and specific standards.
In this paper, we presented a study about programming methodologies and modeling techniques for WSN development. We classified those works into two categories according to the abstraction level of their design. The first category concerned low-level techniques for WSN and particularly programming models. The second category dealt with high-level-based approaches including component-based modeling techniques and MDE-based approaches and particularly those that used UML and MARTE standards and pattern-based concepts.
Table 1 summarizes the previous sections by illustrating a comparison of the discussed related works. We conclude from our study that the development of WSN can be investigated at different abstraction levels. Various development techniques have been presented at low abstraction level to address either the node behavior or the network architecture [ 7 , 19 , 21 ]. These approaches have proven their effectiveness for developing WSNs; however, there is a lack of standard mechanisms that fit with WSN complexity.
Therefore, raising the abstraction level is a promising solution to handle the shortcomings of low-level-based approaches. In the same context, [ 51 ] defined new extensions to MARTE to support only solar energy harvesting modeling.
However, the majority of studies tackle only node-level-based reconfiguration [ 58 , 59 ]. They addressed hardware and software reconfiguration in a sensor node whereas network-level-based reconfiguration modeling is absent. According to our study, network-level-based reconfiguration and energy harvesting modeling are not well considered by model approaches based on the MARTE profile. We therefore need to add extensions to MARTE to allow a generic specification and modeling of energy harvesting modules.
Additionally, the automatic analysis of WSN regarding power efficiency and reconfiguration concerns is not well supported. Design patterns have been also investigated to cope with RTES complexity. They offer generic and reusable models that are used to solve a recurrent problem.
In addition, they facilitate the reuse of software models and improve the quality of software. We derived from our study that design patterns are still not well tackled. Most of existing works described either node components or network architecture [ 60 , 61 ].
Only one work [ 66 ] dealt with patterns devoted for adaptive systems. Yet no attention was given to real-time constraints in the development of WSN patterns. We can conclude from our study that existing approaches on model-based WSN design present shortcomings regarding energy and reconfiguration requirements.
In addition, there is still a lack of high-level modeling standards and reusable models that support the specification of requirements related to WSN development. In this regard, we plan, as a future work, to propose an MDE-based approach for developing an energy-aware reconfigurable WSN. A first study was devoted to the energy sources in WSN.
As we mentioned, existing studies lacks explicit support for power requirement modeling. Accordingly, high abstraction modeling of energy harvesting modules is absent.
In this context, we proposed well-structured support for energy harvesting specification based on the MARTE profile. We extended this profile with seven new energy harvesting devices including vibration, thermal, kinetic, acoustic noise, RF, biochemical, and hybrid energy harvesting types. A second study was devoted to the reconfiguration scenarios in WSN. Our study shows that existing works focus on low-level specifications.
They addressed the node-level-based reconfiguration scenario and dealt with hardware and software reconfiguration.
0コメント