Moppet: A Model-Driven Performance Engineering Framework for Wireless Sensor Networks Pruet Boonma∗ and Junichi Suzuki∗∗ ∗ Department
of Computer Engineering Chiang Mai University Chiang Mai 50200, Thailand ∗∗ Department of Computer Science University of Massachusetts, Boston Boston, MA 02125, USA Email:
[email protected] and
[email protected] This paper describes a model-driven performance engineering framework for applications embedded in individual nodes of wireless sensor networks (WSNs). The framework, called Moppet, is designed for developers, even non-programmers, to rapidly implement WSN applications, estimate their performance and feedback the estimated performance results for customizing their design/implementation. By leveraging the notion of feature modeling, Moppet allows developers to graphically and intuitively specify features (e.g., functionalities and configuration policies) required in their applications. It also validates a set of constraints among features and generates lightweight application code. Moreover, with event calculus and network calculus, Moppet estimates a WSN application’s performance without generating its code nor running it on simulators and real networks. It can approximate data yield, data transmission latency and network lifetime as well as each node’s power and bandwidth consumption. Evaluation results show that, in a large-scale WSN of 400 nodes, Moppet’s performance estimation is 46% more efficient than empirical performance measurement and its estimation error is lower than 10%. Moppet scales well to network size with respect to estimation efficiency and accuracy.
1.
INTRODUCTION
As wireless sensor networks (WSNs) have been growing in their scale and complexity, it is complicated, error-prone and time-consuming to rapidly design, implement and tune WSN applications. Application design, implementation and performance tuning can be expensive even for simple applications. This stems from two major issues. The first issue is a lack of adequate abstractions in application design, implementation and performance tuning. The level of abstraction remains very low in WSN application development. For example, a number of WSN applications are currently implemented in nesC, a dialect of the C language, and deployed on the TinyOS operating system, which provides low-level libraries for fundamental functionalities such as node-to-node communication and signal strength sensing. nesC and TinyOS abstract away hardware-level details; however, they do not aid developers to rapidly implement and tune their applications. The second issue is a lack of sufficient integration between application design/implementation and performance tuning. Performance tuning is a process to examine an application’s performance through simulations and/or empirical experiments and customize its design/implementation against given performance requirements such as data yield, resource consumption and network lifetime. This process The Computer Journal,
is often labor-intensive because most WSN applications are performance/resource sensitive. Few methods and tools exist to seamlessly integrate application design/implementation and performance tuning in order to feedback estimated/measured performance results for customizing application design and implementation. In order to address these two issues, this paper investigates a new model-driven performance engineering framework for WSN applications. The proposed framework, called Moppet, is intended to improve the productivity of implementing WSN applications and engineering their performance. Moppet consists of two components: feature modeler and performance estimator (Figure 1). The Moppet feature modeler is a graphical modeling environment to configure WSN applications. It leverages the notion of feature modeling [1], which is a simple yet powerful method to graphically model an application’s features (e.g., functionalities and configuration policies) and constraints among them. Feature modeler aids developers, even non-programmers, to specify each application as a set of features and consistently validate constraints among those features. Upon validation, the Moppet feature modeler transforms specified features to application code (nesC code and deployment descriptions). The Moppet performance estimator is designed to Vol. ??,
No. ??,
????
2
P. Boonma and J. Suzuki
approximate a WSN application’s performance without generating its code nor running it on simulators and real networks. It leverages event calculus [2, 3] and network calculus [4] to approximate data yield, data transmission latency and network lifetime as well as each node’s power and bandwidth consumption. Event calculus is a first-order logical language to represent and reason about events (or actions) and their effects. For example, it can perform deductive inference, which infers what is true when, given a set of events at certain time points (i.e., what events occur when) and their effects (i.e., what events do) [3]. By considering individual functionalities performed in each duty cycle on each node as events and describing the power consumption of those functionalities as the effects of events, the Moppet performance estimator infers when each node runs out of its battery (i.e., what is true when). Network calculus reasons about a traffic flow in each network link by representing the link as a queuing model and observing packet arrivals/departures on that link. By integrating event calculus and network calculus, the Moppet performance estimator infers data yield, data transmission latency, network lifetime as well as each node’s bandwidth consumption. It is intended to simplify the trial-and-error process for evaluating a WSN application’s performance and customizing its features to satisfy performance requirements (Figure 1). This paper describes the designs of Moppet’s feature modeler and performance estimator, and evaluates them through simulations and empirical experiments. Evaluation results show that, in a large-scale WSN of 400 nodes, Moppet’s performance estimation is 46% more efficient than empirical performance measurement and its estimation error is lower than 10%. Moppet scales well to network size with respect to estimation efficiency and accuracy. Moppet generates lightweight code that can be deployed on resourcelimited nodes. !"#$%&"'()*"+"&'
(7,,18'
4)*"' !"#$%&'()*+,( !"#$%&'(+*+,( 9"/")/' !"#$%&'(*%-."/( 123.#$"*' ,"&-)&.#/0"'
!"#$%&"'' 4)/56%)/'
,"&-)&.#/0"'' 123.#$)&'
("#2%&"*' ,"&-)&.#/0"'
2.
BACKGROUND
Moppet generates application code that runs on the TinyDDS middleware (Figure 1). TinyDDS is a lightweight implementation of the Data Distribution Service (DSS) specification, which Object Management Group (OMG) standardizes for publish/subscribe middleware [5]1 . DDS provides standard middleware interfaces for event subscription and publication in the OMG Interface Definition Language (IDL). TinyDDS implements them with nesC. See [6] for the IDL-to-nesC mapping in TinyDDS. Besides DDS interfaces, the DDS specification standardizes no specific algorithms or protocols for event subscription and publication; they are left to DDS implementations. Thus, TinyDDS implements its own event subscriptions and publication protocols [7], and uses a subset of the OMG General Inter-ORB Protocol (GIOP) [8] to transmit data through DDS interfaces. TinyDDS also assumes B-MAC in TinyOS for media access control. See [7] for implementation details of TinyDDS. The current codebase of TinyDDS contains 2,035 lines of nesC code. Moppet is designed generic enough to support various types of applications. However, it currently targets coastal oil spill detection and monitoring as its application domain. Oil spills occur frequently2 and have enormous impacts on maritime and on-land businesses, nearby residents and the environment. Oil spills can occur due to, for example, broken equipment of a vessel and coastal oil station, illegal dumping or terrorism. Spilled oil may spread, change the direction of movement, and split into multiple chunks. Some chunks may burn, and others may evaporate and generate toxic fumes. In order to detect and monitor oil spills at realtime, this paper assumes an in-situ WSN consisting of batteryoperated sensor nodes and several base stations. Each node is equipped with several sensors such as fluorometers3 , light scattering sensors4 , surface roughness sensors5 salinity sensors6 and water temperature sensors7 . Each node is packaged in a sealed waterproof container, and attached to a fixed buoy. With this in-situ WSN, oil spill detection and monitoring applications are expected to provide real-time sensor data to human operators so that they can efficiently dispatch first responders to contain spilled oil in the right place at the 1 TinyDDS
is freely available at http://dssg.cs.umb.edu. U.S. Coast Guard reports that 200 oil and chemical spills occurred in the U.S. shores in 2006 [9], and the Associated Press reported that, on average, there was an oil spill caused by the US Navy every two days from the fiscal year of 1990 to 1997 [10]. 3 Fluorescence is a strong indication of the presence of dissolved and/or emulsified polycyclic aromatic hydrocarbons of oils. Aromatic compounds absorb ultraviolet light, become electronically excited and fluoresce [11]. Different types of oil yield different fluorescent intensities [12]. 4 High intensity of light that is scattered by water indicates high concentration of emulsified oil droplets in the water [13, 14]. 5 Oil films locally damp sea surface roughness and give dark signatures, so-called slicks [11]. 6 Water salinity influences whether oil floats or sinks. Oil floats more readily in salt water. It also affects the effectiveness of dispersants [15]. 7 Water temperature impacts how fast oil spreads; faster in warmer water than cold water [15]. 2 The
Generated Application TinyDDS Middleware TinyOS
FIGURE 1. An Overview of Moppet
The Computer Journal,
Vol. ??,
No. ??,
????
Moppet: A Model-Driven Performance Engineering Framework for Wireless Sensor Networks
3
right time and avoid secondary disasters by directing nearby ships away from spilled oil, alerting nearby facilities or evacuating people from nearby beaches [11, 12, 16]. In-situ WSN applications can deliver more accurate information (sensor data) to operators than visual observation from the air or coast. Moreover, they are more operational and less expensive than radar observation with aircrafts or satellites [16]. In-situ WSNs can operate during nighttime and poor weather, which degrade the quality of airborne and satellite observation. Sensor Node Generated Applications
Base Station Sensor Node
TinyDDS DDS Interface
APIs Feature Plug-ins
Data Aggregation
OERP Layer
DHTBased
L3 Layer
AODV
Localization
Spanning -Tree DODV
Epidemic Spreading
OneHop
… … …
FIGURE 4. An Example Feature Configuration
TinyOS Sensor Reading Comm. Control
Sensors
Comm. Hardware
Sensor Device
Sensor Network
FIGURE 2. The Architecture of TinyDDS Middleware
3.
FEATURE MODELING IN MOPPET
A feature model describes a set of all possible valid configurations as hierarchies of feature that describe different kinds of constraints, e.g., some feature are mandatory and some are alternative or optional [1]. It gives a clear view of features that a system can support and their constraints even to non-programmers. It is useful for scoping a WSN application, i.e., deciding which features should be deployed in the application and which feature should not. Thus, the requirements are much clear in the early stage of the development process (e.g., requirement phase). By reducing the possibility of changes in requirements in the late stage of the development process, feature model gives a positive impact on application developments since the changes in requirements in the late stage can cause a huge number of modifications in existing (already implemented) application designs and code. Beside, feature model can has constraints among features. These constraints assures the developers that the feature configuration is always legit. Moreover, application developers can use feature configurations as input to a code generation and also performance engineering to improve the productivity of the application development. Figure 3 shows the proposed feature model for WSMs based on an open source pub/sub middleware called TinyDDS8 . Figure 4 is an example feature configuration (i.e., an instance of the proposed feature model). 8 http://dssg.cs.umb.edu
The Computer Journal,
In Figure 3, white circle symbols represent optional features, black circle symbols represent mandatory features, and half-filled circle symbols represent features with predefined value. A feature can have multiple subfeatures. For example, Data Aggregation, which allows the middleware to aggregate incoming data, has two subfeatures: Data Aggregation Operator and Data Aggregation Probability. Each feature may have its type. For example, the type of Event Probability is Float. When a typed feature is selected in a feature configuration, its value should be specified. A fork symbol with a black sector in a feature model represents an or relationship among subfeatures. Application has two subfeatures, Data collection and Event Detection which are represents the generic application of WSNs, and one or two of them should be selected. In the other words, the subfeatures has an or relationship among them. On the other hand, a fork symbol with a white sector, e.g., subfeature of Localization, represents exclusive-or relationship among subfeature, i.e., only one subfeature of Localization can be selected at a time. Likewise, this can be seen as an exclusive-or relationship among subfeatures. The dotted line represents another type of constraints between features. The dotted line with label “requires” dictates that the feature at the beginning of the dotted line depends on the feature at the end of the dotted line. Thus, if the feature at the beginning of the dotted line is selected, the one at the dotted line will be selected automatically. For the dotted line with label “after” dictates that the code generated for the feature at the beginning should be placed after the code generated from the feature at the end of this line. In the other words, this relationship describes the sequence of action should be performed by code generated from a feature configuration. The proposed feature model is divided into three sections, namely, application-related, network-related and hardwareVol. ??,
No. ??,
????
4
P. Boonma and J. Suzuki
FIGURE 3. The Proposed Feature Model
related features. The application-related features comprise of features related to application functionalities such as the type of the application or persistence storage to be used to store collected data. The network-related features can be used to customize the network stack of the applications, e.g., the routing protocol to be used. Lastly, the hardware-related features are associated to the sensor node hardware, e.g., the sensor node hardware platform that this application is going to operate on. 3.1.
Application-Related Features
In application-related feature section, Application is a mandatory feature which specifies the application type, i.e., Data Collection or Event Detection applications, to be deployed. Generally speaking, data collection and event detection represents the common usages of WSNs. Thus, developers can simply select applications to be deployed, either data collection or event detection or both, according to their requirement. When Event Detection is selected, an event criteria needs to be specify using Event Filter feature. For example, to detect oil spilled, the Event Filter might be ROUGHNESS > 0.5 where ROUGHNESS is the reading from surface roughness sensor deployed on the sensor nodes. On the other hand, Event Probability and Event Probability Distribution governs the chance that the event can occurs. This features are not used by code generator but by the estimator (see Section 4.3). Localization is an optional features which contains two subfeatures: Network-Based and GPS-Based. With network-based localization, the location of sensor nodes are determined by triangulation using radio signal strength (RSS) between nodes. On the other hand, GPS-Based localization used an external GPS device to determine the location of sensor nodes. Thus, GPS-Based The Computer Journal,
feature requires or depends on GPS feature, which represent the external GPS device attached to sensor node. Moreover, Localization has after relationship with Application, hence, this feature model suggests that the application, i.e., data collection or event detection, need to be performed after the localization is done. Data/Event Archive and Persistence Storage are optional features used for configuring in-node data storage. If Data/Event Archive is enabled, sensor node kepdf history data for a specific number of data or with a specific time period. This data/event archive requires Persistence Storage feature for collecting data, which can be internal storage, i.e., Memory, or external storage, i.e., Flash memory attached to sensor nodes. Data Aggregation is an optional feature dictates whether sensor node should aggregate data when it received multiple data at a similar time. The data aggregation operator is a subfeature which specify the operator, e.g., SUM or AVERAGE, to be used when aggregating data. The Data Aggregation Probability and Data Aggregation Probability Distribution governs the chance that the data aggregation can occurs. These features are not used by code generator but by the estimator (see Section 4.3). Concurrency specifies the parallelism of the middleware that the application is running on, i.e., TinyDDS. TinyDDS has three concurrency models: a thread per incoming/outgoing event, a thread per event topic and a single thread for all event/topic which specified by Per-Event, Per-Topic and Single Threaded feature respectively. 3.2.
Network-Related Features
OERP, L3 and QoS Policy are network-related features. OERP, i.e., Overlay Event Routing Protocol, is the overlay Vol. ??,
No. ??,
????
Moppet: A Model-Driven Performance Engineering Framework for Wireless Sensor Networks routing protocol used for delivering event among nodes. Currently, TinyDDS supports three overlay routing protocol, namely, Spanning Tree, Distributed Hash Table(DHT), and Epidemic Spreading algorithm. Depending on the selected overlay routing protocol, network routing protocol (L3) will be selected accordingly. TinyDDS supports both single-hop routing protocol or multi-hop routing protocol such as AODV or DSDV. QoS Policy specifies the network-related QoS parameters such as the number of retransmission or the number of packet duplication. These parameters can be configured to archive various network objective such as transmission success rate or latency. For example, increasing the number of retransmission or packet duplication might increase the success rate.
3.3.
Hardware-Related Features
In hardware-related features, Duty Cycle and Node Location are mandatory features which specify the duty cycle period of sensor nodes and the topological location of sensor node, respectively. The duty cycle controls how frequent the data collection or event detection is performed. The topological location of sensor nodes, in term of hop count, describes how many hop from the particular node to the base station. Hardware-Profile is a collection of the feature sets for each hardware platforms that are supported by TinyDDS. Current, TinyDDS supports TinyOS-based hardware platform. The example of TinyOS-based hardware platform are such as Crossbow’s MicaZ and iMote2. For each hardware platform, the default value of Battery Capacity, Flash Memory and Max Bandwidth are assigned using data from specification of each hardware platform. The GPS feature is optional and required GPS daughter board to be attached to the sensor node. Finally, there is a Tailored-Made hardware platform which developer can assign parameter for each feature as they like, i.e., to be used by sensor node developed from scratch. Figure 4 shows a sample feature configuration in the Eclipse’s fmp tool9 of the feature model in Figure 3. In this feature configuration, several features (e.g., Data Collection subfeature and DataAggregation feature) are selected. A supporting tool resolves the constraint between (sub)features (e.g., GPS subfeature is selected when GPS-Based subfeature is selected.). The constraint can be specified at the constraints tab, showed at the bottom of Figure 4. Moreover, the tool reports missing properties (e.g., an alert is shown when the value of Time is not configured even though the subfeature is selected.). This feature configuration can be exported as XML to be used for source code generation or the estimator in the section 4.3.
9 http://gp.uwaterloo.ca/fmp/
The Computer Journal,
4.
5
PERFORMANCE ESTIMATION IN MOPPET
Performance estimation in Moppet is performed using event calculus and network calculus. Generally speaking, event calculus is based on general preposition dictate the notions of events, fluent, and the time series for which a fluent holds and the relationship among them. Fluent is a condition, i.e., logical state, that can change over time. Based on the relationship among events, fluent and time, event calculus can be used to reasoning about missing fact about event, fluent and time. For example, assume that a sensor node consume 100 mW of battery every an hour it is turned on and the sensor node has 1500 mW/Hr battery, then, event calculus can answer question like, how long the sensor node can operate if it is always on ? or if the sensor node need to be operated for 1 year, then, what should be its sleep period?. Network calculus is an algebra for network traffic flow. Basically, network calculus use the arrival and service curve to specify the theoretical bound of the traffic at any particular time. This traffic bound is calculated from the amount of traffic arrival to or departure from the traffic flow. Thus, network calculus provides a set of algebraic operators to update the traffic bound based on the arrival and departure flow. 4.1.
Event Calculus
Following list shows basic event calculus predicates. 1. 2. 3. 4. 5. 6. 7.
τ1 < τ2 : Time point τ1 is before time point τ2 Initiates(α, β, τ): Fluent β starts to hold after event α occurs at time τ Terminates(α, β, τ): Fluent β cease to hold after event α occurs at time τ Happens(α, τ): Event α occurs at time τ HoldsAt(β, τ): Fluent β holds at time τ Releases(α, β, τ): Fluent β is not subject to common sense law of inertia after event α at time τ Trajectory(β1 , τ, β2 , δ): If fluent β1 is initiated at time τ then fluent β2 holds at time τ + δ
As this list shows, in the event calculus, fluents are firstclass citizen, which can be quantified over and can appear as the arguments to predicates. At the first line of the list, a time point can be specify before the other time point. Likewise, two time point can have after or exactly the same relationship, which can be represented by using > and = symbols, respectively. In the second a fluent β starts to holds, i.e., becomes true in the sense of prepositional logic, as an effect of an event α occurs at a particular time τ. After the time τ, the fluent β holds until it is altered by some event. This is called The Common Sense Law of Inertia, which is inspired by the Newton’s first law of motion. For example, consider following formula, Initiates(TurnOn, Opearting, t), it specifies that if a sensor node is turned on at time t, then it starts to operate at time t and so on. The third line, on the other hand, dictate that a fluent β cease Vol. ??,
No. ??,
????
6
P. Boonma and J. Suzuki
to be holds, i.e., becomes false, as an effect of an event α occurs at time τ. The predicate Happens(α, τ) at the fourth line prescribes that event α occurs at time τ. This predicate associate an event with the time that the event occurs. The HoldsAt(β, τ) at the fifth line, on the other hand, evaluate whether the fluent β holds at the time τ. For example, consider following formulae, Listing 1. Example Conditional Formulae 1 2
HoldsAt ( BattLevel (0) , t) → Happens (TurnOff , t). Terminate (TurnOff , Operating , t).
The first line describes the relationship between HoldsAt() and Happens() predicates. In the fist predicate, BattLevel() is a function which check the input parameter, e.g. 0, and compare the input parameter with the current battery level and return true when they are the same. Thus, from the first line, if the batter level is zero at time t, the first predicate becomes true; thus, it implies that the second predicate becomes true as well. As a consequence, the event TurnOff occurs. In the second line, if the event TurnOff occurs at time t, then the sensor node stops to operate. In conclusion, this formulae dictates that if the battery level is zero, then sensor node will stop to operate. The sixth line represents a particular property of event calculus. As discussed before, a fluent is assumed to preserve its current state until an external event is applied to the fluent. The sixth line in the list allows a fluent to be released from The Common Sense Law of Inertia such that its state can be changed without direct event applied to it. The seventh line in the table represents a continuous changes, such as height of a falling leaf or battery level, in a fluent caused by an event. Basically, if fluent β1 is initiated at time τ, then it is projected that the event β2 will holds at time τ + delta. What happens when Happens Event Calculus Reasoner
What true when HoldsAt
What actions do Initiates Terminates Releases Trajectory
FIGURE 5. Relationships Among Predicates
Figure 5 shows the relationship among different types of predicate. In general, predicates can be categorized into three type group on the relationship among fluent, event and time in that predicate. First, predicates in the group what happen when do represents the relationship between event and time. The second group, what actions do represents the relationship between event and fluent. Finally, the group what true when represents the relationship between the fluent and time. Then, based on given formulae, event calculus reasoner can reason about missing information. The Computer Journal,
Listing 2. An Example Axiom on Continuous Changes 1 2 3 4 5
6
7 8 9 10
Initiates (Start , Operating , t). Terminates (Stop , Operating , t). Release (Start , BattLevel ( level ), t). HoldsAt ( BattLevel (0) , t) → Happens (Stop , t). HoldsAt ( BattLevel ( level1 ), t1) ∧ level2 = level1 - offset → Trajectory ( Operating , t1 , BattLevel ( level2 ), offset ). HoldsAt ( BattLevel ( level1 ), t) ∧ HoldsAt ( BattLevel ( level2 ), t) → level1 = level2 HoldsAt ( BattLevel (100) , 0) ! HoldsAt (Operating , 0) Happens (Start , 0) ? HoldsAt (Operating , 200)
Listing 2 shows an example of event calculus axiom that can be used to estimate the power consumption of a sensor node. Assume that a sensor node consumes one battery power unit at a time and given a particular initial battery level and required operating period, this axiom can conclude whether the sensor node can still operate at the end of the required operating period. The first and second line indicate that when Start and Stop event occurs at time t, the sensor node starts and stops operate, respectively. In the third line, battery level fluent (i.e., BattLevel(level)) is released from the common sense law of inertia; thus, the battery level can be changed indirectly. The fourth line indicates that when batter level is zero, i.e., sensor node is running out of battery, then sensor node stops operating by emitting Stop event. The fifth line in the listing 2 shows an example of using continuous changes predicates to calculate the power consumption of sensor node, in this line, if a sensor node has batter level at level1 at time t1 and the new battery level level2 is reduced from level1 by some amount (assume that battery level is reduced one unit per unit time), then the new battery level level2 will hold at time t1 + offset given that the sensor node starts operating at time t1. The sixth line in the listing is called state constraint. Because the battery level is released from the common sense law of inertia, without explicit specification, multiple battery level state is possible. Thus, in order to guarantee that at each particular time only single battery level holds, the state constraint, like in the sixth line, is required. The seventh line indicates the initial battery level, which is one hundred unit at the beginning (time zero) and the eighth line indicates that sensor node is not operating initially. Then, the ninth line states that a Start event occurs at time zero which allows sensor node to operate. Finally, the tenth line evaluate the Operating fluent at time 200th to see whether the sensor node still operates at time 200th10 . Based on the feature model for WSNs proposed in section 3, we proposed an event calculus model for performance engineering in WSNs, specifically, the proposed calculus model can be used to estimate the sensor node lifetime according to feature configuration. Figure 6 shows the overview of the proposed event calculus model. The left most column shows the event time in event calculus. The second column shows the duty cycle state of the sensor node. 10 The
Vol. ??,
answer is no.
No. ??,
????
Moppet: A Model-Driven Performance Engineering Framework for Wireless Sensor Networks Event Time
Duty Cycle
0
Sleep
1
Wakeup
Event Start
Sleep
!WakeUp ➔ Start
3
Wakeup
WakeUp ➔Sleep
4
Sleep
5
Wakeup
6
Sleep
7
Wakeup
8
Sleep
9 10
Wakeup
Start ➔ Wakeup Sleep ➔ !WakeUp
GpsOff
GpsOff ➔ !Gps, EventDetectionApp, DataCollectinApp
Sleep
11
Wakeup
12
Sleep
ceases to hold. The switching of Wakeup fluent to hold or not to hold controls the duty cycle of the sensor nodes. Listing 4 shows fraction of event calculus axiom which controls the duty cycle.
Fluents Level(batt=1.5M), Gps, !EventDetectionApp, !DataCollectinApp, !EventDetect, Operating
2
...
...
EventOccurProb(sensor, eventprob1 = 0) ➔ EventDetect Sleep ➔ !EventDetect
Listing 4. Example Predicates on the Duty Cycle Controller 1 2 3 4
The third and forth column shows the events (shown in italic words) and fluents that happen or changed in each event time. In the figure, each sensor node’s duty cycle is represented by two event time unit, one is used when node wakes up and the other when node slepdf. Initially at event time 0, several parameters are configured according to the feature configuration customized by developers (see Figure 4 for the example of feature configuration used in this section). For example, the battery level is in itially set to 1500000 µA/hr. GPS feature, which is represented by a fluent, is turned on (or holds) but EventDetectionApplication and DataCollectinoApplication feature are disabled (in the figure, exclamation symbol dictate that the feature is disabled, i.e., the fluent does not hold). This is according to the after relationship which govern that data collection and event detection application must performed after the localization (i.e., GPS) is finished (i.e., GPS supposes to turn-off after three duty cycle). Listing 3 shows the fraction of event calculus axiom which archive this initialization.
Listing 5. Example Predicates on Probabilistic Event Occurrence 1 2
3
Listing 3. Example Initialization Predicates sensor mote ! HoldsAt ( WakeUp (Mote) ,0). ! HoldsAt ( EventDetect (Mote), 0). HoldsAt ( Level (Mote ,1500000) ,0). ! HoldsAt ( EventDetectionApplication (Mote), 0). ! HoldsAt ( DataOllectionApplication (Mote), 0). HoldsAt (Gps(Mote), 0). Happens ( GpsOff (Mote), 6). Happens ( Start (Mote) ,0).
At each duty cycle, the sequence of action which used for controlling the sensor node duty cycle is performed. For example, at time 2, because of Wakeup fluent does not hold, i.e., node is sleeping, so Start event is emitted. Then, in the next event time, because of the Start event, Wakeup fluent holds at this event time. However, because the Wakeup fluent holds, the Sleep event is emitted. As a consequence, in the next event time, Sleep event causes the Wakeup fluent The Computer Journal,
HoldsAt ( WakeUp ( sensor ), time) → Happens ( Sleep ( sensor ), time). Terminates ( Sleep ( sensor ),WakeUp ( sensor ),time). ! HoldsAt ( WakeUp ( sensor ), time) → Happens ( Start ( sensor ), time). HoldsAt ( Operating ( sensor ), time) → Initiates ( Start ( sensor ),WakeUp ( sensor ),time).
At the event time 6, GpsOff event is emitted (see the 8th line in the listing 3. Because of this event, event calculus enables event detection and data collection application. In contrast with the other estimators which based on mathematical model, event calculus allows developer to create conditional behavior based on temporal condition, i.e, some behavior occurs at a specific time, or boolean condition, i.e., xor-relation between GPS and Data Collection/Event Detection. This conditional behavior can be used to changed the power consumption of sensor node according to difference condition, e.g., sensor node consume more power when GPS is turned on than when it is turned off. At the event time 11, based on non-deterministic property of event calculus, probabilistic event occurrence can be simulated. Listing 5 shows the fraction of event calculus code to archive the probabilistic event occurrence and its effect.
FIGURE 6. An Example Event Flow
1 2 3 4 5 6 7 8 9
7
4
range eventprob 0 100 HoldsAt ( EventOccurProb (sensor , eventprob ), time) ∧ eventprob < 1 & HoldsAt ( Operating ( sensor ) ,time) → Initiates ( Start ( sensor ), EventDetect ( sensor ),time). HoldsAt ( Level (sensor , batt1 ),time) ∧ batt2 = batt1 - 30 ∧ HoldsAt ( EventDetectionApplication (Mote), 0) ∧ ! HoldsAt ( EventDetect ( sensor ), time) → Initiates ( Sleep ( sensor ), Level (sensor , batt2 ), time). HoldsAt ( Level (sensor , batt1 ),time) ∧ batt2 = batt1 - 34 ∧ HoldsAt ( EventDetectionApplication (Mote), 0) ∧ HoldsAt ( EventDetect ( sensor ), time) → Initiates ( Sleep ( sensor ), Level (sensor , batt2 ), time).
In the listing, the first line sets the range of eventprob random variable to be 0 to 100. Then, in the second line, EventOccurProb fluent will randomly select one of the value within the range and assigned to eventprob variable. The variable will be tested against the condtion eventprob < 1 which suggests that the event probability is set to 0.01. Then, if the condition is true (eg., the value of eventprob variable is 0), then the EventDetect holds. Then, if the EventDetect fluent does not hold, at the third line, the Vol. ??,
No. ??,
????
8
P. Boonma and J. Suzuki
new battery level (batt2) is calculated by current battery level (batt1) by 30 µA reduction. On the other hand, if the EventDetect fluent holds, at the fourth line, 34 µA battery reduction is performed instead, i.e., sensor node needs to use more battery power to reporting event. Then, in the next event time, e.g., 12th event time in Figure 6, EventDetect fluent is disable, indicate that the event is finished. 4.2.
Network Calculus
Network calculus is an extension of Cruz’s service curve [17, 18] which derives the the concepts of packet arrival/departure and service curves based on queuing model. A network link can be seen as a queue with one buffer; thus, arrival package, i.e., a packet sent out from a network node, is added to the end of the queue while the departure package, i.e., a package arrived at a network node, is removed from the beginning of the queue. However, Cruz’s concept is shortcoming for a network with multiple links, i.e., for a wireless network or a large-scale wired network, because such network has to be modeled as a network of queues, which is not suitable for single-queue assumption of Cruz’s service curve. Thus, Le Boudec and Thiran extends the Cruz’s work by introduced extended service curve [4] by removing the limitation on the queue such that the new system can be applied to any input-output system, be it a queuing system or not. Thus, the extended service curve can be extended to network with multiple ,wired or wireless, links. Then, in order to calculate the traffic in each link, the Min-plus algebra is used instead of queuing theory. Min-plus algebra is an area in mathematics focuses on the calculation on the topological space. In particular, addition in conventional algebra is replaced by the point-wise minimization while the multiplication is replaced by the point-wise addition. The usage of min-plus algebra in the extended service curve is the basic of network calculus. Following in this section, the Cruz’s service curve is introduced first, then, the network calculus is explained. A service curve expresses a bound of a network property, e.g., bandwidth or delay, at a particular time. Formally, consider a system S , which takes data in and outputs data after some delay. Let R(t) be the arrival function, i.e., the amount of data (in bit) flow into the system s in time interval [0,t]. Then R∗ (t) is the arrival function of the output flow defined in the similar fashion as R(t) but consider the output flow of S . Therefore, the backlog, i.e., the data still in the system S , at time t is R∗ (t) − R(t). In particular, the backlog over time is the current bandwidth of the link. Moreover, if d(t) is the delay of the system at time t, i.e.; d(t) = inf T : T ≥ 0 ∧ R(t) ≤ R∗ (t + T )
(1)
in the other words, R∗ (t + d(t)) = R(t). To represent the bounded delay and backlog for arbitrary system, Cruz introduces the concept of arrival and queue service curves. •
Given a function α, a flow is constrained by α if and only if ∀s ≤ t; R(t) − R(s) ≤ α(t − s). Function α is called The Computer Journal,
•
an arrival curve for flow R. In particular, function α dictates the bound of the traffic increment between two time points. The queue offers to a flow of a queue service curve β if and only if for all time t, there exists some t0 ≤ t such that the backlog for the flow in the queue at time t0 is zero and R∗ (t) − R∗ (t0 ) ≥ β(t − t0 ). In particular, function β dictates the bound of the queue that can keep the output flow increasing.
From these two curves, Cruz concludes that the delay d(t) at any time t satisfies the following inequality: d(t) ≤ sup(inf T : T ≥ 0 ∧ α(t) ≤ β(s + T ))
(2)
s≥0
In particular, the delay at time t is less than the maximum bound of the time that minimize the difference between the arrival curve (how fast the data come to the system) at time t and the service curve (how fast the system can process the data) at time s + T where 0 ≤ s ≤ t and T ≥ 0. Moreover, the backlog x(t) at any time t satisfies the following inequality: x(t) ≤ sup(α(s) − β(s)).
(3)
s≥0
In particular, the backlog is less than the minimum bound of the difference between the arrival curve and the service curve at time s; s ≤ t. Further, Cruz concluded that the maximum end-to-end delay variation is bound by following equation; β(t) =
inf
t1 +···+tI =t
β1 (t1 ) + · · · + βI (tI )
(4)
where I is the number of network node (i.e., hop count). In particular, the network service curve β(t) which bounds the end-to-end delay is the summation of the service curve at each node along the path. Finally, the output from the queue is constrained by arrival curve α∗ of output flow given by α∗ (t) = sup(α(t + v) − β(v))
(5)
v≥0
Then, in the extended service curve, the network queue is replaced by an input-output system. Formally, consider a flow with arrival function R, input to a bit processing system S and R∗ is the output function. S offers to the flow an extended service curve β if and only if for all t ≥ 0, there exists some t0 ≥ 0, which t0 ≤ t, such that R∗ (t) − R(t0 ) ≥ β(t − t0 ). This definition is very close to that of the queue service curve, but the new definition does not limit the backlog size at t0 to zero. To represent the arrival curve of output flow in Equation 5, a new operator called Minus operator is introduced. For two functions γ1 and γ2 , define γ1 and γ2 by γ1 γ2 = supu≥0 γ1 (t + u) − γ2 u. Thus, the output flow in Equation 5 can be rewritten as α∗ = α β. Likewise, the Min-Plus operator is introduced as γ1 ⊕ γ2 = inf 0≥u≥t γ1 (u) + γ2 (t − u). For example, the network service curve in equation 4 can be rewritten as β = β1 ⊕ · · · ⊕ βI Vol. ??,
No. ??,
????
Moppet: A Model-Driven Performance Engineering Framework for Wireless Sensor Networks By using the minus and min-plus operator, the bound of traffic and delay in each network link of a given network topology can be calculated and updated in each time point. For example, when a node traffic production function (i.e., arrival curve of input flow) is α(t) while the current traffic in a link connected to the node has the capacity function (i.e., network service curve) of β(t); then, the traffic flow of this link (γ(t)) according of the network node traffic can be calculated as γ(t) = α(t) β(t). Moreover, consider a link which connects two two network nodes a, and b, which have traffic production function as αa (t) and αb (t), respectively, the previous example can be revised to includes the traffic from both network nodes, i.e., γ(t) = (αa (t) ⊕ αb (t)) − β(t). The ⊕ symbols merges the traffic from the two nodes while the deduct the traffic which still stay inside of the link because of network delay. Thus, the output is the traffic flow that depart from this link. For a proactive routing algorithm, e.g., spanning tree, each sensor node is assumed to know where to send the data to. For example, in the case of spanning tree, each node is assumed to know who is its parent node. Thus, only the data traffic flow is considered. However, for the reactive routing algorithm, e.g., AODV, there are two traffic flow. One is the route request (RREQ) traffic generated from a sensor node who wants to find a route to a destination node. This traffic flow is flooded into the network. Then, after a destination node is found, another traffic flow, for data transmission, is considered. 4.3.
Using Event and Network Calculus for Performance Estimation in Moppet
...
...
...
1111 0000 0000 1111 0000 1111 0000 1111 0000 1111 0000 1111
Base Station Sensor Node, governed by Event Calculus’ Formulae Wireless link Network Calculus’ Queue
FIGURE 7. Structure of the Performance Estimator
Figure 7 shows the structure of the Moppet performance estimator. The estimator combines a model written in event calculus for estimating the characteristic, e.g., power consumption, of sensor nodes and a model written in network calculus for estimating the characteristic, e.g., bandwidth bound, of links in the sensor network. Then, the models are constructed into a particular topology, e.g., grid The Computer Journal,
9
, using network calculus topology construction. The path of the data packet is determined by the network calculus model using Dijkstra’s Shortest Path algorithm. As dictated from the figure, the same event calculus model is used in each sensor node and the same network calculus model is used in each network link. When an event calculus model project that a data packet production will be occurred at a particular time , e.g., when an event is detected and sensor node wants to report that event, then the traffic generated from that packet is added to the links connected to the node. In particular, an event calculus’ event , i.e., PublishEvent is binded with the packet arrival queue of all connected links to a sensor node. Therefore, when the node publish and event, e.g., using HoldsAt(PublishEvent, t) -> UpdateLinksArrivalQueue() , the network calculus model of that particular links are updated, e.g., the arrival curve (R(t)) is updated. On the other hand, when the network calculus produces a output flow to particulars node, e.g. from the arrival curve of output flow (R ∗ (t)), and event is added to event calculus model of the node, i.e, using Trajectory(Operating, t, PacketArrival, 1) predicate. 5.
EVALUATION
This section evaluates Moppet through simulations and empirical experiments. Simulations are carried out with TOSSIM [19], a simulator for TinyOS. Empirical experiments are conducted with iMote2 sensor nodes. Both simulations and empirical experiments use the the feature configuration shown in Table 1. This evaluation study emulates an oil spill and operates a WSN application that detects a spill as an event with sensor nodes, each of which equips a fluorometer. (See also Section 2.) The spill is emulated to contain 110 barrels (approximately 3,100 US gallons) of crude oil and to be spilled in the middle of Dorchester Bay, Massachusetts, in the U.S. The spilled oil moves and spreads out due to the water current and tide. To describe this oil movement, a set of spatio-temporal emulation data is generated with an oil spill trajectory model implemented in the General NOAA Oil Modeling Environment11 . The emulation data contains sensor data (i.e., fluorescence reading) at each node, associated with a timestamp. Every node is supplied with this emulation data and emulates its sensor reading in each duty cycle. This evaluation study uses three different WSNs that consist of 16, 100 and 400 nodes deployed uniformly in an observation area. The observation area is 150x150 meters for a WSN of 16 nodes, while it is 300x300 meters for WSNs of 100 and 400 nodes. An oil spill is emulated to occur at the north-western corner of the observation area. Each node’s communication range is 30 meters. A base station is deployed at the center of the observation area. The Moppet performance estimator uses the same power consumption characteristics as the one in TOSSIM [20]. 11 http://response.restoration.noaa.gov/software/gnome/gnome.html
Vol. ??,
No. ??,
????
P. Boonma and J. Suzuki
Feature Name
Configuration
Application - Event Probability - Event Prob. Distribution - Event Filter Localization Data/Event Archive Data Aggregation - Data Aggregation Operator - Data Aggregation Prob. - Data Aggregation Prob. Dist. Persistence Storage Concurrency OERP L3 - Packet Loss Rate - Routing QosPolicy - Latency-budget - Retransmission - Packet Duplication Duty Cycle Hardware-Profile - GPS - Battery Capacity - Flash Memory - Max Bandwidth
Event Detection Obtained from GNOME Gaussian Distribution Fluorescence spectrum > 300 nm GPS-based Time: 1 hour Merge 0.05 Gaussian Distribution External Storage Per-topic Spanning Tree
45 TOSSIM Moppet Empirical Node Lifetime (Days)
10
35
30
25 0
1
0.01 Single-Hop Routing
2 3 Node Location (Hop Count)
4
5
FIGURE 8. Node Lifetime in a Network of 16 Nodes 300 seconds 3 2 300 seconds iMote2 Enabled 2800 mA/hour 512 KB 38 kbps
5% and 11%. In a network of 400 nodes, the average and maximum estimation errors are 2% and 4%. These trends of estimation error are similar to the one obtained in a network of 16 nodes (Figure 8). Figures 9 and 10 illustrate that Moppet scales well to network size; its node lifetime estimation is accurate and practical in large-scale networks. 45
Node Lifetime
Figure 8 shows the node lifetime that Moppet estimates for a network of 16 nodes. It also compares the result with simulated and empirical lifetime results. Node lifetime is defined as the period in which a node can continue to operate until it runs out of its battery. The X-axis of Figure 8 indicates the location of nodes based on the hop count from the base station. Each of simulated and empirical results shows the average lifetime of nodes with the same hop count from the base station. Its range bar denotes the standard deviation of node lifetime. Figure 8 demonstrates that Moppet’s node lifetime estimation is accurate compared with simulated and empirical results. The average estimation error is 5% and 9% against simulated and empirical results. The maximum estimation error is 8% and 11% against simulated and empirical results. Note that the Moppet performance estimator is designed to be optimistic; estimated node lifetime is generally longer than simulated and empirical results. This stems from the fact that Moppet does not consider all factors that impact power consumption of nodes. However, the accuracy of Moppet’s node lifetime estimation is acceptable and practical. Figures 9 and 10 show estimated and simulated node lifetime results in the networks of 100 and 400 nodes, respectively. Except the number of nodes, all configurations are same as the one used for Figure 8. In a network of 100 nodes, the average and maximum estimation errors are The Computer Journal,
Node Lifetime (Days)
TABLE 1. A Feature Configuration Used in Simulations and Empirical Experiments
5.1.
40
TOSSIM Moppet
40
35
30
25
0
1
2
3
4 5 6 7 8 Node Location (Hop Count)
9
10
11
FIGURE 9. Node Lifetime in a Network of 100 Nodes
5.2.
Network Lifetime
Table 2 shows estimated, simulated and empirical network lifetime. The results are obtained in the networks of 16, 100 and 400 nodes. (Empirical experiments are carried out only for a network of 16 nodes.) Table 2 uses three different ways to determine network lifetime: (1) the period until the first node goes down due to a lack of battery, (2) the period until 50% of nodes go down in the network due to a lack of battery, and (3) the period until the base station receives the last data from nodes in the network. Compared with simulation results, Moppet’s average and maximum estimation errors are 5% and 11%, respectively. They are 8% and 11% compared with empirical experiment Vol. ??,
No. ??,
????
Moppet: A Model-Driven Performance Engineering Framework for Wireless Sensor Networks 25
30
Number of Packets per Second
Node Lifetime (Days)
28 26 24 22 20 18
TOSSIM Moppet Empirical 20
15
10
5
TOSSIM Moppet
16
0
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 Node Location (Hop Count)
The period until the first node goes down The period until 50% of nodes go down The period until the base station receives the last data
Estimation Simulation Empirical Exp. Estimation Simulation Empirical Exp. Estimation Simulation Empirical Exp.
16
100
400
27.74 29.32 28.45 45.9 42.3 41.4 45.9 42.3 41.4
30.5 27.4 N/A 37.7 36.15 N/A 35.7 34.7 N/A
17.1 17.0 N/A 24.5 24.0 N/A 23.7 23.3 N/A
1
2 3 Node Location (Hop Count)
4
5
TABLE 2. Network Lifetime (Days) in the Networks of 16, 100 and 400 Nodes
120 100 80 60 40 20 0
Bandwidth Consumption
Figure 11 shows the bandwidth consumption that Moppet estimates for a network of 16 nodes. It also compares the result with simulated and empirical results of bandwidth consumption. Bandwidth consumption is defined as the number of packets that nodes transmit toward the base station in each second. The X-axis of Figure 11 indicates the location of nodes based on the hop count from the base station. Each of simulated and empirical results shows the average bandwidth consumption of nodes with the same hop count from the base station. Its range bar denotes the standard deviation of bandwidth consumption. Figure 11 demonstrates that Moppet’s estimation of bandwidth consumption is accurate and practical compared with simulated and empirical results. The average estimation error is 3% and 8% against simulated and empirical results. The maximum estimation error is 6% and 12% against simulated and empirical results. Figures 12 and 13 show estimated and simulated The Computer Journal,
0
1
2
3 4 5 6 7 8 Node Location (Hop Count)
9
10
11
FIGURE 12. Bandwidth Consumption in a Network of 100 Nodes
700
Number of Packets per Second
results. These results demonstrate that Moppet’s network lifetime estimation is accurate enough. Moreover, Table 2 shows that Moppet scales well to network size; the trends of estimation error remain similar as the number of nodes grows.
TOSSIM Moppet
140 Number of Packets per Second
# of Nodes
0
FIGURE 11. Bandwidth Consumption in a Network of 16 Nodes
FIGURE 10. Node Lifetime in a Network of 400 Nodes
5.3.
11
TOSSIM Moppet
600 500 400 300 200 100 0 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 Node Location (Hop Count)
FIGURE 13. Bandwidth Consumption in a Network of 400 Nodes
bandwidth consumption in the networks of 100 and 400 nodes, respectively. Except the number of nodes, all Vol. ??,
No. ??,
????
P. Boonma and J. Suzuki
configurations are same as the one used for Figure 11. In a network of 100 nodes, the average and maximum estimation errors are 6% and 10%. In a network of 400 nodes, the average and maximum estimation errors are 5% and 10%. These trends of estimation error are similar to the one obtained in a network of 16 nodes (Figure 11). Figures 12 and 13 demonstrates that Moppet scales well to network size; its estimation of bandwidth consumption is accurate and practical in large-scale networks. The results in Figures 11, 12 and 13 can be used to estimate the maximum allowable packet size in a WSN application that has a constraint in wireless channel bandwidth. For example, assume an application that operates 100 iMote nodes with the bandwidth of 38.4 kbps. The maximum bandwidth consumption is approximately 136 packets per second, as Figure 12 shows. Therefore, the maximum allowable packet size is approximately 290 bits. Beyond this size, the bandwidth of 38.4 kbps can be saturated.
TOSSIM Moppet Empirical
16 14 Network Latency (Second)
12
12 10 8 6 4 2 0 0
Data Yield
Table 2 shows estimated, simulated and empirical results of data yield. The results are obtained in the networks of 16, 100 and 400 nodes. (Empirical experiments are carried out only for a network of 16 nodes.) Data yield is determined as d/t where d denotes the number of data delivered to the base station and t denotes the number of data transmitted from nodes toward the base station. Compared with simulation results, Moppet’s average and maximum estimation errors are 3% and 5%. The estimation error against an empirical result is 0%. These results The Computer Journal,
4
5
TOSSIM Moppet
140 120 100 80 60 40 20 0 0
1
2
3 4 5 6 7 8 Node Location (Hop Count)
9
10
11
FIGURE 15. Data Transmission Latency in a Network of 100 Nodes
300 Network Latency (Second)
5.5.
Network Latency (Second)
Latency of Data Transmission
Figure 14 shows shows the data transmission latency that Moppet estimates for a network of 16 nodes. It also compares the result with simulated and empirical results of data transmission latency. Latency indicates how long it takes for a node to transmit data to the base station. The X-axis of Figure 14 shows the location of nodes based on the hop count from the base station. Figure 14 demonstrates that Moppet’s estimation of data transmission latency is accurate and practical, compared with simulated and empirical results. The average estimation error is 7% and 8% against simulated and empirical results. The maximum estimation error is 10% and 13% against simulated and empirical results. Figures 15 and 16 show estimated and simulated latency results in the network of 100 and 400 nodes, respectively. Except the number of nodes, all configurations are same as the one used for Figure 14. In a network of 100 nodes, the average and maximum estimation errors are 6% and 10%. In a network of 400 nodes, they are 9% and 17%. These trends of estimation errors are similar to the one obtained in a network of 16 nodes (Figure 14). Figures 15 and 16 illustrate that Moppet scales well to network size; it’s latency estimation is accurate and practical in large-scale networks.
2 3 Node Location (Hop Count)
FIGURE 14. Data Transmission Latency in a Network of 16 Nodes
160
5.4.
1
TOSSIM Moppet
250 200 150 100 50 0 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 Node Location (Hop Count)
FIGURE 16. Data Transmission Latency in a Network of 400 Nodes
Vol. ??,
No. ??,
????
Moppet: A Model-Driven Performance Engineering Framework for Wireless Sensor Networks # of Nodes
16
100
400
Memory Footprint (KB)
Moppet-generated code
Surge
Estimation Simulation Empirical experiment
98% 99% 98%
95% 92% N/A
91% 87% N/A
RAM Flash Memory
7.6 120.8
4.9 86.9
TABLE 3. Data Yield in the Networks of 16, 100 and 400 Nodes
demonstrate that Moppet’s data yield is accurate enough. Moreover, Table 2 shows that Moppet scales well to network size; the trends of estimation error remain similar as the number of nodes grows. 5.6.
Performance Estimation Efficiency
Figure 17 shows the time required to conduct a Moppetbased performance estimation, a TOSSIM-based simulation and an empirical experiment. In each case, a WSN application is operated for 300 minutes, following the feature configuration shown in Table 1. Moppet and TOSSIM run on the same computer equipped with a 2.0 GHZ dual core processor and 2 GB memory. In a network of 16 nodes, it takes 18.2 and 101 minutes to run Moppet and TOSSIM, respectively. Thus, Moppet is 94% and 82% more efficient than an empirical experiment and TOSSIM. In a network of 100 nodes, Moppet is 89% and 82% more efficient than an empirical experiment and TOSSIM. In a network of 400 nodes, it is 46% and 85% more efficient than an empirical experiment and TOSSIM. (With 400 nodes, a TOSSIM spends more time than an empirical experiment.) As these results show, Moppet significantly improves the efficiency of performance estimation than TOSSIM does. Moreover, Figure 17 illustrates that Moppet scales better to network size than TOSSIM. In a large-scale network of 400 nodes, Moppet is 46% more efficient than an empirical experiment, while TOSSIM’s simulation time is 3.4 times longer than the time of an empirical experiment. 1200
1000
Moppet TOSSIM Empirical
1033
800 Time (Min.)
13
600
400
300
300 193
200
300 162.3
101 34.5
18.2 0 16
100 Number of Nodes
400
FIGURE 17. Performance Estimation Efficiency
The Computer Journal,
TABLE 4. Memory Footprint of Generated Code on an iMote2 Node
5.7.
Memory Footprint of Generated Code
Table 4 shows the memory footprint of nesC code generated from the feature configuration in Table 1. It consumes approximately 8 KB and 121 KB in RAM and flash memory, respectively. Table 4 also shows the memory footprint of Surge, a simple data collection application bundled in TinyOS. (Serge implements a shortest-path routing protocol based on a spanning tree.) The difference in memory footprint between Moppet-generated code and Surge is 2.7 KB in RAM and 33.9 KB in flash memory. This difference is fairly small, given the fact that Serge does not perform most of the functions of Moppet-generated code (e.g., data aggregation, concurrency, data retransmission and data duplication). Table 4 demonstrates that Moppet successfully generates lightweight code. 6.
RELATED WORK
Several studies have investigated model-driven development for WSN applications. They intend to improve the productivity of designing and implementing applications through Unified Modeling Language (UML) profiles [21– 23] and domain-specific languages [24–26]. Unlike them, Moppet considers performance engineering as well as application design/implementation in a model-driven manner. Moreover, it employs feature modeling so that even non-programmers can build WSN applications and estimate their performance. This work is the first attempt to study model-driven performance engineering in WSNs. Feature modeling has been used to configure the capabilities/parameters in an embedded operating system [27] and WSN applications [28]. However, these work do not study model-driven performance engineering as Moppet does. Moppet also investigates a new modeling element that these work do not consider (the after relationship). In the area of networks research, performance engineering often focuses on mapping application designs to performance analysis methods [29] or transforming application designs to program code to be tested with simulators [30–33]. Some of those work estimate power consumption [30, 32], and others estimate bandwidth consumption [29,33]. In contrast, Moppet can carry out both simulator-less performance estimation and code generation. Generated code can run on the TOSSIM simulator as well as TinyOS-based physical nodes such as iMote nodes. In WSNs, performance engineering has been studied in different network layers such as data link layer [34], network layer [35] and application layer [36]. All of them rely on simulation-based performance estimation techniques. Unlike them, Moppet aids simulator-less Vol. ??,
No. ??,
????
14
P. Boonma and J. Suzuki
performance estimation with event calculus and network calculus. This way, it significantly improves the efficiency of performance estimation, compared with a simulation-based approach, as Section 5.6 describes. This work is the first attempt to leverage event calculus and network calculus for performance engineering in WSNs. Most of existing estimation methods for power consumption in WSNs focus on network traffic characteristics [37– 42] because data communication is a critical source of power consumption in WSNs [20]. Moppet considers more sources of power consumption in addition to network traffic characteristics; for example, event occurrence/propagation probability and data aggregation probability. This allows Moppet to estimate power consumption under a wider range of scenarios and assumptions. For example, it can infer how different assumptions in event occurrence frequency impact power consumption. 7.
CONCLUDING REMARKS
This paper describes a new model-driven development framework, called Moppet, which aids to rapidly build WSN applications and engineer their performance. Moppet estimates a WSN application’s performance without generating its code nor running it on simulators and real networks. It can approximate data yield, data transmission latency and network lifetime as well as each node’s power and bandwidth consumption. Evaluation results show that, in a largescale WSN of 400 nodes, Moppet’s performance estimation is 46% more efficient than empirical performance measurement and its estimation error is lower than 10%. Moppet scales well to network size with respect to estimation efficiency and accuracy. Moppet generates lightweight code that can be deployed on resource-limited nodes. Future research directions include extending Moppet more flexible for a wide range of application developers. Moppet currently requires event and network calculus descriptions of all intra- and inter-activities of nodes that impact application performance. It could be a steep learning curve for developers to understand event and network calculus for extending Moppet beyond its default intraand inter-activities of nodes. Therefore, the authors of the paper plan to investigate a scripting language that allows developers to flexibly extend Moppet in an easy-touse/understand way. Moppet will transform the descriptions of this DSL to event/network calculus expressions. REFERENCES [1] Czarnecki, K., Eisenecker, U., and Czarnecki, K. (2000) Generative Programming: Methods, Tools, and Applications. Addison-Wesley Professional. [2] Kowalski, R. and Sergot, M. (1986) A logic-based calculus of events. New Generation Computing, 4, 67–95. Ohmsha. [3] Shanahan, M. (1999) The event calculus explained. Springer LNCS, 1600, 409–430. [4] Boudec, J.-Y. L. and Thiran, P. (2001) Network Calculus: A Theory of Deterministic Queuing Systems for the Internet. Springer.
The Computer Journal,
[5] Object Management Group (2007). Data Distribution Service (DDS) for real-time systems, v1.2. [6] Boonma, P. and Suzuki, J. (2008) Middleware support for pluggable non-functional properties in wireless sensor networks. Proc. of Workshop on Methodologies for Nonfunctional Properties in Services Computing, Honolulu, HI, USA, July. IEEE Press. [7] Boonma, P. and Suzuki, J. (2009) Toward interoperable publish/subscribe communication between wireless sensor networks and access networks. Proc. of Int’l Workshop on Information Retrieval in Sensor Networks, Last Vegas, NV, USA, Jan. IEEE Press. [8] Object Management Group (2007). Common object request broker architecture (CORBA) specification, version 3.1; part 2: CORBA interoperability. [9] Allen, T. W. (2007) U.S. Coast Guard 2008 budget in brief and performance report. Technical report. U.S. Coast Guard. [10] Siegel, L. (1998) Navy oil spills. Technical report. Center for Public Environmental Oversight. [11] Andrews, J. and Lieberman, S. (1998) Multispectral fluorometric sensor for real time in-situ detection of marine petroleum spills. Water studies series, 3, 291–301. Computational Mechanics Publications. [12] Brown, C., Fingas, M., and An, J. (2001) Laser fluorosensors: A survey of applications and developments. Proc. of Arctic and Marine Oil Spill Program Tech. Sem., Alberta, Canada, June. Environment Canada. [13] Mowery, R. L., Ladouceur, H. D., and Purdy, A. (1997) Enhancement to the et-35n oil content monitor: A model based on mie scattering theory. Technical Report NRL/MR/6176–97. Naval Research Laboratory. [14] Nardella, J. A., Raw, T. A., and Stokes, G. H. (1989) New technology in oil content monitors. Naval Engineers J., 101, 48–55. ASNE. [15] Office of Emergency and Remedial Response (1999) Understanding oil spills and oil spill response. Technical Report EPA 540-K-99-007. US Environmental Protection Agency. [16] Fingas, M. F. and Brown, C. E. (2002) Review of oil spill remote sensors. Proc. of Int’l Conf. on Remote Sensing for Marine and Coastal Env., Miami, FL, USA, May. Veridian. [17] Cruze, R. L. (1991) A calculus for network delay, part i: Network elements in isolation. IEEE Trans. on Info. Theory, 37, 114–131. [18] Cruze, R. L. (1991) A calculus for network delay, part ii: Network analysis. IEEE Trans. on Info. Theory, 37, 114–131. [19] Levis, P. (2003) TOSSIM: Accurate and scalable simulation of entire tinyos applications. Proc. of Conf. on Embedded Networked Sensor Systems, Los Angeles, CA, USA, November. ACM Press. [20] Shnayder, V., Hempstead, M., rong Chen, B., Allen, G. W., and Welsh, M. (2004) Simulating the power consumption of large-scale sensor network applications. Proc. of Int’l Conf. on Embedded Networked Sensor Systems, Baltimore, MD, USA, November. ACM Press. [21] Sadilek, D. A. (2007) Prototyping domain-specific languages for wireless sensor networks. Proc. of Int’l Workshop on Software Language Engineering, Nashville, TN, USA, September. Springer. ´ [22] Vicente-Chicote, C., Loslla, F., Alvarez, B., and Iborra, A. (2007) Applying MDE to the development of flexible and
Vol. ??,
No. ??,
????
Moppet: A Model-Driven Performance Engineering Framework for Wireless Sensor Networks
[23]
[24]
[25]
[26]
[27]
[28]
[29]
[30]
[31]
[32]
[33]
[34]
[35]
[36]
reusable wireless sensor networks. Int’l J. of Cooperative Information Systems, 16, 393–412. World Scientific. Mura, M. and Sami, M. (2008) Code Generation from Statecharts: Simulation of Wireless Sensor Networks. Proc. of Digital System Design Architectures, Methods and Tools, Parma, Italy, September. IEEE Press. Kuorilehto, M., H¨annik¨ainen, M., and H¨am¨al¨ainen, T. D. (2008) Rapid design and evaluation framework for wireless sensor networks. Ad Hoc Network, 6, 909–935. Elsevier. Cheong, E., Lee, E. A., and Zhao, Y. (2006) Joint modeling and design of wireless networks and sensor node software. Technical Report UCB/EECS-2006-150. University of California, Berkeley, CA, USA. Losilla, F., Vecente-Chicote, C., Alvarez, B., Iborra, A., and Sanchez, P. (2007) Wireless sensor network application development: An architecture-centric MDE approach. Springer LNCS, 4758, 179. Lohmann, D., Scheler, F., Preikchat, W. S., and Spinczyk, O. (2006) PURE embedded operating systems - CiAO. Proc. of Int’l Workshop on Operating System Platforms for Embedded Real-Time Applications, Dresden, Germany, July. IEEE Press. Schr¨oder-Preikschat, W., Kapitza, R., Klein¨oder, J., Felser, M., Karmeier, K., Labella, T. H., and Dressler, F. (2007) Robust and efficient software management in sensor networks. Proc. of Int’l Workshop on Software for Sensor Networks, Bangalore, India, January. IEEE Press. Grassi, V., Mirandola, R., and Sabetta, A. (2004) UML based modeling and performance analysis of mobile systems. Proc. of Int’l Symp. on Modeling, analysis and simulation of wireless and mobile systems, Venice, Italy, October. ACM Press. Edwards, G., Malek, S., and Medvidovic, N. (2007) ScenarioDriven Dynamic Analysis of Distributed Architectures. Springer LNCS, 4422, 125. Thompson, C., White, J., Dougherty, B., and Schmidt, D. C. (2009) Optimizing mobile application performance with model-driven engineering. Proc. of Workshop on Software Technologies for Future Embeded and Ubiquitous Systems, CA, USA, November. IFIP. Becker, P., Gotzhein, R., and Kuhn, T. (2008) Model-driven Performance Simulation of Self-organizing Systems with PartsSim. PIK-Praxis der Informationsverarbeitung und Kommunikation, 31, 45–50. Walter de Gruyter GmbH & Co. KG. Fok, C., Roman, G., and Lu, C. (2005) Rapid development and flexible deployment of adaptive wireless sensor network applications. Proc. of Int’l Conf. on Distributed Computing Systems, Columbus, OH, USA, June. IEEE Press. Azgomi, M. and Khalili, A. (2009) Performance Evaluation of Sensor Medium Access Control Protocol Using Coloured Petri Nets. Electronic Notes in Theoretical Computer Science, 242, 31–42. Elsevier. Yang, T., Ikeda, M., De Marco, G., and Barolli, L. (2007) Performance Behavior of AODV, DSR and DSDV Protocols for Different Radio Models in Ad-Hoc Sensor Networks. Proc. of Int’l Conf. on Parallel Processing, Xian, China, September. IEEE Press. Huang, Y., Luo, W., Sum, J., Chang, L., Chang, C., and Chen, R. (2007) Lifetime Performance of an energy efficient clustering algorithm for cluster-based wireless sensor networks. Springer LNCS, 4743, 455.
The Computer Journal,
15
[37] Rai, V. and Mahapatra, R. N. (2005) Lifetime modeling of a sensor network. Proc. of Design, Automation and Test in Europe Conf. and Exhibition, Munich, Germany, March. IEEE Press. [38] Noori, M., M.and Ardakani (2008) A probability model for lifetime of event-driven wireless sensor networks. Proc. of Conf. on Sensor, Mesh and Ad Hoc Comm. and Net., New Orleans, LA, USA, June. IEEE Press. [39] Mounier, L., Samper, L., and Znaidi, W. (2007) Worst-case lifetime computation of a wireless sensor network by modelchecking. Proc. of Workshop on Performance evaluation of wireless ad hoc, sensor and ubiquitous networks, Crete Island, Greece, October. ACM Press. [40] Coleri, S., Ergen, M., and Koo, T. J. (2002) Lifetime analysis of a sensor network with hybrid automata modelling. Proc. of Int’l workshop on Wireless sensor networks and applications, Atlanta, GA, USA, September. ACM Press. [41] Baoqiang, K., Li, C., Hongsong, Z., and Yongjun, X. (2008) Accurate energy model for WSN node and its optimal design. J. of Systems Engineering and Electronics, 19, 427–433. Elsevier. [42] Ruiz-Garcia, L., Barreiro, P., and Robla, J. (2008) Performance of ZigBee-Based wireless sensor nodes for realtime monitoring of fruit logistics. J. of Food Engineering, 87, 405–415. Elsevier.
Vol. ??,
No. ??,
????
