Model Driven Development for Rapid Prototyping and ...

Model Driven Development for Rapid Prototyping and Optimization of Wireless Sensor Network Applications Ryo Shimizu

Kenji Tei

Waseda University, Tokyo, Japan

National Institute of Informatics, Tokyo, Japan

Waseda University, Tokyo, Japan

National Institute of Informatics/The University of Tokyo, Tokyo, Japan

[email protected] [email protected] Yoshiaki Fukazawa Shinichi Honiden [email protected]

[email protected]

ABSTRACT

Keywords

In order to develop Wireless Sensor Network (WSN) applications, it is necessary to develop prototypes in a low-cost way and to optimize application performance. Existing development approaches enable to develop a low-cost prototype by concealing the detail of WSN from the developers. However, there is a trade-off between the development cost of prototype and the description capability needed to optimize the application performance. We propose a Model-Driven Development (MDD) process to enable a low-cost prototyping and detailed optimization. To enable such a development process, we define modeling languages, which describe an application at three abstraction levels, and transformation rules, which transform models described by our modeling language to concrete one. Using our process, in prototyping, the developer describes a model by using the modeling language at the highest abstraction level and automatically obtains an executable model by using transformation rules. In addition, in optimizing, the developer can automatically obtain the models at more concrete abstraction level than the prototype by using transformation rules and modifies them in greater detail by using each modeling language.

Wireless Sensor Network, Model Driven Development, Modeling Language, Prototyping

1.

Categories and Subject Descriptors C.2.4 [Computer-Communication Networks]: Distributed Systems; D.2.m [Software Engineering]: Miscellaneous— Rapid Prototyping; D.3.2 [Programming Languages]: Language Classifications—Specialized Application Languages

General Terms Design, Language

Permission to make digital or hard copies of all or part of this work for Permission to make digital hard copies allprovided or part of workare for personal or classroom use is or granted withoutoffee thatthis copies personal or distributed classroom use is granted without fee providedand thatthat copies are not made or for profit or commercial advantage copies not made or distributed for profit or commercial advantage and that copies bear bearthis thisnotice noticeand andthe thefull fullcitation citationon onthe thefirst firstpage. page.To Tocopy copyotherwise, otherwise,toto republish, republish,totopost poston onservers serversorortotoredistribute redistributetotolists, lists,requires requiresprior priorspecific specific permission permissionand/or and/oraafee. fee. ICSE ’11, MayMay 21–28, 2011, Waikiki, Waikiki, Honolulu, Honolulu, HI, HI, USA USA SESENA’11, 22, 2011, Copyright2011 2011ACM ACM978-1-4503-0583-9/11/05 978-1-4503-0583-9/11/05...$10.00. ...$10.00 Copyright

31

INTRODUCTION

A WSN is a network consisting of small devices, called sensor nodes, with a wireless communication unit, CPU, RAM, multiple sensors, and a battery. They also have resource constraints, e.g. energy and reliability. Due to these constraints, WSN application developers have to optimize performances, e.g. the energy consumption and communication reliability. The performance of WSN applications heavily depends on the execution environment[13]. To optimize performance, application is needed to be executed on the environment at early stage of development. In this way, WSN application development must be able to (i) develop the prototype in a low-cost way and (ii) modify the prototype in order to optimize the performance. However, existing approaches cannot satisfy both (i) and (ii) at the same time. For the satisfaction of requirement (i), many domain specific languages and frameworks have been proposed, such as NesC[3], Abstract Regions[16], and TinyDB[8]. These languages conceal details of WSN from developers, and enables a developer to describe model of application at abstract level. The model is executed upon framework which maps the abstract model to concrete behavior of each sensor node. The degree of cost reduction depends on the degree of abstraction. For example, NesC conceals details of hardware from the developer. The developer describes behavior of a node by using hardware-independent APIs instead of hardware-native APIs. In addition, Abstract Regions conceals details of behavior of each node. The developer describes macro-behavior of a node group, instead of behavior of each nodes. Thus, Abstract Regions is at higher abstraction level than NesC. Furthermore, TinyDB conceals the macro-behavior of a node group. The developer describes data processing, that is, data flow with data yielding, processing, and sink points, instead of macro-behavior of node group to achieve such a data flow in a WSN. Therefore, TinyDB is at the highest abstraction level of the three. In addition, for the satisfaction of requirement (ii), developers need to carefully select appropriate choices about the details of WSN, for its execution environment. There

