SpaceTime Oriented Macroprogramming for Data

SpaceTime Oriented Macroprogramming for Data Collection in Coastal Environmental Sensor Networks Hiroshi Wada, Pruet Boonma and Junichi Suzuki Department of Computer Science University of Massachusetts, Boston Boston, MA 02125-3393 {shu, pruet, jxs}@cs.umb.edu Abstract This paper proposes a new programming paradigm for data collection in wireless sensor networks (WSNs), called SpaceTime Oriented Programming (STOP). It is designed to reduce the complexity of WSN programming by providing a high-level programming abstraction to specify spatiotemporal data collection in WSNs. In STOP, data collection is specified from a global viewpoint as a whole rather than sensor nodes as individuals. STOP treats space and time as first-class citizens and combines them as spacetime continuum. A spacetime is a three dimensional object that consists of a two spacial dimensions and a time playing the role of the third dimension. Application developers program data collections to spacetime, which abstracts away the low-level details in WSNs. This paper describes the design of the STOP language and STOP runtime environment.

1. Introduction Wireless sensor networks (WSNs) have been rapidly increasing in their scale and complexity. The decrease in unit cost of sensor nodes allows WSN applications to leverage more nodes to cover larger observation areas in higher spatial resolutions. At the same time, the increase in computing and networking capabilities in each node allows WSN applications to implement more advanced in-network functionalities such as node clustering, data aggregation, data filtering, data queries, anomaly detection and failure mitigation. These changes in scale and complexity make application programming more complicated, time-consuming and error-prone in WSNs. For example, even for implementing a simple node clustering mechanism (e.g., member selection, leader election and data synchronization among members), application developers need to know the lowlevel mechanisms in WSNs (e.g., routing, topology maintenance and signal strength sensing) and carefully control the state and behavior of each node with those mechanisms.

Macroprogramming is an emerging programming scheme that allows developers to implement a WSN application from a global viewpoint as a whole rather than sensor nodes as individuals [1]. In general, a macro program specifies the global behavior of a WSN application. The macro program is transformed to node-level (micro) programs, and the micro programs are deployed on individual nodes. This way, macroprogramming is expected to increase the simplicity, productivity and reliability in WSN application programming. This paper proposes a macroprogramming paradigm called SpaceTime Oriented Programming (STOP). It provides a new programming abstraction to specify spatiotemporal data collection as a global behavior of a WSN application rather than a behavior of individual nodes. STOP considers both spatial and temporal aspects of sensor data, and treats space and time as first-class citizens in programming. Space and time are combined as spacetime continuum. A spacetime is a three dimensional object that consists of a two spacial dimensions and a time playing the role of the third dimension. STOP allows application developers to program data collection to spacetime, and abstracts away the low-level details in WSNs, such as how many nodes are deployed in a WSN, how nodes are connected and synchronized with each other, and how packets are routed among nodes. Moreover, STOP provides a uniform means to specify data collections for the past and future. STOP assumes an application architecture that uses mobile agents1 to collect and process sensor data (Figure 1). In this architecture, each application is designed as a collection of mobile agents, called query agents (QAs). QAs are deployed at the Agent Repository, which is connected with base stations via the STOP server. QAs are dispatched to a particular spatial region (a certain set of nodes) to collect sensor data that meet a given temporal range and resolu1 Mobile agents are software entities/modules that move one node to another in the network.

tion. All collected sensor data is stored in a spatio-temporal database (STDB). This paper presents a motivating WSN application that STOP is designed for (Section 2), describe how the STOP language and the STOP runtime environment are designed (Sections 3 and 4), and concludes with some discussion on related work and future work (Sections 5 and 6). Sensors

Base Station

Wireless Sensor Network

Gateway

Agent Repository STOP Server

Query Agent Spatio-Temporal Database

Figure 1: A Sample WSN Organization

