Estimating Energy Savings in Smart Street Lighting by Using an Adaptive Control System

Research Article Estimating Energy Savings in Smart Street Lighting by Using an Adaptive Control System Soledad Escolar,1Jesús Carretero,1Maria-Cristina Marinescu,2and Stefano Chessa3 1Computer Science Department, University Carlos III of Madrid, Legan´ es, 28911 Madrid, Spain 2Computer Science Department, University of Pisa and ISTI-CNR, 56127 Pisa, Italy 3CASE Department, Barcelona Supercomputing Center, 08034 Barcelona, Spain Correspondence should be addressed to Soledad Escolar; [email protected] Received 5 July 2013; Revised 16 October 2013; Accepted 28 October 2013; Published 8 May 2014 Academic Editor: Yu Gu Copyright © 2014 Soledad Escolar et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. The driving force behind the smart city initiative is to offer better, more specialized services which can improve the quality of life of the citizens while promoting sustainability. To achieve both of these apparently competing goals, services must be increasingly autonomous and continuously adaptive to changes in their environment and the information coming from other services. In this paper we focus on smart lighting, a relevant application domain for which we propose an intelligent street light control system based on adaptive behavior rules. We evaluate our approach by using a simulator which combines wireless sensor networks and belief-desire-intention (BDI) agents to enable a precise simulation of both the city infrastructure and the adaptive behavior that it implements. The results reveal energy savings of close to 35% when the lighting system implements an adaptive behavior as opposed to a rigid, predefined behavior. 1. Introduction Providing an appropriate level of city lighting in public spaces is an important issue both for citizens and city councils. Most cities have strategic plans that specify how lighting is to be provided, as well as the intensity levels required for each area. The goals addressed by these plans must be agreed upon among politicians, citizen associations, businesses, and other city stakeholders and usually reflect trade-offs among the goals of the different actors. On one hand, city councils (and possibly environmental agencies) want to provide a sufficient service without wasting energy and money; on the other hand, the rest of the stakeholders ask for comprehensive lighting that can assure safety and create a psychologically positive social environment. City lighting [1]hasalwaysbeenamajorconcern,asit represents 10% to 20% of the electricity use in most countries—sometimes more in developing countries. One of the measures that are most favoured by city councils involves the replacement of the emission devices with new ones based on LED technology [1–4]. But even without investing into replacing less efficient devices, a significant amount of energy can be saved by a more intelligent control of the lighting system [5–9]. This is a trend towards highly sustainable systems that are quickly gaining ground. References [10,11] describe smart street light controllers with dual function of timing control and automatic photoelectric control to save energy in lampposts. The drawback when evaluating the impact of such approaches is that the estimation of the energy savings entailed by this kind of lighting systems is not as straightforward as calculating the benefit of lamppost replacement. This is due to the potential complexity of the control system and the circumstances that may affect its behavior. Having tools that can precisely simulate the smart cities scenarios and estimatethepotentialsavingsinthelamppostswithreasonable accuracy before committing to real deployment is fundamental to effectively support such complex processes. In this paper we introduce a simulator for intelligent street light control systems. This simulator allows users to evaluate the energy efficiency of different public lighting configurations before deciding on a solution and implementing it on Hindawi Publishing Corporation International Journal of Distributed Sensor Networks Volume 2014, Article ID 971587, 17 pages http://dx.doi.org/10.1155/2014/971587 2 International Journal of Distributed Sensor Networks site. Our solution assumes a wireless sensor network (WSN) platform and multiphase lamppost functionality based on LEDs,anditisbasedonanagent-basedapproach.The smart city scenario we are simulating involves a set of intelligent devices—in the Internet of Things (IoT) terminology things—which communicate and coordinate their actions to achieve intelligent street lighting. The devices are installed on the lampposts within the neighborhood that is being monitored and, additionally, in other strategic positions within this area. They have the ability to sense the environment and share their views with each other. This enables them to construct a global picture of the site and make informed decisions about lighting depending on the real-time necessities at their location. The purpose of the system we are simulating is to use the street lighting in an energy efficient manner while guaranteeing service as needed to avoid a negative social impact. The lamppost control devices in our scenario execute applications that are aware of their context and have the abilitytocontinuouslyanddynamicallyadapttheirbehaviorin response to changes in the environment (e.g., ambient light, movement in the environment, and behavior of other communicating devices). In principle the application running on a lamppost may be different from the application running on any other; in practice nevertheless we expect that these applications fit the roles found in WSNs: data collector, cluster head, or sink. An application consists of a set of rules which describe all the possible lamppost behaviors under every relevant set of conditions. Some of these conditions may refer to local phenomena (e.g., values sensed by the device); others may implicitly specify more global properties (e.g., via values passed in messages from other devices). When a change which is specified as a rule condition occurs, the devicemaychoosetoexecuteapossiblynewbehaviorthatis more suitable and efficient in managing its new state. For instance, the application could define a rule to reduce the intensity of a street light if additional nearby lighting is detected. This continuous adaptation to the actual conditions provides flexibility to the applications running on the devices and ultimately results in a sustainable usage of the smart city infrastructure. Decisions are made at two levels: (1) local, wherethedevicesreactonlybasedontheinformationthat they possess from their environment and (2) globally distributed, where the devices interact and cooperate with other devices to react to changes in the environment and make global decisions that control the part of the system that they are responsible for. The remainder of this paper is organized as follows. Section 2 reviews the related work in smart cities and intelligent street light control systems. Section 3 presents the background in autonomic computing systems and the novel approaches that combine WSNs and agents-based systems. In Section 4 we present the system model for self-adaptive applications. Section 5 describes a smart city scenario where lampposts are equipped with devices able to react to the changes in their environment with the purpose of saving energy in the lampposts. Section 6 presents the simulation results and Section 7 discusses the conclusions and future work. 2. Related Work The European Research Cluster (IERC) on the Internet of Things (IoT) [12] has recently identified the most relevant application areas and has grouped them in twelve different vertical themes; one of them is related to smart cities.The concept of smart city is still to be precisely defined; however, the ultimate goal of a smart city is to improve the quality of life of the population while guaranteeing a sustainable development. About 50% of the world population lives in cities and it is estimated that this number will continue to grow to reach 70% by 2050 [12]. The resources demanded by citizens— energy, water, land, and so forth—will also grow at least linearly with the population size; however, it is difficult to see how the supply could follow the same growth curve. This fact imposes severe requirements to managing the basic resources efficiently and sustainably. New technologies have a tremendous potential to monitor and analyze resourceconsuming processes and to bring added value to the services thatacityprovides.Theinfrastructureofthesmartcity— composed of millions of object instances and heterogeneous devices—must act as the pervasive technology [13]which, managed appropriately, can increase the knowledge that citizens, public organizations, and businesses have of their environment and can help making smart decisions with the involvement of the community. One of the scopes that IERC identifies for smart cities is smart lighting [12], which is also the problem addressed in this paper. The design of control strategies meant to match the emitted light level to the actual needs can lead to a significant reduction in energy costs and, in turn, to an efficiency improvement. One of the popular strategies that city councils carry out is replacing old, expensive lights by low-cost and low-CO2emissions devices such as the LED-based devices [2]. According to [1], using LED technology can improve energy efficiency by up to a factor of five without altering light intensity levels and with a relatively low effort. The work described in [3] analyzes the effect of using LED street lights from technical and economic perspectives to indicate savingsof$100,000peryear.Similarly,astudyforthecityof Dublin [4] shows that currently the township spends almost $250,000 a year for a street lighting system with 2,019 lights, 30% of them (the more expensive) mercury vapor lights. They predict that replacing these with more efficient LED-based lightswouldsaveabout$15,000peryear. In addition to replacing less efficient devices, many cities are taking measures that balance citizen satisfaction, expenses, and energy efficiency to achieve a more sustainable lighting system. In [14]theauthorspresentagoalprogramming (GP) model designed to capture multiple objectives involved in sustainable energy-environment management in urban areas. In [15] the authors show a model for rational sustainable development in Vilnius. Jabareen [16] identified sustainable urban forms and their design concepts and equipments. In addition, he addresses the question of whether certain urban forms contribute more than others to sustainability. International Journal of Distributed Sensor Networks 3 The issue of urban energy consumption is not only relevant for street lighting but also for public buildings. In Europe it is estimated that the amount of electric energy consumed in illuminating the interiors of medium and large public buildings is about 40% [5]ofthetotalelectricalenergyused.This study identifies different kinds of buildings (e.g., offices, hospitals, hotels, and restaurants) and defines a light control system that regulates the emission based mainly on two parameters: daylight and occupancy. The evaluation reveals that the system results in energy savings of 25% in industrial and commercial sectors and up to 45% in tertiary and educational sectors. This approach uses WSNs to monitor the environmental conditions. The intelligent street light control system proposed in [6] relies on LED-based lampposts and wireless sensors.Basedonapredefinedscheduleandthesensor information about weather conditions and detection of pedestrians, the system adapts the level of lighting of the lampposts to achieve energy savings between 30% and 40%. In [7] the authors define a control system for an indoor scenario by using a WSN and address the problem of the energy consumption in the sensor nodes by proposing an energyaware communication protocol which increases the lifetimes of the sensor nodes by 20%. Reference [8]analyzesdistributed and centralized models for building environmental control systems. The authors use simulation to evaluate and compare the two models in terms of latency, performance, packet loss, and computational complexity. They demonstrate that, in general, a distributed model behaves better than a centralized model. The works cited above define static behaviors that allow the sensors nodes to regulate the light level of each lamppost. These approaches lack the degree of autonomy and (self-) adaptationthatresults from continuously reasoning aboutthe changes that occur in the environment of the sensor node (beitpurelylocalortheresultofcommunicatingwithother nodes). In fact, [12] recognizes that there exists “a lack of research on how to adapt and tailor existing research on autonomic computing to the specific characteristics of IoT, such as high dynamicity and distribution, real-time nature resource constraints, and lossy environments.” Agents-based systems have been identified as one of the most suitable technologies that could potentially improve the flexibility, robustness, and autonomy [17] of WSN-controlled systems. Reference [9] presents the design of an multiagent systems (MAS)thatusesaWSNtocontrolthelightingofcommercial spaces; it additionally discusses the issues that are important in this type of systems. The authors organize the global sensor network in different subnets according to the preferences of theusers.Eachsubnetconsistsofasetofsensornodes,eachof them executing a single agent. This is still preliminary work and the authors do not present an evaluation of their approach. The work we present in this paper introduces an intelligent street light control system that combines three elements: (1) LED-based lampposts, (2) wireless sensor networks, and (3) agents. Our objective is estimating the energy savings in the lampposts as a result of replacing the fixed behavior of the sensor nodes with an adaptive behavior. This paper contributes to the state-of-the-art in two ways: (1) it describes a way of modeling and simulating the features of smart cities scenarios such that we can estimate the potential energy savings before deployment, and (2) it proposes an adaptive control system that can be implemented by the devices that compose the smart city infrastructure and which ensures sustainability without sacrificing the level of services offered to the citizens. 3. Background Autonomic computing [18] refers to the self-managing characteristics of distributed computing resources, which have the ability to adapt to changes while hiding the intrinsic complexity from the users. Several research groups have focused on autonomy and self-adaptivity for embedded systems [19–22]. The components of an autonomic computing system should be able to independently react to their environment and interact between them to achieve their goals. One of the paradigms which most naturally fits this model is the agentbased approach. Agents have the ability to manage their local knowledge, sense their environment, and share knowledge with other agents [23]. They are continuously reacting to changes in their environment and making decisions that can lead to changes in their behavior. There exist different classes of agents depending on their reasoning capability. We are focusing on a particular class of agents called BDI (beliefdesire-intention) agents, which have a very powerful reasoning engine but generally consume a lot of computing resources. BDI [24] agents are defined by an internal state that consists of a set of beliefs (information that the agent has about the world), desires (a set of goals), and actions (a set of plans to achieve the goals). The intentions represent the current state of progress of the actions started by the agent, followingsomeplanthathasnotyetbeencompleted.Programming languages such as AgentSpeak(L) [25]providea way of programing BDI agents where beliefs, desires, and intentions are not explicit formulas in the language; instead it uses events, contexts, goals, and actions. In AgentSpeak(L) a plan is generally defined by a rule of the form event: context ←list to do,wherelist to do is a set of actions and/or goals to be achieved by the agent when the event occurs in the specified context.Aneventistriggered when the agent acquires a new goal or detects a change in the environment (i.e., addition or deletion of goals/beliefs). The context specifies the beliefs that must hold when the plan is triggered. As an example of event, consider rule 3 in Reaction Plan 1. This rule says that when an event VAL SOLAR LIGHT(s) istriggeredasresultofsampling the environment, if the event parameter 𝑠is greater than a constant value TH DAY, then the plan body on the right hand side of the arrow executes; otherwise, the plan is discarded for executioninthisstep. Jason [26] provides a simulation framework based on BDI agents and AgentSpeak(L); it implements a metalanguage on top of AgentSpeak(L) and builds an interpreter for this metalanguage. Each agent in Jason behaves as a finite state machine but may also implement additional functions (called 4 International Journal of Distributed Sensor Networks Let 𝑇be the number of times an object must be sensed to consider it present Let 𝑇𝐻 𝐷𝐴𝑌, 𝑇𝐻 𝑉𝑂𝐿𝑇,𝑇𝐻 𝐸𝑁𝑉 be the thresholds for the solar light, energy, and environmental light Let 𝑃𝑟𝑒𝑠𝑒𝑛𝑐𝑒 be the reading of the presence sensor (initially Presence == null) Let 𝑃𝑟𝑒𝑠𝑒𝑛𝑐𝑒𝑆𝑡𝑎𝑏𝑙𝑒 = 𝐹𝑎𝑙𝑠𝑒 be the value to indicate that the value of 𝑃𝑟𝑒𝑠𝑒𝑛𝑐𝑒 is stable or not Let 𝑃𝑟𝑒𝑠𝑒𝑛𝑐𝑒𝐶𝑜𝑢𝑛𝑡𝑒𝑟 = 0 be the number of consecutive times that the presence sensor detects the same value Let 𝑁𝑖𝑔ℎ𝑡𝑡𝑖𝑚𝑒,𝐸𝑛V𝐿𝑖𝑔ℎ𝑡be the reading of the solar and environmental light sensors, respectively %Block A: Local behavior—computation (1) SAMPLING TIMER:←Read(SOLAR LIGHT), Read(ENV LIGHT), Read(LIGHT LAMP), Read(VOLTAGE), Read(PRESENCE SENSOR) (2) VAL SOLAR LIGHT(s):(s≤TH DAY) ←set lamp(HIGH), set nighttime(True) (3) VAL SOLAR LIGHT(s):(s>TH DAY) ←set lamp(OFF), set nighttime(False) % Rules 4–7 detect continuous absence or presence of obstacles for the past 𝑇time intervals (4) VAL PRESENCE(p): (Presence == null) ←set presence(p), set presence stable(False), reset presence counter() (5) VAL PRESENCE(p): (Presence != null) ∧(p != Presence) ←set presence(null) (6) VAL PRESENCE(p): (Presence != null) ∧(p == Presence) ∧(PresenceCounter ≤𝑇)←inc presence counter() (7) VAL PRESENCE(p): (Presence != null) ∧(p == Presence) ∧(PresenceCounter >𝑇)←set presence stable(True) (8) VAL ENV LIGHT(e):←EnvLight = e (9) true: (PresenceStable) ∧(Nighttime) ∧(∼Presence) ←set lamp(LOW) (10) true: (PresenceStable) ∧(Nighttime) ∧(Presence) ∧(EnvLight >TH ENV) ←set lamp(MEDIUM) %Block B: Global behavior—communication (11) SENDING DATA:(Nighttime)←SENSOR MSG(Sender = id sensor, Receiver = id cluster head, sensorMeasurements) (12) CLUSTER SMSG(Msg): (Msg[SolLight] ≤TH DAY) ←set lamp(Msg[ActivityLevel]) (13) CLUSTER QMSG(Query):←SENSOR QMSG(Sender = id sensor, Receiver = Msg[Sender], PresenceStable, ∼Presence) reactionplan 1: Behaviors for data collectors. internal actions). Jason also supports features such as multithreading and a Java-based graphical monitoring tool. Several more recent works have combined sensor networks and agents. These model each sensor node as an agent programmed using an agent-based language. This abstraction enables the sensors to act autonomously and react to the environment. A survey of these simulation tools is presented in [27]. SAMSON [27] is one such tool which provides a framework for WSNs on top of Jason and models every sensor node as an AgentSpeak(L) agent. SAMSON supplies every agent with the radio and energy models of the TMote Sky [28]platform and enables the simulation of sensor nodes that behave as BDI agents. The framework can measure the energy consumption and the number of packets received and transmitted by each sensor node. 4. System Model We consider a WSN consisting of 𝑁sensor nodes. Every node 𝑘(0≤𝑘<𝑁) is provided with a possibly different set of behaviors (or reaction plans)RP 𝑘={𝑃 1 𝑘,𝑃2 𝑘,...,𝑃𝑛 𝑘}.Asensor node usually plays one of the roles of data collector, cluster head, or sink. It is commonly the case that each set of nodes fulfilling the same role implement the same behavior, although different behaviors are allowed. In principle every data collector node is associated with one lamppost; cluster heads and sinks may be deployed in different locations as well as on lampposts. Abehavior𝑃𝑖 𝑘(1 ≤ 𝑖 ≤ 𝑛) is defined by the triple ⟨𝑒𝑖 𝑘, 𝐶𝑖 𝑘,𝐴𝑖𝑘⟩,where𝑒𝑖 𝑘is the triggering event and 𝐶𝑖 𝑘is the set of conditions that must hold for 𝑃𝑖 𝑘to be eligible for execution. When 𝑃𝑖 𝑘is chosen for execution, it will execute the subset of tasks 𝐴𝑖𝑘from the set of all tasks Θ={𝐴0,...,𝐴𝛼}.Themechanismbywhichabehavioriselectedforexecutionbetween many eligible behaviors and the semantics of executing the corresponding set of actions are explained in Section 4.1. During their lifetime the sensor nodes react to changes in their environment and to messages received from other sensor nodes by choosing the best course of action out of the behaviors defined by RP𝑘. At configuration time, every node 𝑘is assigned an initial behavior 𝑃0 𝑘=⟨𝑒 0 𝑘,𝐶0 𝑘,𝐴0 𝑘⟩. Even if the sensor lifetime is an important issue—one which we have already addressed in [29,30]—our purpose in this paper is to minimize the energy waste of the lighting system as provided by the lampposts. Since data collector nodes are attached to the lampposts, they can be directly powered from the power grid. Additionally, the energy required to power on the sensors is typically much lower than the energy required to power up the lampposts; we have therefore disregarded this aspect in the paper and we focus exclusively on the management of the lampposts. 4.1. The Execution Semantics. The execution of any task in 𝐴𝑖𝑘 can generate a set of internal events. Consider for instance a task that measures the light emitted by a sensor node. Since thelatencyofthehardwarewhenperformingthisoperation cannot be neglected, there is a lapse of time between the instant when the operation is started and when it ends. When the operation finishes the hardware generates an internal event (e.g., lightDone()) to announce that the data is available. A sensor node may also observe external events which are generated by the environment rather than being a result of International Journal of Distributed Sensor Networks 5 the execution of some of its tasks. Examples of external events are the reception of a message from another sensor node, an alarmthatgoesoffwhenavalueexceedssomethreshold,and so on. Both internal and external events that occur in a node 𝑘 may have the role of a triggering event for some behavior. External events are enqueued in the event queue 𝐸𝑘[] in the order in which they occur. Meanwhile, a newly generated internal event will be processed immediately. We can think of an internal event as being conceptually processed as part of processing the external event whose associated task generated it. Our simulations execute on top of a language based on AgentSpeak(L) and therefore adopts its execution semantics. When an event is observed, every behavior 𝑃𝑖 𝑘triggered by this event must evaluate its triggering condition 𝐶𝑖 𝑘.Ifthe condition evaluates to false, 𝑃𝑖 𝑘is discarded as a candidate forexecution;otherwise,itbecomeseligible.AgentSpeak(L) implements a selection function 𝑆𝑂which chooses one of the eligible behaviors for execution. The lifetime of a sensor node is discretized in reasoning cycles of a given duration. This duration is chosen to be the maximum of the worst-case estimated times that it takes for the node to process the external events (which it recognizes) to quiescence. Given that this time depends on the set of behaviors implemented by each sensor node, the reasoning cycle may have a different value for each node. Algorithm 1 describes the infinite reaction loop which is executed locally and independently on each sensor node. Every (local) reasoning cycle the sensor node removes an external event from its event queue 𝐸𝑘[] by using the AgentSpeak(L) operator 𝑆𝐸; then it chooses the next behavior to execute by using the operator 𝑆𝑂over the set of eligible behaviors. Remember that executing an action 𝐴𝑗 𝑘may generate (a set of) internal events {𝑖𝑒}. These are processed as part of the execution of the external event rather than being queued explicitly. The last line of Algorithm 1 (Execute 𝐴𝑗 𝑘) may therefore include the execution of additional sets of tasks corresponding to behaviorstriggeredbytheeventsin{𝑖𝑒}. The reason we can only compute an approximation of the event processing time is that we cannot know for sure which other behaviors will be executed as a result of tasks generating internal events. For instance, events are allowed to have parameters and the triggering condition may depend on the values taken by these parameters. If a value passed as a parametertoaninternaleventcanbewrittenbythebehavior which generated the internal event, we cannot know in advance which behavior this will trigger if any. Conditional generation of internal events is another case in which the set of behaviors executed as part of processing an external event is not known at static time. 4.2. Energy Estimation. Every behavior 𝑃𝑖 𝑘has a cost 𝑊𝑖 𝑘 which depends on the energy cost per unit of time, and that canbeexpressedas 𝑊𝑖 𝑘=∑ 𝑗=1⋅⋅⋅𝐴𝑖𝑘 𝑉×𝑡 𝑗×𝐼 𝑗,(1) Let RP𝑘be the set of behaviors defined for node 𝑘 loop 𝑗=𝑆 𝐸(𝐸𝑘[]) // Select some event in 𝐸𝑘[] for all 𝑃𝑖 𝑘=⟨𝑒 𝑖 𝑘,𝐶𝑖 𝑘,𝐴𝑖𝑘⟩in RP𝑘s.t. 𝑗==𝑒 𝑖 𝑘do holds = true for all 𝑐∈𝐶 𝑖 𝑘do if eval(𝑐) == false then holds = false if holds == true then Insert 𝑖in Eligible𝑘 𝑃𝑗 𝑘=𝑆 𝑂(Eligible𝑘) Execute 𝐴𝑗 𝑘 Algorithm 1: Adaptation algorithm. where 𝑡𝑗is the execution time for task 𝑗∈𝐴 𝑖𝑘,𝑉is the voltage required by the device to work properly, and 𝐼𝑗is the current draw required to execute this task. As we explained in the previous section, the processing of an external event to completion may result in the processing of additional internal events. The estimation of the energy it takes to execute the entire set of behaviors triggered by an external event is therefore a worst-case estimation, just like the calculation of the reasoning cycle time. 5. Application for Smart Lighting We consider a WSN composed of 𝑁sensor nodes that execute an adaptive application which models a smart lighting system using the approach described in Section 4.TheWSNis deployed on a street with lampposts emitting variable light intensity. The sensor nodes may take one of three roles: (1) data collectors which are attached to lampposts and have a fixed position, (2)cluster heads which are deployed in strategic positions within the WSN to facilitate the grouping of several sensors for fault-tolerance, forwarding, or aggregation purposes, and (3) the sink which is the target sensor node which collects all the data from the WSN. Data collectors are equipped with five transducers: LIGHT LAMP for the intensity of the light generated by the lamppost, ENV LIGHT for the intensity of the light in the environment, SOLAR LIGHT for perceiving solar light, PRESENCE SENSOR to detect the presence of obstacles in the environment, and VOLTAGE to measure the remaining battery voltage. Each data collector is also equipped with an actuator ACT LAMP which may be used to regulatetheintensityofthelightemittedbythelamppost.The cluster heads only have the transducer VOLTAGE. Alamppostcanbeinoneoffourstates:OFF,LOW,MEDIUM, and HIGH. Our smart lighting application allows for adjusting the level of light according to a series of conditions which we describe below. The energy consumption of a lamppost is proportional to the intensity of the light it produces. The goal of this application is to reduce the global energy consumption for street lighting while providing an adequate degree of service. 6 International Journal of Distributed Sensor Networks 5.1. Specifying Behavior by means of Rules. In our system, the sensor nodes (data collectors, cluster heads, and the sink) executewhatwecallareactionplan.Thenameismeant to capture the idea that our approach is best suited for specifying reactive systems. If the behavior of two sensor nodes is different (be they of different types—such as data collectors,clusterheads,andsink—orofthesametype)then their reaction plans are also different. In general all nodes of thesametypewillhavethesamebehavior;thedeveloperwill only have to specify three reaction plans, one per type. Different from the traditional syntax used to implement algorithms for sensor nodes, we adopt a rule-based language. Each behavior included in the reaction plan is represented as a rule with a triggering event (possibly parameterized), a context, and a body. The body is the only component of the rule which is not optional. We use a similar notation to that of AgentSpeak(L), which was already introduced in Section 3: [event] ([parameters]): [context] ←body, where event can be both an internal or an external event, context is the set of conditions that must hold for the rule to be executable, and body specifies the actions to be executed. The execution semantics that we use was described in Section 4.1. The choice of a specification approach based on rules is an important decision. While a specification using imperative if-then-else constructs may traditionally be more common, it is not equivalent to a set of rules. First, rules are triggered by events and therefore naturally specify reactive behavior such as that of WSNs. The condition of an if-then-else construct is evaluated only when the code is explicitly invoked. To find the behavior that will apply the execution must evaluate all if-then-else conditions that textually precede it. No freedom is allowed to choose between multiple behaviors that would be eligible in a rule-based specification. Once passed the somewhat unfamiliar syntax, the developer will find that composition of behavior is considerably easier in our approach because it is implicitly done by the compiler or the runtime system. This approach does not involve extraneous code compared to other approaches that use more traditional specification languages. It is important to note that our syntax does not distinguish computation from communication. Communication between sensor nodes is done by generating and consuming external events. From the point of view of the specification, it is irrelevant whether event triggering is due to sensing a change in the local environment or a message received from another node. This feature simplifies the language and makes applications conceptually more uniform and easy to modify and reuse. It is the decision of the developer whether the reaction plans implement global behaviors that are distributed or centralized; coordination and synchronization between nodes are achieved by generating external events and appropriately setting the values of their parameters. We use different fonts to represent different elements during the explanation of the three reaction plans. We use typewriter font to indicate the names of transducers and italic font to represent both variables and events. 5.2. Reaction Plans. Reaction Plans 1,2,and3describe the set of behaviors implemented by the data collector, cluster head, and sink type nodes in our WSN. Data Collector Nodes. The reaction plan for this type of nodes is specified in Reaction Plan 1.Ascomponentsofadata collector node, the SOLAR LIGHT,ENV LIGHT, and PRESENCE SENSOR transducers generate the events VAL SOLAR LIGHT, VAL ENV LIGHT,and VAL PRESENCE; we do not explicitly show how this happens but rather assume that the environment produces them. Additionally, the periodic external events SAMPLING TIMER and SENDING DATA are generated by two timers. Note that local/global refers to physical location, whereas internal/ external refers to whether an event was produced by an executing task with the intention of being processed immediately or whether this was produced by the environment external to the executing application to be queued and processed at some point in the future. SENDING DATA triggers an external event SENSOR MSG(m) which is processed by the corresponding cluster head, and it therefore specifies global, internode behavior (one can think of this as a communication component of the application). The rest of the events trigger purely local behavior. The data collector nodes also implement internode communication behavior as a reaction to receiving messages from the corresponding cluster heads; we consider the receipt of a message to be an external event. The rules that control the intensity of the light emitted by a lamppost are described next. During daytime conditions the lamppost is turned off; at nighttime, the lamppost is turned on either LOW,MEDIUM,orHIGH, depending on a series of conditions. The value of a sample taken by the SOLAR LIGHT transducer indicates whether the light conditions are those of daytime or nighttime depending on whether this value is above TH DAY.Thisvalueispassedas a parameter to the VAL SOLAR LIGHT event, which is generated when the measurement is done. For instance, rule 2ofReaction Plan 1 reads as follows: when the external event VAL SOLAR LIGHT(s) isobservedbyadatacollectornode, if the value of the event parameter 𝑠is not greater than a fixed threshold TH DAY, then the node sets the actuator ACT LAMP such that the lamppost produces light with HIGH intensity andadditionallysetsthelocalvariable Nighttime to True. When a lamppost is turned on its level of intensity is set by default to HIGH. We can always set multiple finer thresholds to distinguish between different time frames (e.g., sunrise to noon and noon to sunset). We configure a data collector 𝑘to wake up every sampling time period and sample each one of its five transducers; rule 1implementsthisbehavior.Tobeprecise,thedatacollector does not necessarily sample its environment at equal time intervals. SAMPLING TIMER events are periodically generated and queued. As we described in the previous section, there may be multiple events in the queue, and the processing of an event may be delayed until after the processing of other previously queued events. At nighttime, periodic SENDING DATA events trigger the sending of a message containing the sampled data values to the corresponding cluster head; rule 11 describes this International Journal of Distributed Sensor Networks 7 Let DC be the number of data collectors within a cluster dominated by the cluster head Let 𝑇𝐻 𝑉𝑂𝐿𝑇 bethethresholdvaluefortheenergysensor Let 𝐷𝐶𝐶𝑜𝑢𝑛𝑡𝑒𝑟 = 0 be the number of different data collectors within a cluster that sent a message with their readings Let 𝑁𝑜𝑃𝑟𝑒𝑠𝑒𝑛𝑐𝑒𝐶𝑜𝑢𝑛𝑡𝑒𝑟 = 0 be the number of different data collectors within a cluster that did not detect presence Let 𝑉𝑜𝑙𝑡𝑎𝑔𝑒 be the reading of the energy sensor Let 𝐷𝑎𝑡𝑎𝐶𝑜𝑙𝑙𝑒𝑐𝑡𝑜𝑟𝑉𝑒𝑐𝑡𝑜𝑟[] be a vector that contains the identifiers of DC data collectors Let 𝑃𝑟𝑒𝑠𝑒𝑛𝑐𝑒𝑉𝑒𝑐𝑡𝑜𝑟[] be a vector that contains the values of valid presence detected for DC data collectors %Block A: Local behavior—computation (1) SAMPLING TIMER:←Read(VOLTAGE) (2) VAL VOLTAGE(v):←Voltage = V %Block B: Global behavior—communication (3) CLUSTER MSG(Msg):←CLUSTER MSG(Msg) % Rule 4 forwards each received message from the data collectors to the sink and queries the data collectors for information about the continuous presence/absence of objects (4) SENSOR MSG(Msg): (Msg[Voltage] >TH VOLT) ←set presence vector(null), reset nopresence counter(), CLUSTER QMSG n(DC, Sender = id cluster head, Receiver = DataCollectorVector[i]), CLUSTER MSG(Sender = Msg[Sender], Receiver = id sink, ParametersOfMsg(Msg)) % Rule 5 accumulates the values of the readings from DC data collectors in local variables (5) SENSOR MSG(Msg): (Msg[Voltage] ≤TH VOLT) ∧(DCCounter <DC) ←inc dc counter(), computeAggregate(Msg) % Rule 6 computes the averages over all received values and sends the results as a unique message to the sink (6) SENSOR MSG(Msg): (Msg[Voltage] ≤TH VOLT) ∧(DCCounter==DC) ←reset dc counter(), CLUSTER MSG(Sender = Msg[Sender], Receiver = id sink, computeAverages) % Rule 7 receives the information about the continuous presence/absence of objects from those collectors which have not already sent this information (7) SENSOR QMSG(Msg): (Msg[Sender]==DataCollectorVector[j]) ∧(PresenceVector[j]==null) ← inc nopresence counter(), PresenceVector[j] = Msg[Presence], computeProducts(Msg) % Rule 8 is executed when DC data collectors detected stable absence; it turns off odd numbered lampposts and it turns LOW the rest (8) true: (NoPresenceCounter == DCCounter) ∧(ProdPresence == 1) ∧(ProdPresenceStable == 1)← CLUSTER SMSG n(floor(DC/2), sendMessageEvenCollectors(LOW)), CLUSTER SMSG n(floor(DC/2)-1, sendMessageOddCollectors(OFF)) (9) SENDING DATA:←SINK MSG(Sender = id cluster head, Receiver = id sink, Voltage) reactionplan 2: Behaviors for cluster heads. Let 𝑇𝐻 𝑉𝑂𝐿𝑇 be the threshold value for the energy sensor (1) CLUSTER MSG(Msg): (Msg[Voltage] ≤TH VOLT) ←Save(Msg), Print(“Alert for battery in”, Msg[Sender]) (2) CLUSTER MSG(Msg): (Msg[Voltage] >TH VOLT) ←Save(Msg) (3) SINK MSG(Msg): (Msg[Voltage] ≤TH VOLT) ←Save(Msg), Print(“Alert for battery in”, Msg[Sender]) (4) SINK MSG(Msg): (Msg[Voltage] >TH VOLT) ←Save(Msg) reactionplan 3: Behaviors for the sink. behavior. Sending the information occurs via the only available mechanism: generating the corresponding event. In this case the event SENSOR MSG contains several parameters; theidofthedatacollectornodeisspecifiedasthesenderand the corresponding cluster head as the receiver. Values measured by the transducers and local variable values follow in a predefined order; for the sake of readability we use a made-up variable name (sensorMeasurements)tostandforVoltage, EnvLight,Nighttime,PresenceStable,Presence,and LightLamp. Lines 4–10 describe behavior rules which modify the intensity level of a lamppost at nighttime depending on the actual conditions at the site, specifically the detection of objects (or their absence) over a certain extent of time. PRESENCE SENSOR returns 1 if an object is detected and 0 otherwise. If no object is detected for a number 𝑇of consecutive sampling periods we downgrade the intensity level to LOW.WechoosetoneverturnOFF a whole section of lampposts at nighttime to avoid a negative social impact on pedestrians—which may choose to altogether avoid an apparently dark street. The variable PresenceStable indicates if the value of Presence returned by PRESENCE SENSOR is stable; that is, all sensor readings over the last 𝑇consecutive sampling periods returned the same value, in which case PresenceStable takes the value True (see rule 7). If two consecutive readings of PRESENCE SENSOR have a different value, 8 International Journal of Distributed Sensor Networks Off High Low Medium Nighttime Daytime Daytime Presence && Presence && Daytime Presence && Presence && ∼presence ∼presence Env.Light >MIN Env.Light ≤MIN Env.Light ≤MIN Env.Light >MIN Figure 1: Transition diagram for the light intensity states. rule 5 resets the variable Presence to null.Otherwise,rule6 increments the variable PresenceCounter amaximumnumber of 𝑇times. If some object is detected continuously over the past 𝑇time samples and the environment light is above a certain threshold then the data collector node downgrades the intensity level to MEDIUM,asshowninrule10.Thecontinuous presence of an object is detected if PresenceStable has value True and the last reading was positive; that is, Presence has value 1. If no presence is detected for the past 𝑇time samples (PresenceStable is True and Presence is 0), then the data collector node downgrades the intensity level to LOW,as showninrule9.Figure 1 summarizes the transitions among different light intensity states for a lamppost. The states in the figure are labeled with the level of light intensity: OFF,HIGH, MEDIUM,andLOW; the labels on the arrows represent the conditions that must hold to transition from a state to another. To simplify the conditions, the variable Presence used in the figure means that presence was detected and it is also stable. To avoid excessive cluttering we do not show the self-loops corresponding to each state. Lastly, a data collector may receive messages from its cluster head. In rule 12 the external event CLUSTER SMSG (Msg) triggers an action which sets the activity level of the lamppost to the value indicated by the cluster head. Specifically,therulereadsasfollows:whena CLUSTER SMSG event with parameter Msg is processed, if the value of the field named SolLight of Msg is below the fixed threshold then the actuator ACT LAMP is set to take the value passed in the field ActivityLevel of Msg.Inrule13aneventoftype CLUSTER QMSG prompts the data collector to send information about the continuous (aka stable) presence (or absence) of an object to the cluster head. This information is necessary to implement a cluster head policy which involves turning off subsets of lampposts. The data collector therefore needs to send two pieces of information: PresenceStable to capture stability of observation and Presence to reflect whether stability over the past 𝑇timeintervalsrepresentspresence or absence of an object. In Reaction Plan 2 it will become apparent why the data collector sends as the fourth parameter the negated value of Presence. Cluster Head Nodes. Reaction Plan 2 describes the set of behaviors implemented by a cluster head. A sensor node 𝑗 acting as a cluster head (𝑗 =𝑘)is configured to sample its battery level every sampling interval (rule 1) and send it to the sink every sending interval by generating an external event (rule 9) for energy management purposes. When a message from one of its data collector is received (via the parameter of the SENSOR MSG event) the cluster head checks the collector’s voltage level. If this is greater than a certain threshold (TH VOLT)thenrule4isselectedto execute; otherwise, rules 5 or 6 are selected. By generating the external CLUSTER MSG event, rule 4 forwards the values it receives in the event parameter to the sink—if the battery level is above a given threshold. Notice that the sender field is set to the original data collector which is stored in Msg[Sender], such that the sink may know the identity of the originating node for the transducer values. For legibility purposes we use the notation ParametersOfMsg (Msg) to stand for Voltage = Msg[Voltage],EnvLight = Msg[EnvLight],SolLight =Msg[SolLight], PresenceStable =Msg[PresenceStable],Presence = Msg[Presence],andLightLamp =Msg[LightLamp].This rulealsogenerateseventsforthedatacollectorswhichrequest the values of the PresenceStable and Presence bits. Messages received from other cluster heads (via the CLUSTER MSG event in rule 3) are simply forwarded regardless of the battery level; this implements the multihop message routing protocol. If the cluster head receives values from the data collectors but its battery level is below the predefined threshold TH VOLT then the node switches from forwarding every message received to an aggregator behavior. Rules 5-6 describe the process by which the cluster head aggregates the data proceeding from the last DC samples sent by data collectors in a unique message and forwards it to the sink. 𝐷𝐶𝐶𝑜𝑢𝑛𝑡𝑒𝑟is initially set to 0. To keep the example legible we aggregate DC readings regardless of whether they come from different DC data collectors or not (we assume that DC is the number of the data collectors that the cluster head is responsible for). By sending one single message instead of forwarding every one of them, the cluster head saves energy. We use the function computeAggregate (Msg) to stand for add (SumVoltage,Msg[Voltage]), add (SumLightLamp,Msg[LightLamp]),add (SumSolarLight,Msg[SolLight]),add (SumEnvLight, International Journal of Distributed Sensor Networks 9 Msg[EnvLight]),mul (ProdPresenceStable, Msg[PresenceStable]),andmul (ProdPresence, Msg[Presence]),whereadd(x,y) means x=x+y and mul(x,y) means x=x∗y. Similarly, for legibility purposes we use the notation computeAverages in rule 6 to stand for Voltage =SumVoltage/N,EnvLight =SumEnvLight/N, SolLight =SumSolarLight/N,ProdPresenceStable, ProdPresence,andLightLamp =SumLightLamp/N. Inrule7,thepresenceinformationsentbythedata collectors(asresultoftherequestbytheclusterheadinrule4) is received as the parameter of event SENSOR QMSG.The rule collects the inverse of the values measured by the PRESENCE SENSOR transducer of each lamppost in the cluster; it also collects the PresenceStable values. The function computeProducts (Msg) stands for mul (ProdPresence, Msg[Presence]),mul (ProdPresenceStable, Msg[PresenceStable]) and computes the values for the local variables ProdPresence and ProdPresenceStable.The triggering condition of the behavior in rule 7 reads as follows: for the data collector which corresponds to the sender of the SENSOR QMSG event, check whether its corresponding PresenceVector[j] is null. This condition is true whenever no previous SENSOR QMSG event has been received from this data collector in this counting round. DataCollectorVector and PresenceVector aretwovectorslocaltothecluster head, of size equal to DC.DataCollectorVector[i] and PresenceVector[i] contain the identifier and the value of the presence bit for the 𝑖th data collector (PresenceVector[i] is initialized to null in rule 4 by the function set presence vector(null)). In rule 8, if DC different collectors detect stable absence of objects then the cluster head generates an event for every other data collector that it is responsible for, such that these turn their light OFF;therestofthelightsturndowntoLOW. The rule condition reads as follows: NoPresenceCounter == DC tests DC different collectors because rule 7 only triggers when PresenceVector[j] has not been previously set; that is, it only considers distinct collectors; ProdPresenceStable == 1 tests whether all readings were stable; ProdPresence == 1 tests whether all negated values of the presence sensor are 1; thatis,allvaluesofthesesensorsare0.Wedecidedto exchange the inverse values of the presence values (instead of the values themselves) to efficiently implement the test that every value returned is zero, that is, to implement the test that the stable condition captures absence, rather than presence, of an object. Rules 4 and 8 use functions with the notation 𝑒V𝑒𝑛𝑡𝑛𝑎𝑚𝑒 𝑛(ℎ,𝑝𝑎𝑟𝑎𝑚𝑒𝑡𝑒𝑟𝑠) as syntactic sugar for the generation of ℎevents 𝑒V𝑒𝑛𝑡𝑛𝑎𝑚𝑒.Forinstance,inrule4,a number (DC)of CLUSTER QMSG events are generated, one for each data collector 𝑖(0≤𝑖<𝐷𝐶). Rule 8 generates floor (DC/2) CLUSTER SMSG events for the even numbered data collector nodes and floor (DC/2)-1 CLUSTER SMSG events for the odd numbered nodes. For legibility purposes we use the function sendMessageEvenCollectors (LOW) that stands for the parameters (Sender = id cluster head,Receiver = DataCollectorVector[2⋆i],andActivityLevel = LOW) and sendMessageOddCollectors (OFF) that stands for the parameters (Sender =id cluster head,Receiver =DataCollectorVector[2⋆i+1],andActivityLevel = OFF).Thealgorithmworksundertheassumptionthatconsecutively placed lampposts are numbered sequentially suchthatnolargecontiguousregionisturnedOFF at the same time. If another pattern is sought to choose the lampposts thatstayon,thismustbereflectedinthewaythatrule8 selects this set. Sink Node. The reaction plan for this type of nodes is specified in Reaction Plan 3. The sink receives messages from the cluster heads and saves the message data. If the battery level is below TH VOLT then the sink additionally prints an alert message. These messages may be of one of two types: CLUSTER MSG—initiated at a data collector node and containing all the measurements—or SINK MSG—initiated at a cluster head and containing only the energy measurement (since this is the only transducer available in a cluster head). 5.3. Complexity. The reaction plans that we are proposing use a set of rules to detect changes in the environment (including the events produced by other sensor nodes). While no change has been detected, none of the rules in the reacting plan can trigger. Detecting a change is represented by the processing of an event. When an event is processed it triggers the execution of a rule, which may in turn trigger other rules, either by generating internal events or by enabling rules with no triggering event. The processing of the event is considered finished when there are no more rules that can trigger in the current timestep. The key is that all of the rules that execute during a timestep are evaluated for execution in the state at the beginning of the timestep and they may not see the data changes produced by the others. This ensures convergence. Additionally, in every timestep the maximum number of rules which may execute is given by adding 1 to the sum of thenumberofrulestriggeredbyinternaleventsandthenumber of rules with no triggering event. This gives the worstcase complexity of the algorithm in terms of the number of executing rules per timestep. In practice we expect this number to be very small. 5.4. Distributed Decision Model. To support the autonomous decision making process of each sensor node our approach follows a fully distributed communication model at two levels: local and collective. Local decisions are made based only on the information available in the sensor node while collective decisions require information interchange among the nodes that are involved in the decision. For instance, a data collector decides by itself (i.e., locally) what is the most appropriatelightstatefortheassociatedlamppostbasedonits surroundings (see rules 2-3 and 9-10 in Reaction Plan 1). Similarly, a cluster head decides if it should reduce the light level of the lampposts within the cluster based on the information sent from the data collectors (see rule 8 in Reaction Plan 2). Each node fulfills its role by reacting to events in its locally defined manner. While cluster nodes may have the power of authority to modify the light levels of the data collector nodes under its management, the data 16 International Journal of Distributed Sensor Networks L1L3L5L7L9L11 L13 L15 Lamppost Residual voltage 3.0 2.5 2.0 1.5 1.0 0.5 0.0 Voltage (V) (a) L1L3L5L7L9L11 L13 L15 Lamppost 1200 1000 800 600 400 200 Number of packets Number of Tx Number of Rx (b) Figure 12: Residual voltage after simulation (a) and number of packets transmitted and received (b) per lamppost in the city of Legan´ es. Table 2: Estimation of the energy costs per lamppost, overnight and per year, for the city of Legan´ es. State Rated power (W) Average time per hour Adaptive application Nonadaptive application Power per hour (W) Cost per night (C) Power hour (W) Cost per night (C) High 240 0.22 53.33 0.079 240 0.36 Medium 120 0.14 16.38 0.024 0 0 Low 60 0.64 38.49 0.057 0 0 Total lamppost/night (C) 0.162 0.36 Total lamppost/year (C)59.13 131.4 adaptivebehaviorofthedevices.Wealsoplantoincludemore sophisticated algorithms which conserve sensor energy along with street light energy. Conflict of Interests The authors declare that he has no conflict of interests regarding the publication of this paper. Acknowledgment This work has been funded by the Spanish Ministry of Science and Technology under the Grant TIN2010-16497 “T´ ecnicas Escalables de E/S en Entornos Distribuidos y de Computaci´ on de Altas Prestaciones.” References [1] G. S. Dutt, “Illumination and sustainable development. Part I: technology and economics,” Energy for Sustainable Development,vol.1,no.1,pp.23–35,1994. [2] M. Stockman, “Light-emitting devices: from nano-optics to street lights,” Nature Materials,vol.3,no.7,pp.423–424,2004. [3] W. Murff and Kuntz, “Winter 2011: sustainable cities: Salem street lights,” City of Salem, February 2012, http://www .cityofsalem.net/Residents/Sustainable-Salem/SCI/Documents/ StreetLights/Group1 Book.pdf. [4] P. Leonard, “Memorandum: street lights,” City of Dublin, February 2010, http://www.upperdublin.net/information/sustainable/streetlights.aspx. [5] L.Martirano,“Asmartlightingcontroltosaveenergy,”inProceedings of the 6th IEEE International Conference on Intelligent Data Acquisition and Advanced Computing Systems (IDAACS ’11), vol. 1, pp. 132–138, September 2011. [6] P. Elejoste, I. Angulo, A. Perallos et al., “An easy to deploy street light control system based on wireless communication and led technology,” Sensors,vol.13,no.5,pp.6492–6523,2013. [7] T.P.Huynh,Y.K.Tan,andK.J.Tseng,“Energy-awarewireless sensor network with ambient intelligence for smart LED lighting system control,” in Proceedings of the 37th Annual Conference of the IEEE Industrial Electronics Society (IECON ’11),pp. 2923–2928, November 2011. [8] X. Cao, J. Chen, Y. Xiao, and Y. Sun, “Building-environment control with wireless sensor and actuator networks: centralized versus distributed,” IEEE Transactions on Industrial Electronics, vol. 57, no. 11, pp. 3596–3605, 2010. [9] J. S. Sandhu, “Wireless sensor networks for commercial lighting control: decision making with multi-agent systems,” in Proceedings of the AAAI Workshop on Sensor Networks,pp.131–140, 2004. [10] Y.Wu,C.Shi,X.Zhang,andW.Yang,“Designofnewintelligent street light control system,” in Proceedings of the 8th IEEE International Conference on Control and Automation (ICCA ’10), pp. 1423–1427, June 2010. International Journal of Distributed Sensor Networks 17 [11] L. Y. X. Jun and P. Yonglong, “Study of energy-saving solar street light using led based on mcu-controlled,” Test & Measurement Technology, no. 10, pp. 29–31, 2008. [12] IERC—Internet of Things, “The Internet of Things 2012—New Horizons,” 2012, http://www.internet-of-things-research.eu/ pdf/IERC Cluster Book 2012 WEB.pdf. [13] M. Weiser, “The computer for the 21st century,” in HumanComputer Interaction, R. M. Baecker, J. Grudin, W. A. S. Buxton, andS.Greenberg,Eds.,pp.933–940,MorganKaufmann,San Francisco, Calif, USA, 1995. [14] R. K. Bose and G. Anandalingam, “Sustainable urban energyenvironment management with multiple objectives,” Energy, vol. 21, no. 4, pp. 305–318, 1996. [15] E.K.Zavadskas,A.Kaklauskas,andJ.Kaklauskiene,“Modelling and forecasting of a rational and sustainable development of Vilnius: emphasis on pollution,” International Journal of Environment and Pollution,vol.30,no.3-4,pp.485–500,2007. [16] Y. R. Jabareen, “Sustainable urban forms: their typologies, models, and concepts,” Journal of Planning Education and Research,vol.26,no.1,pp.38–52,2006. [17] M. Vinyals, J. A. Rodriguez-Aguilar, and J. Cerquides, “A survey on sensor networks from a multiagent perspective,” The Computer Journal,vol.54,no.3,pp.455–470,2011. [18] J. O. Kephart and D. M. Chess, “The vision of autonomic computing,” Computer,vol.36,no.1,pp.4–50,2003. [19] K. Schneider, T. Schuele, and M. Trapp, “Verifying the adaptation behavior of embedded systems,” in Proceedings of the InternationalWorkshoponSelf-AdaptationandSelf-Managing Systems (SEAMS ’06),pp.16–22,ACM,2006. [20] K. Hazelwood, “Process-level virtualization for runtime adaptation of embedded software,” in Proceedings of the 48th Design Automation Conference (DAC ’11), pp. 895–900, ACM, 2011. [21] J. C´ amara, G. Sala¨ un, C. Canal, and M. Ouederni, “Interactive specification and verification of behavioral adaptation contracts,” Information and Software Technology,vol.54,no.7,pp. 701–723, 2012. [22] F. Fleurey, B. Morin, and A. Solberg, “A model-driven approach to develop adaptive firmwares,” in Proceedings of the 6th InternationalSymposiumonSoftwareEngineeringforAdaptiveand Self-Managing Systems (SEAMS ’11), pp. 168–177, ACM, 2011. [23] N. R. Jennings, “On agent-based software engineering,” Artificial Intelligence,vol.117,no.2,pp.277–296,2000. [24] A. S. Rao and M. P. Georgeff, “Bdi agents: from theory to practice,” in Proceedings of the 1st International Conference on Multiagent Systems (ICMAS ’95), pp. 312–319, 1995. [25] A. S. Rao, “AgentSpeak(L): BDI agents speak out in a logical computable language,” in Proceedings of the 7th European Workshop on Modelling Autonomous Agents in a Multi-Agent World (MAAMAW ’96), pp. 42–55, Springer, Eindhoven, The Netherlands, January 1996. [26] R. H. Bordini and J. F. Hbner, “Bdi agent programming in agentspeak using jason,” in Proceedings of the 6th International Workshop on Computational Logic for Multi-Agent Systems (CLIMA VI ’05),vol.3900ofLecture Notes in Computer Science,pp.143– 164, Springer, 2005. [27] A. Morris, SAMSON: strong multi-agent simulation of wireless sensor networks [Ph.D. dissertation], University College Dublin, Dublin, Ireland, 2008. [28] M. Corporation, “Tmote sky. Low Power Wireless Sensor Module,” 2006, http://www.eecs.harvard.edu/∼konrad/projects/shimmer/references/tmote-sky-datasheet.pdf. [29] S. Escolar, S. Chessa, J. Carretero, and M. C. Marinescu, “Cross layer adaptation of check intervals in low power listening mac protocols for lifetime improvement in wireless sensor networks,” Sensors,vol.12,no.8,pp.511–510,2012. [30] S. Escolar, S. Chessa, and J. Carretero, “Energy management in solar cells powered wireless sensor networks for quality of service optimization,” Personal and Ubiquitous Computing, 2013. [31] B. B. Earth, “Ls led street lights—ls8,” June 2013, http://www .bbeled.com/downloads/ls8-spec-vo.pdf. International Journal of Aerospace Engineering Hindawi Publishing Corporation http://www.hindawi.com Volume 2014 Robotics Journal of Hindawi Publishing Corporation http://www.hindawi.com Volume 2014 Hindawi Publishing Corporation http://www.hindawi.com Volume 2014 Active and Passive Electronic Components Control Science and Engineering Journal of Hindawi Publishing Corporation http://www.hindawi.com Volume 2014 International Journal of Rotating Machinery Hindawi Publishing Corporation http://www.hindawi.com Volume 2014 Hindawi Publishing Corporation http://www.hindawi.com Journal of Engineering Volume 2014 Submit your manuscripts at http://www.hindawi.com VLSI Design Hindawi Publishing Corporation http://www.hindawi.com Volume 2014 Hindawi Publishing Corporation http://www.hindawi.com Volume 2014 Shock and Vibration Hindawi Publishing Corporation http://www.hindawi.com Volume 2014 Civil Engineering Advances in Acoustics and Vibration Advances in Hindawi Publishing Corporation http://www.hindawi.com Volume 2014 Hindawi Publishing Corporation http://www.hindawi.com Volume 2014 Electrical and Computer Engineering Journal of Advances in OptoElectronics Hindawi Publishing Corporation http://www.hindawi.com Volume 2014 The Scientific World Journal Hindawi Publishing Corporation http://www.hindawi.com Volume 2014 Sensors Journal of Hindawi Publishing Corporation http://www.hindawi.com Volume 2014 Modelling & Simulation in Engineering Hindawi Publishing Corporation http://www.hindawi.com Volume 2014 Hindawi Publishing Corporation http://www.hindawi.com Volume 2014 Chemical Engineering International Journal of Antennas and Propagation International Journal of Hindawi Publishing Corporation http://www.hindawi.com Volume 2014 Hindawi Publishing Corporation http://www.hindawi.com Volume 2014 Navigation and Observation International Journal of Hindawi Publishing Corporation http://www.hindawi.com Volume 2014 Distributed Sensor Networks International Journal of