are many choices for each abstraction level. For example, at the macro-behavior level, developers can select topology of nodes (cluster, tree, mesh, and so on), and node selection methods (k-hop neighbors, geographic-based, and so on). Many of existing choices are optimized for specific class of execution environment. For example, in an environment where people can easily maintain the nodes, the developer should choose a routing protocol that realizes reliable communications but consumes a lot of energy[6]. In the opposite kind of environment, a developer has to choose a protocol that reduces the energy consumption, but also decreases the communication reliability[4]. For another example, in an environment where the node density is high, in order to conserve resources, a developer should use a node selection that selects fewer nodes. Otherwise the developer uses a task allocation method that uses more nodes to maintain the data accuracy. However, there are tradeoff between the degree of description capability and the degree of optimization. For example, from the viewpoint of the requirement (i), TinyDB is the best among the three. However, TinyDB conceals the details of macro-behavior in the WSN, the developer cannot select choices about network-related issues, such as routing protocol, network topology, node selection, and so on. From the view point of the requirement (ii), the TinyDB is the worst among the three. For these reasons, existing approaches cannot satisfy both requirements (i) and (ii). This is because developer has to describe model at one abstraction level. In this paper, we focus on the three aforementioned abstraction levels and propose a development process that satisfies the requirement (i) and (ii) at the same time. We adopt the MDD concept to design our development process. In MDD, the developer describes an abstract model using a Domain Specific Modeling Language (DSML), and the abstract model is transformed into a concrete model by using the model transformation rule through single or multiple steps, and then the developer obtains an executable[9]. We define three DSMLs in order to describe the models at each different abstraction level and transformation rules in order to convert a high abstract model to a low abstract one. With our MDD process, in a prototyping phase, the developer only needs to describe a model by using a DSML at the highest degree of abstraction. Executable models can be obtained by transforming the model by using transformation rules. In addition, in the optimization phase, the developer can modify models to select appropriate design choices, by using DSMLs at an appropriate abstraction level. The described model is automatically transformed into more concrete models and an executable model according to transformation rules. The rest of this paper is organized as follows. Section 2 discusses the related work tackling the low-cost WSN application development and their problems. Section 3 explains our proposed development process, DSMLs, and transformation rules. In Section 4, the results from an evaluation of our method are presented with a case study from a fire detection application. Section 5 concludes this paper and present opportunities for future work.

Table 1: A classification of programming models[11]. Abstraction level Node-level Group-level Network-level

Example methods NesC, etc... Abstract Regions, etc... TinyDB, etc...

have taken an abstraction approach that conceals the details of WSN from the developers and reduces the number of elements the developers need to describe. With these approaches, the elements that the developer cannot describe are fixed by the OS or middleware. In a survey of the area, Sugihara and Gupta[11] classified them into three groups based on what they conceal from the developers. Table 1 lists this classification. The network-, group-, and nodelevel, respectively, represent the class of frameworks that the developers describe the data processing, the macro-behavior, and the behavior of each node. The models at the node-level are focused on hardware abstraction and described about the behavior of each node for a single node. The models at the group-level are focus on communication abstraction and described about the macro-behavior for a group of nodes. The models at the network-level are focused on network abstraction and described about data processing as for whole network. The approaches in Table 1 have a trade-off between the ease of description and the difficulty in optimization, because less describable elements mean less tunable elements. Furthermore, there are studies that have used the concept of MDD to reduce the cost of WSN application development. Using these approaches the developer can describe an abstract model, such as application logic. In addition, the cost of prototyping is reduced because the developers can automatically obtain an executable model from the model by transformation. In [12] and [15] the authors propose a MDD process for the WSN platform called BiSNET[2], in which an application is described as an agent. These MDD processes enable description of the agent’s task as a model. In addition, there are many approaches using MDD[1][7][10]. However, in all these MDD approaches, they assume that the developers use merely one abstract model. Thus, these approaches cannot dissolve the trade-off between the cost of prototyping and the ability to optimize the performance. In this paper, we suggest a development process that uses multilevel abstract models to overcome this trade-off. For performance optimization, it is useful to be able to grasp the performance in the execution environment. There are some studies that measure the application performance, such as MOTE-VIEW[14]. MOTE-VIEW is a visualization tool for monitoring and analyzing the measurement data of the nodes, and checking the state of each node. For example, this tool can check values such as an estimated battery charge, estimation of the link quality, the throughput, etc. Performance measurement tools help developers to decide what modifications are needed for the optimization by analyzing the application performance. Therefore, it is effective to combine these tools with our development process.