2. A Motivating WSN Application This section describes coastal oil spill detection/monitoring, which is a WSN application that STOP is currently designed for. STOP operates on a multi-modal WSN2 , which consists of battery-operated sensor nodes and several base stations. STOP currently assumes that all nodes are stationary. Base stations are linked to the gateway that in turn connects to the STOP server (Figure 1). When a QA arrives at the STOP server, the STOP server stores the sensor data the agent carries to STDB. Also, the STOP server maintains each node’s location through a certain localization mechanism. Oil spills occur frequently3 and have enormous impacts on maritime/on-land businesses, nearby residents and the environment. When an oil spill occurs due to, for example, broken equipment of a vessel and coastal oil station, illegal oil dumping or terrorism, an in-situ WSN of fixed buoyattached sensor nodes (e.g., fluorometers4 , surface roughness sensors5 , salinity sensors6 and temperature sensors7 ) 2 A multi-modal WSN deploys multiple types of sensor nodes. Data from different types of nodes are aggregated, through in-network processing, to provide a multi-dimensional view of collected data. 3 The US Coast Guard reports that 50 oil spills occurred in the US shores in 2004 [2], and the Associated Press reported that, on average, there was an oil spill caused by the US Navy every two days from fiscal year 1990 to 1997 [3] 4 Fluorescence is a strong indication of the presence of oils. Certain compounds in oil absorb ultraviolet light, become electronically excited and fluoresce [4]. Different types of oil yield different fluorescent intensities (emission wavelengths) [5]. 5 Oil films locally damp sea surface roughness and give dark signatures, so-called slicks [4]. 6 Water salinity influences whether oil floats or sinks. Oil floats more readily in salt water. It also affects the effectiveness of dispersants [6]. 7 Water temperature impacts how fast oil spreads. Oil spreads faster in warmer water than in cold water [6].

detects and monitors the spill. Oil may move and spread fast, change the direction of movement, and split into multiple chunks. Some chunks may burn, and others may evaporate and generate toxic fumes. A in-situ WSN can provide real-time sensor data so that human operators efficiently dispatch first responders to contain spilled oil in the right place at the right time, and avoid secondary disasters by directing nearby ships to move away from the oil, alerting nearby facilities or evacuating people from nearby beaches. In-situ WSNs can deliver more accurate information (sensor data) to operators more rapidly than visual observation does from the air or coast. Also, in-situ WSNs are less expensive than radar observation with aircrafts or satellites [7].

3. Design of STOP Language STOP language is designed based on the following requirements. Dynamic Type System Dynamic type system makes STOP programs simple and readable because it allows omitting variable declarations. Application developers can focus on application logic, i.e., what their program does, without considering types of variables. Object Oriented Programming Object oriented programming technique can hide the details of programs, i.e., states and implementation, through the notion of objects. It improves the maintainability and readability of programs. Moreover, object oriented programming is well accepted, and it lowers the learning curve of STOP langauge. Domain Specific Concepts STOP language should support several domain specific concepts as its primitives, e.g., the notion of time and operations for data aggregations, which all STOP programs require. It makes easy to implement and understand STOP programs because domain specific concepts can raise the abstraction level of programs. Integration of data query and data processing Any programs for data collection require not only data queries, but also data processing, e.g., data analysis or visualization. STOP language should support a mechanism (a notation) to associate a data query and a data processing easily. To satisfy these requirements, this project designs STOP language as an extension of Ruby8 . Ruby is an object oriented language equipped with a dynamic typing. It supports a facility to extend the language itself to support domain

8 www.ruby-lang.org

