Declarative Interface for In-network Actuation on Wireless - - PowerPoint PPT Presentation

declarative interface for in network actuation on
SMART_READER_LITE
LIVE PREVIEW

Declarative Interface for In-network Actuation on Wireless - - PowerPoint PPT Presentation

Declarative Interface for In-network Actuation on Wireless Sensor-Actuator Networks Asanka Sayakkara M.D.J.S Goonetillake Kasun De Zoysa Sustainable Computing Research Group (SCoRe), University of Colombo School of Computing, Sri Lanka.


slide-1
SLIDE 1

Declarative Interface for In-network Actuation on Wireless Sensor-Actuator Networks

Asanka Sayakkara M.D.J.S Goonetillake Kasun De Zoysa

Sustainable Computing Research Group (SCoRe), University of Colombo School of Computing, Sri Lanka.

slide-2
SLIDE 2

Outline

  • Wireless sensor networks (WSN)
  • Database abstraction for WSN
  • Cougar and TinyDB
  • Wireless sensor actuator networks (WSAN)
  • TinyDB for WSAN
  • Greenhouse scenario
  • Issues in declarative interface for WSAN
  • Solution approach
  • Evaluation
  • Discussion
  • Conclusion
slide-3
SLIDE 3

Wireless Sensor Networks (WSN)

  • Low powered devices.
  • Wireless communication.
  • Limited computing resources.
  • Built-in sensors.
slide-4
SLIDE 4

Database Abstraction for WSN

  • Hides the complex network details and provide a familiar

interface.

slide-5
SLIDE 5

Cougar and TinyDB

  • Cougar from Cornell University

➔ The pioneering work in the domain. ➔ In network query processing

  • TinyDB as a joint work from MIT, UCB and Intel Research

➔ First successful implementation. ➔ Widely used in real world applications

SELECT nodeid, light FROM sensors SAMPLE PERIOD 1 FOR 10;

Specify Data Sampling Rate

slide-6
SLIDE 6

Wireless Sensor Actuator Networks (WSAN)

  • Having just sensors in the network is not enough.
  • New requirements for controlling the deployed environment in

addition to monitoring.

  • Actuators are attached to the nodes in a network.
  • Some nodes may have just sensors, some may have just

actuators and some may carry both sensors and actuators.

slide-7
SLIDE 7

TinyDB for WSAN

  • Special keywords to specify which action should be performed.
  • Calls to low level system functions.

SELECT nodeid,temperature FROM sensors WHERE temperature > 25 OUTPUT ACTION sprinkler-on() SAMPLE PERIOD 10s

The function to be Called Specify Data Sampling Rate

slide-8
SLIDE 8

The Greenhouse Scenario

  • A greenhouse with wireless sensors and actuators.

(Only the components Of our concern are shown)

slide-9
SLIDE 9

The Greenhouse Scenario (continued)

SELECT nodeid FROM sensors WHERE (nodeid=5 OR nodeid=7) AND temperature>35 AND humidity>45 ONCE; SELECT nodeid FROM sensors WHERE nodeid=9 OUTPUT ACTION air-cooler-on() ONCE; SELECT nodeid FROM sensors WHERE nodeid=15 OUTPUT ACTION screen-ctrl-on() ONCE; SELECT nodeid FROM sensors WHERE nodeid=23 OUTPUT ACTION sprinkler-on() ONCE;

slide-10
SLIDE 10

Issues In Declarative Interface For WSAN

  • 1. Violation of declarative nature.
  • 2. Inefficiency in complex actuation tasks.
slide-11
SLIDE 11

Solution Approach

  • Actuators were not the concern of TinyDB developers.
  • Data acquisition query syntax has been extended to support

actuators using a new keyword.

  • To solve declarative nature violations we need better query

syntax for actuation tasks.

slide-12
SLIDE 12

Virtual Data Table

nodeid temperature humidity 1 25 40 2 28 39 3 27 NULL 4 NULL 41 nodeid temperature humidity air-cooler sprinker 1 25 40 NULL NULL 2 28 39

  • ff
  • ff

3 27 NULL

  • n

NULL 4 NULL 41

  • ff
  • n

Traditional Sensors table Enhanced table With sensors And actuators

slide-13
SLIDE 13

Actuation By Updates

  • Actuator attributes in the table are alterable.
  • We can update actuator attributes by using traditional update

queries. UPDATE sensors SET air_cooler=’on’ WHERE nodeid=2 AND temperature>20 ONCE;

Still we need to specify sampling rate

slide-14
SLIDE 14

Actuation By Updates (continued)

  • Multiple nodes can involve for a single actuation task.
  • Alias can be used to perform such tasks.

UPDATE sensors AS sen, sensors AS act SET act.air_cooler=’on’ WHERE (act.nodeid=4 OR act.nodeid=2) AND (sen.nodeid=1 AND sen.temperature>20) ONCE;

Such as Greenhouse scenario

slide-15
SLIDE 15

Query Execution

slide-16
SLIDE 16

Evaluating Declarative Nature

  • Randomly selected a group of 10 students who have an

average knowledge on acquisitional queries.

  • Provided them with different actuation scenarios and asked

them to write SQL queries to perform those actuation tasks in both existing and the suggested approaches.

  • Collected feedback from them regarding how they found writing

queries for actuation tasks in both approaches.

slide-17
SLIDE 17

Evaluating Declarative Nature (continued)

  • Each person participated in the survey considers the existing

approach of performing actuation tasks has unnecessary syntax restrictions.

  • All the participants consider the modified virtual table with

actuators as attributes is more convenient to handle than the

  • ld table.
  • Most of them have struggled to write queries using the existing

syntax for the greenhouse scenario.

slide-18
SLIDE 18

Actuation Time

  • Actuation time Vs Number of fields in a query.
slide-19
SLIDE 19

Discussion

  • Having NULL values in the virtual table doesn't add any overhead to

the query execution cost.

  • Adding a list of functions to TinyDB query syntax can reduce the

multiple query usage to some extent. But still declarative nature violation remains.

  • Node mobility should be seriously considered in the future.
  • Require efficient ways to execute UPDATE queries in the network.
slide-20
SLIDE 20

Conclusion

  • Considering actuators as a part of the data model in the

database abstraction is more convenient.

  • UPDATE queries can be used to perform actuation tasks in the

network.

  • Executing actuation queries in the network needs more

research to handle node movements, node failures, etc.