3.

2. RELATED WORK Generally, WSN application development is a challenging task, and there is a large amount of existing work in the area. As for low-cost prototype development, many studies

DEVELOPMENT PROCESS FOR RAPID PROTOTYPING AND OPTIMIZATION

In this section, we explain our development process that enables low-cost prototyping and detailed optimization. At first, we describe the overview of the proposed process. Next,

32

Prototyping Phase

Optimizing Phase Execute, Performance Monitor

requirement

Network‐level Model Group‐level Model Node‐level Model : automatic : manual

Analyze, Decide modifying element

Network‐level Model*

Group‐level Model*

Executable Model

Node‐level Model* Executable Model*

Figure 2: Definition of Network-level DSML.

Figure 1: Proposed development process for prototyping and performance optimization.

nections between groups, modify communication links between nodes, or change the task assignment. Finally, to reflect the geographical task allocation, the developer needs to change the attribute, the connection between groups, the communication links between nodes or the task assignment. These decisions on what changes to make and the modification of the models in the optimization phase are tasks to be carried out manually. The modified model is again automatically transformed into executable model, and executed in the given environment, and the adequacy of the performance optimization is confirmed. The developer can optimize the application performance by repeating the following process: transforming the models, executing the prototype, measuring and analyzing the performance, and modifying the models. Our process enables the developer to model data flow in a flexible, purely descriptive way, and to describe not only the data flow but also the macro-behavior and the behavior of each node in optimizing performance. Even though steps such as describing the network-level model in the prototyping phase, measuring and analyzing performance, and modifying the models in the optimization phase are manual tasks, transformations from abstract to concrete models are automatic.

we define the DSMLs at three abstraction levels. Finally, we explain the transformation rules between the models described by the DSMLs we defined. In Section 3.2 and 3.3, we explain definitions of DSMLs and rules, although not completely, due to limitations of space.

3.1 Development Process Design Figure 1 shows an overview of the proposed development process. We adopt to use three DSMLs based on Table 1 because both the classification of Table 1 and the reason why the trade-off mentioned in Chapter 2 is based on the idea what element is abstracted. Each level in Table 1 has each aspect, therefore the transformation from higher level to lower level is a refinement, not just adding information. In our process, the developer creates a prototype using the following steps. At first, the developer describes the data processing to satisfy requirement (i) by using the networklevel DSML. The transformation rules transform the described model into a group-level model and then a node-level model automatically and step-by-step. In transforming the network-level model into a group-level and the group-level model into node-level, the new elements, which appear in more concrete models, are given default fixed values by our transformation rules. Then, the developer can create an executable model from the node-level model. By using this process, the developer can create a prototype for performance measurement in the early stages of the development process by describing only the data flow aspect. Afterward, the developer uses the prototype in an execution environment and measures its performance using a monitoring tool. The developer decides on a performance optimization objective for the execution environment based on the performance measurement. Specifically, the developer makes a decision on the timing for data yielding and transmitting, the routing protocol, the network topology, the in-network processing, and the geographical allocation of tasks. Based on this decision, the developer modifies the models at the corresponding level. Table 2 summarizes the ways that developers can modify properties that affect performance including the modifiable item, changeable level, and change method. When “change method” is “change attribute”, the value that the developer can describe is also suggested. To reflect the data yielding or data transmitting timing, attribute changes in the models at each level are needed. To reflect the routing protocol in the node-level and network topology in the group-level, developers may change attributes in the models. To reflect in-network processing characteristics, the developer needs to modify con-