specific concepts without changing its parsers and interpreters. STOP language reuses Ruby’s syntax and semantics, but support several domain specific concepts. Also, Ruby supports closures, which modularize code blocks as objects (similar to anonymous method). Closures make easy to associate a code for data processing with a data query (Section 3.1). Moreover, STOP uses a JRuby9 interpreter to allow STOP programs to use existing Java libraries, e.g., for visualization. A STOP program consists of pairs of a data query and an event handler. A data query specifies an area and a time period from where to collect data, and provides collected data to its corresponding event handler for further data processing, e.g., data analysis or visualization. A declaration of a data query starts with specifying a certain spacetime consisting of a space (a two dimensional area) where attracts the attention, e.g., an area around a coastal oil station or an estuary region, and a time period, e.g., from 6 hours ago to 24 hours later. After that, a query will collect sensor data from the certain spacetime according to a certain data resolution which defines a frequency and the amount of data to collect, e.g., collecting fluorescence spectrum data from at least 80% of deployed sensor nodes in a certain space at every 1 hour. The notion of spacetime hides the details in WSNs, and application developers can declare data queries and data resolutions at a high abstraction level. A query returns collected sensor data, or processes sensor data and returns a result when a data processing operator is specified, e.g., calculating an average/standard deviation or finding the maximum/minimum value among sensor data, to its corresponding event handler which implements a further data processing, e.g., data visualization or data analysis. An event handler is implemented as a closure associated with a method to execute a query, i.e., get_data() method.

3.1. Example 1: Simple Query for the Past Listing 1 shows an example STOP program, which is visualized in Figure 2. The program in Listing 1 specifies a spacetime, sp, a polygonal prism consisting of a triangular space, s, and a time period during the last one hour, p. STOP language supports the concept of time as its primitive, and allows to denote relative time as a number annotated with a keyword such as Week, Day, Hr, Min, Sec. get_spaces_every() returns a discrete set of "snapshot" spaces that meet specified spatial and temporal resolutions. In this example, the method returns spaces at every five minutes (first parameter) with a 10 seconds time band (second parameter), and each space contains at least 80% of nodes within it (third parameter). Then, the maximum data is selected from each space and assigned in max_values. In STOP language, a list has each() method 9 jruby.sourceforge.net

which takes a closure as its parameter, and the closure is called on each element in a list. In this example, each element in spaces is assigned to space parameter of a closure (Line 10). get_data() is used on a space to process data available on the space according to a data processing operator (second parameter). STOP language supports several operators, e.g., MAX, MIN, AVG and SUM, as its primitives. The third parameter of get_data() specifies the tolerable delay (i.e., deadline) to collect and process sensor data (three minutes in this example). get_data() can have a closuer as an event handler (Line 13 and 14). A closure is executed when get_data() returns a data. At the same time, the maximum values from each space are stored in max_values by using push() method of a list. STOP language supports select() method to return a subset of a list which meets a certain condition specified in a closure. event_spaces obtains subset spaces (from spaces), each of which yields 10 or lower standard deviation of sensor data and finds higher than 20 degrees difference in average data compared with a previous space in the list spaces. Listing 1: Example Query 1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