3.2 Domain Specific Modeling Language Design Figure 2 shows the definition of a network-level DSML. The network-level model is independent of the network and describes the data flow needed to meet the requirements. The data yielding point, data processing point and data sink are needed to express the data flow. The data yielding point needs a data type to sense, and the sampling and transmitting condition (duration or trigger event). The data processing point has two processing types: aggregation dealing with a single data type and fusion dealing with multiple data types into a single data type. They need attributes for the operation and data type dealing with. The data flow is expressed by using the connection between the SourceNodes,AggregationPoint, FusionPoint, and Sink. Figure 3 shows the definition of group-level DSML. The group-level model is dependent on the network and describable about handling a group of nodes as a single entity. Group here means a set of nodes that are geographically near each other and that have the same task. Group includes the data yielding group, the data fusion group and the data sink. The data yielding group needs information on the data sampling and data aggregation. The data fusion group needs information on the data fusion such as the function. In addition, each group needs information on the

33

Table 2: Modifiable items in our development process. Modifiable item

Routing protocol Network topology In-network processing

Changeable level Network-level, Group-level, Node-level Network-level, Group-level, Node-level Node-level Group-level Group-level, Node-level

Task’s geographical location

Group-level, Node-level

Data yielding condition Data transmitting condition

Change method (and describable value) Change attribute: samplingCond (N sec, reading > threshold) Change attribute: transCond (N sec, reading > threshold) Change Change Change Change Change

3.3

SourceNodes 0..*

0..*

1

- dataType : String - samplingCond : String - transCond : String

InputGroup 1..*

AggregationPoint

1

Group 0..1

- topology : String - locationCond : String

FusionPoint - function : String - inputDataType : String - outputDataType : String

1

FusionOutputGroup

Transformation Rule Design

The transformation rules are necessary to ensure there is a transformation between the models described by the defined DSMLs. Therefore we define these transformation rules. By using these rules, the group-level and node-level models are automatically generated from the network-level model. Thus, automatic transformation rules can help to generate executable model from the network-level model and provide other abstract views for optimizing the performance in detail. A brief example applying transformation rules is described in Section 4.

Sink

- function : String - inputDataType : String

attribute: protocol (collection, dissemination) attribute: topology (tree, mesh) link between groups, task allocation for node attribute: locationCond (all node, N hop) link between groups, task allocation for nodes

0..*

0..1

3.3.1

Figure 3: Definition of Group-level DSML.

Transformation Rule from Network-level to Group-level

The transformation rule maps the elements that are common in the network-level and group-level models and gives a fixed default value to the elements that newly appear in the group-level model. The common elements refer to the descriptions of the data flow decided in the network-level: dataType, samplingCond and transCond that the SourceNodes have, function, inputDataType, and outputDataType that the AggregationPoint or FusionPoint have. The newly appearing elements in the group-level are the descriptions related to inside of network; locationCond and topology. The locationCond, which are the conditions for constructing a group, is given the value all_node in order to use all the nodes to assign a task as a default value based on the rule. The topology is given the value tree that uses the tree topology as a default based on the transformation rule. By using these default values, the developer does not have to decide on the parameters of the transformation and can automatically receive a lower model.

Figure 4: Definition of Node-level DSML.

geographical conditions for constructing a group and the network topology for the group. The data flow is also expressed by the connection of Group and Sink. Finally, Figure 4 shows the definition of the node-level DSML. The node-level model is dependent on the network and describable about the behavior of each node. In addition, the node-level model expresses the task assignment for each node and the communication link between nodes. Each node can be expressed as set of tasks. To express this, a node that contains a set of tasks and location information, and the tasks themselves, which each has role such as data yielding or data processing, are needed. Tasks concerning data sensing, data aggregation, data fusion, and the sink are needed because upper level models perform these roles. In addition, tasks concerning communication are needed. We express this as a SendingTask and a ReceivingTask. These tasks need information on the routing protocol and dealing data type. The set of connections between the SendingTask and ReceivingTask also expresses the data flow.

3.3.2

Transformation Rule from Group-level to Node-level

Like the transformation rule from the network-level to the group-level, this transformation rule also maps the common elements and presents the default value to the new element in node-level. The common elements are the descriptions of the data flow decided upon in the network-level and the conditions for constructing a group that were decided in the group-level. They are mapped one to one because the same value is used in both models: the SourceNodes, AggregationPoint, FusionPoint and locationCond in a Group respectively maps the SensingTask, AggregationTask, FusionTask and locationCond in a Node. In addition, the protocol value, which is the new element in the node-level, is given based on the group-level topology. Tree and mesh, which are topology value, respectively map the collection and dissemination values of the protocol. Nodes are generated from a Group one-by-one and the connections be-

34

Table 3: Comparison of prototyping cost

Network-level Group-level Node-level Our Method

Table 4: Comparison of description capability

Describing items when prototyping Behavior of Data Flow Macro-Behavior Each Node ✓ ✓ ✓ ✓ ✓ ✓ ✓ -

Changeable items when optimizing Behavior of Macro-Behavior Each Node ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

Data Flow Network-level Group-level Node-level Our Method

tween the groups are reflected into the communication link between the nodes, and the link between the SendingTask and ReceivingTask.

if it seems that the communication reliability is low, the developer will modify the value of the protocol from the collection representing the Collection Tree Protocol, to dissemination representing the Dissemination Protocol, in node-level model. This modification is expected to lead to a higher reliability. Table 4 presents a comparison of the descriptive elements in the optimization phase. In this table, the more checkmarks there are, the more flexible the performance optimization is. Therefore, our process enables to optimize the performance in equivalent or more detail than the existing studies because our process enables the developer to optimize the performance of the macro-behavior and behavior of each node.

4. EVALUATION In this section, we demonstrate how to apply our development process by giving a brief example of the development of a fire detection application. The example application senses the temperature and location information, sends each data to the sink node when the sensing temperature is greater than the threshold. In transmitting, the location information is averaged to regard the average location of the nodes detecting higher temperature as the origin of the fire. In addition, we discuss the limitations of our process.

4.3

4.1 Case Study: Prototyping Phase

Limitations

There are some limitations in our method. This work is our first step, the proposed DSMLs can describe very simple sensing application. For example, our DSMLs have the capability to describe static applications, meanwhile not to describe mobility and adaptive behavior. However, now we can easily map the models described by our DSMLs to executable model because of the simplicity of DSMLs. As Table 2 shows, the proposed DSMLs allow for modifying the performances for data yielding and transmitting timing in each level, the conditions for group construction, the network topology, the connection between groups in the group-level, the routing protocol and the communications link between the nodes in the node-level. From a developer’s point of view, it is necessary to use three kinds of DSMLs in our process; thus it is probable that the learning cost of ours is higher than that of the existing methods providing one abstract model. In addition, there is a difficulty keeping the consistency between models. One reason is that the consistency between models is lost if the element appearing in all levels, such as dataType is changed at only one level. Another reason is that the data flow decided in the network-level can be broken by the manual and arbitrary modification of the model. However, these disadvantages can be improved by doing the following: For the learning cost, a modeling tool helps to describe the models. For the loss of consistency, bidirectional transformation that automatically reflects changes in one model into the other model and validation system that extract and compare the data flows would help to maintain the consistency between models. Our approach has intrinsic limitations, but through the use of the abovementioned techniques our development process becomes efficient in achieving a low-cost prototyping and performance optimization in more detail.

At first, the developer describes a model in the networklevel DSML. The left part of Figure 5 shows the model described in the network-level DSML. This model expresses that the fire detection application consists of two kinds of sampling processing: one is to sense the temperature data every 5 sec and transmit it if the temperature is greater than 40 degrees Celsius, and the other is to sense the location information every 5 sec and transmit it if the temperature is greater than 40 degrees Celsius along with the average location information. This model is transformed into the group-level model, as shown in the center part of Figure 5, and then into the node-level model, as shown in the right part of Figure 5 by automatically using a stepwise transformation. In addition, Figure 5 shows that the elements in color box are mapped from the elements in the same color box in the model at the upper level. Finally, an executable model is generated from the node-level model. Therefore, the developer can create a prototype by merely describing the data flow. Table 3 presents a comparison of the descriptive elements in the prototyping phase. A checkmark means that each approach represents whether or not such descriptions are needed and the less checkmarks there are, the lower the cost of prototyping is. In this way, our process enables to create a prototype at an equivalent or lower cost than the existing studies describing the macro-behavior or the behavior of each node because our process needs only to describe the data flow.

4.2 Case Study: Optimization Phase Next, the developer executes the prototype and measures its performance. If it seems that the energy consumption is too great, it is assumed that the developer will modify the locationCond value from all_node to 3hop, which means the group is constructed using the nodes within three hops, in the group-level model. This modification is expected to lead to a reduction in energy consumption by reducing the number of nodes assigned to tasks. Otherwise,