points = [ Point.new( 10, 10 ), Point.new( 100, 100 ), Point.new( 80, 30 ) ] s = Polygon .new( points ) p = RelativePeriod .new( NOW , Hr -1 ) sp = Spacetime .new( s, p ) spaces = sp. get_spaces_every ( Min 5, Sec 10, 80 ) max_values = [] spaces .each { |space| max = space. get_data ( ’f- spectrum ’, MAX , Min 2 ){ | event_type , value , space , time | # event handler } max_values .push( max ); } name = ’f- spectrum ’ event_spaces = spaces . select {|s| s. get_data (name ,STDEV ,Min 5) 20)}

Time

Future

NOW

Y Node (0) (10, 10)

(100, 100)

(80, 30)

Space (s)

Spacetime (sp) X

Min 5 Hr -1

Past

List of Nodes (nodes_over_time)

Figure 2: A Query in STOP

3.2. Example 2: Event-Driven Query Listing 2 shows another example, which is visualized in Figure 3. This program is called when an event (e.g., oil spill) occurs, and investigates the event area during the last 30 minutes with low data resolution and watches an area around the event area during the next one hour with high data resolution in a real-time manner. This program is designed as an event handler of GLOBALSPACE. GLOBALSPACE is a special type of space, which represents a whole monitoring area, and it takes closures which implement an event handler and a condition to call the event handler. In Listing 2, when fluorescence spectrum data exceeds 300nm in some area (select() method in Line 2), it activates a closure of on_event() method (from Line 3 to 22). Parameters of a closure of on_event() represent features of an event (e.g., event area and time). Then, the program (an event handler) creates a spacetime, sp1, consisting of event_space in which an event is found and a period during the last 30 minutes (Line 6). Then, a list of spaces at every six minutes (past_spaces) is extracted from sp1 (Line 7), and from Line 8 to 10 counts the number of nodes that ’f-spectrum’ data exceeds 280nm on each space in past_spaces. This example also creates a spacetime in the future, sp2, consisting of the space s2 during the next one hour (Figure 3). Line 18 collects the maximum ’f-spectrum’ data and executes a corresponding event handler (a closure) at every three minutes. Listing 2: Example Query 1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

GLOBALSPACE . select {|s| s. get_data (’f- spectrum ’, MAX) > 300 } . on_event { |event_type ,value , event_space , event_time |

# query for the past sp1 = Spacetime .new( event_space , event_time ,Min -30) past_spaces = sp1. get_spaces_every (Min 6,Sec 20 ,50) num_of_nodes = past_spaces . get_nodes . select {| node| node. get_data (’f- spectrum ’,Min 3) > 280}. length # query for the future s2 = Circle .new( event_area .centroid , event_area . radius * 2 ) sp2 = Spacetime .new( s2 , event_time , Hr 1 ) future_spaces = sp2. get_spaces_every ( Min 3, Sec 10, 80 ) future_spaces . get_data ( ’f- spectrum ’, MAX , Min 1 ){ | event_type , value , space , time | # event handler } }

4. The STOP Runtime Environment STOP programs runs on a STOP runtime environment. The runtime environment consists of several components as illustrated in Figure 4. After application developers write a STOP program, the program is deployed on the STOP server and interpreted by a JRuby interpreter. STOP runtime environment has a STDB which stores pushed/pulled sensor data (in

Y

Time Future

Min 3

Spacetime (sp2)

Hr 1

event_time

Space (s2)

Min 6

Space (event_space) X Spacetime (sp1)

Min -30 Past

Figure 3: An Event-Driven Query in STOP SensorRedings table) received through a gateway and locations of sensors (in SensorLocations table). When a STOP program has a query for the future, received sensor data is notified to an appropriate event handler in the program as well. Locations of sensors are represented in OpenGIS’s Well-Known Text (WKT) format10 in a STDB, and a STOP program uses geographic functions defined by OpenGIS to retrieve a list of sensor nodes in a certain space specified in a query. If a STDB can provide enough sensor data to satisfy a query’s data resolution, a program constructs a SQL query automatically and obtains data from a STDB. If a STDB can not provide enough sensor data, a STOP program automatically dispatch QAs to certain sensor nodes to "pull" sensor data in order to satisfy a data resolution through a gateway. STOP assumes each sensor node has a Bombilla VM [8] and QAs can migrate to sensor nodes to collect sensor data. Before dispatching QAs to a sensor network, a STOP program retrieves a QA code in tinyscript from an agent repository and configures it, e.g., specifying nodes to visit and data to collect. Collected (pulled) data is also received through a gateway, and stored in a STDB. The notion of data resolution hides the details of a push-pull hybrid WSN architecture. Data collections are automatically performed according to required data resolutions. Application developers do not need to collect (pull) sensor data explicitly in their applications, but can benefit from a push-pull architecture.

5. Related Work Kairos [9] and SNLong [10] provide programming abstractions to describe spatial relationships and data reduction operations across nodes. Data collection can be expressed without specifying the details of node-to-node communication and data aggregation. However, these languages still require application developers to work at the node level. Developers need to explicitly write programs to individual sensor nodes. In contrast, STOP allows developers to 10 www.opengeospatial.org

STOP Server STOP Class Library Sensor Locations SensorID

JRuby Interpreter

Location

OpenGIS (WKT)

Agent Repository

query

configure

Sensor Readings SensorID Time Value

QA code PostgreSQL + PostGIS

notify deploy

store Gateway Data Receiver

Sensor Data Sensor SensorData Data QAs

rently, QAs visit nodes to collect data, and carry the data to STDB for executing data processing operators such as AVG and MAX. QAs will be extended to support in-network data aggregation. This can reduce the amount of data transmitted in the network and contribute to expand network life. In addition to pre-defined data processing operators such as AVG and MAX, STOP will be extended to allow programmers to define their own operators. Also, STOP will provide a GUI for developers to visually specify spatiotemporal data collection.

Code Dispatcher

dispatch to certain nodes

References QAs

Figure 4: The STOP Runtime Environment write programs at a higher level of abstraction; spacetime, thereby improving the productivity and maintainability in WSN programming. Also, Kairos and SNLong cannot deal with temporal aspects of sensor data; data is always handled only at the current time frame. TinyDB [11] extends SQL to support in-network data processing, and addresses spatial and temporal aspects of sensor data. It allows developers to program data collection in the future, but not in the past. Moreover, since TinyDB is an extension to SQL, its expressiveness is too limited to specify event handlers although it is well applicable to specify data queries. Therefore, application developers need to learn and use an extra language to implement event handlers. In contrast, STOP supports spatio-temporal data collection both in the future and the past. Its expressiveness is high enough to provide an integrated programming abstraction for data queries and event queries. This increases the ease of programming and understanding the overall design of an WSN application. Regiment [12] is another WSN macroprogramming language supporting in-network data processing and spatialtemporal data collection. It allows developers to specify data collection for the future, but not for the past. Also, Regiment does not support the notion of spatial and temporal resolutions. Unlike Regiment, STOP allows developers to specify data collection for both future and past in arbitrary spatio-temporal resolutions.

6. Conclusion This paper proposes a new macroprogramming paradigm for data collection in WSNs, called SpaceTime Oriented Programming (STOP). By leveraging the notion of spacetime, STOP is designed to reduce the complexity of WSN programming to specify spatio-temporal data collection. Several extensions are planned as future work. Cur-

[1] M. Welsh and G. Mainland. Programming Sensor Networks Using Abstract Regions. USENIX/ACM Symposium on Networked Systems Design and Implementation, March 2004. [2] US Coast Guard. Polluting Incident Compendium: Cumulative Data and Graphics for Oil Spills 1973-2004. Technical report, September 2006. [3] L. Siegel. Navy Oil Spills. Webpage, November 1998. [4] J. M. Andrews and S. H. Lieberman. Multispectral Fluorometric Sensor for Real Time in-situ Detection of Marine Petroleum Spills. In The Oil and Hydrocarbon Spills, Modeling, Analysis and Control Conference, July 1998. [5] C. E. Brown, M. F. Fingas, and J. An. Laser Fluorosensors: A Survey of Applications and Developments. In The Twenty-forth Arctic and Marine Oil Spill Program Technical Seminar, June 2001. [6] US Environmental Protection Agency. Understanding Oil Spills and Oil Spill Response. Technical report, 1999. [7] M. F. Fingas and C. E. Brown. Review of Oil Spill Remote Sensors. Spill Science & Technology Bulletin Journal, 4(4), 1997. [8] P. Levis and D. Culler. Mate: A Tiny Virtual Machine for Sensor Networks. Int’l Conference on Architectural Support for Programming Languages and Operating Systems, October 2002. [9] R. Gummadi, O. Gnawali, and R. Govindan. Macroprogramming Wireless Sensor Networks using Kairos. IEEE Int’l Conference on Distributed Computing in Sensor Systems, June 2005. [10] D. Chu, A. Tavakoli, L. Popa, and J. Hellerstein. Entirely Declarative Sensor Network Systems. Int’l Conference on Very Large Data Bases, September 2006. [11] S. Madden, M. J. Franklin, J. M. Hellerstein, and W. Hong. TinyDB: An Acqusitional Query Processing System for Sensor Networks. ACM Transactions on Database Systems, March 2005. [12] R. Newton, G. Morrisett, and M. Welsh. The Regiment Macroprogramming System. Int’l Conference on Information Processing in Sensor Networks, April 2007.