5.

CONCLUSION AND FUTURE WORK

In this paper, we suggest a development process to create a low-cost prototype that does not reduce the tunable

35

Figure 5: Example models of fire detection application described by defined DSMLs. elements for optimization. We define three levels of DSMLs and the transformation rules between the models. A prototype is generated by using the most abstract DSML and an automatic transformation process. A detailed performance optimization is achieved by using more concrete DSMLs. This work proposes a development process, but does not evaluate it empirically. In the future, we need to develop a tool in order to realistically test the proposed method. We are currently developing the tool with transformation engine, GRoundTram system[5] supporting systematic development of bidirectional model transformation. For this tool, we need to define the platform specific model (PSM), the transformation rules from the node-level model to the PSM and code generator. We also need to develop real applications and evaluate our method using this tool. In addition, we will tackle some of the problems mentioned in Section 4.2. We are trying to maintain the consistency between models using the GRoundTram system. In addition, for the problem of a break in the data flow, we are developing a validation system to extract it from the models and to check for any invariance.

[7]

[8]

[9]

[10]

[11]

6. REFERENCES

[12]

[1] K. Beckmann, M. Thoss. A model-driven software development approach using omg dds for wireless sensor networks. SEUS’10 Proc. of the 8th IFIP WG 10.2 international conference on Software technologies for embedded and ubiquitous systems, 2010. [2] P. Boonma, J. Suzuki. Bisnet: A biologically-inspired middleware architecture for self-managing wireless sensor networks. Computer Networks: The International Journal of Computer and Telecommunications Networking, vol. 51, 2007. [3] D. Gay et al. The nesc language: A holistic approach to networked embedded systems. PLDI’03 Proc. of the ACM SIGPLAN 2003 conference on Programming language design and implementation, 2003. [4] O. Gnawali et al. Collection tree protocol. SenSys ’09 Proc. of the 7th ACM Conference on Embedded Networked Sensor Systems, 2009. [5] S. Hidaka et al. Bidirectionalizing graph transformations. ICFP ’10 Proc. of the 15th ACM SIGPLAN international conference on Functional programming, 2010. [6] K. Lin, P. Levis. Data discovery and dissemination with dip. IPSN ’08 Proc. of the 7th international

[13]

[14]

[15]

[16]

36

conference on Information processing in sensor networks, 2008. F. Losilla et al. Wireless sensor network application development: An architecture-centric mde approach. Software Architecture First European Conference, ECSA 2007, 2007. S. R. Madden et al. Tinydb: an acquisitional query processing system for sensor networks. ACM Transactions on Database Systems (TODS), vol. 30, 2005. D. C. Schmidt. Guest editor’s introduction: Model-driven engineering. IEEE Computer, vol. 39(no. 2), 2006. S. Schuster, U. Brinkschulte. Model-driven development of ubiquitous applications for sensor-actuator-networks with abstract state machine. SEUS’07 Proc. of the 5th IFIP WG 10.2 international conference on Software technologies for embedded and ubiquitous systems, 2007. R. Sugihara, R. K. Gupta. Programming models for sensor networks: A survey. ACM Transactions on Sensor Networks (TOSN), vol.4, 2008. N. X. Thang, K. Geihs. Model-driven development with optimization of non-functional constraints in sensor network. SESENA’10 Proc. of the 2010 ICSE Workshop on Software Engineering for Sensor Network Applications, 2010. S. Tilak, N. B. Abu-Ghazaleh, W. Heinzelman. Infrastructure tradeoffs for sensor networks. WSNA ’02 Proc. of the 1st ACM international workshop on Wireless sensor networks and applications, 2002. M. Turon. Mote-view: a sensor network monitoring and management tool. EmNet ’05 Proc. of the 2nd IEEE workshop on Embedded Networked Sensors, 2005. H. Wada et al. Modeling and executing adaptive sensor network applications with the matilda uml virtual machine. SEA’07 Proc. of the 11th IASTED International Conference on Software Engineering and Applications, 2007. M. Welsh, G. Mainland. Programming sensor networks using abstract regions. NSDI’04 Proc. of the 1st conference on Symposium on Networked Systems Design and Implementation, 2004.