In 2020, we will live in a world that is networked to unprecedented scale where every device and appliance will have computing and communication capabilities, and smart sensor networks will be deployed widely for measurement, detection, and monitoring applications. Existing architectures for working with this world of sensors and monitoring agents are inadequately scalable and overly constraining. Today's sensor networks lack flexibility because sensors are treated as remote peripherals from which data can only be extracted in a predefined way for transmission to central storage. In the Cougar Project, we are investigating a novel distributed database approach to unite the seemingly conflicting requirements of scalability and flexibility in mining and monitoring the physical world. We are building a distributed data management infrastructure that scales with the growth of interconnectivity and computational power over the next decades.
The COUGAR System is a platform for testing query processing techniques over ad-hoc sensor networks. COUGAR has a three-tier architecture: The QueryProxy, a small database component that runs on sensor nodes to interpret and execute queries, and a Frontend component, which is a more powerful QueryProxy that permits connections to the world outside of the sensor network, and a graphical user interface through which users can pose ad-hoc and long-running queries on the sensor network. Our system forms clusters out of the sensors to allows intelligent in-network aggregation to conserve energy by reducing the amount of communication between sensor nodes. The query processing component handles queries for distributed devices in an intelligent manner. We will describe these three parts in more detail in the next section.
Currently, the QueryProxy system may be used to monitor sensor output from any sensor which is compatible with the Sensoria WINS NG 2.0 node (see hardware). This includes acoustic and seismic sensors as well as a GPS receiver. However, any type of sensor may be used with the system, provided that code is available to read the sensor output as an integer, floating point, or string value. The GUI component of the system allows a user to enter SQL style queries as XML. These queries can use aggregates such as sum, min, max, average, etc. Additionally, since all messages sent and received by the system are in XML format, the QueryProxy can communicate with any type of software or device which sends messages according to the DTD used by the QueryProxy.
There are many possible monitoring applications for the QueryProxy system. The system may be used when raw sensor data is required, or one wants some aggregated data from multiple nodes. Additionally, this data may be limited to a specific region, allowing one to either focus on a specific region, or compare sensor values or aggregates from multiple regions.
For example, maintenance workers in a factory may use the system to detect which areas of the factory have abnormally high areas of vibration. This may alert them to machines in the factory which might be beginning to break down, and allow them to fix the problem before it occurs. The system may also be used to get the average temperature in a certain region.
The QueryProxy consists of three parts: the device manager, the node layer, and the leader layer. The sensor nodes are capable of acting as leaders or normal query processing/signal processing nodes. When the network is set up, clusters are formed and leaders are elected from the nodes in the clusters. The QueryProxy system has a hierarchical structure, with the front-end communicating with nodes that act as cluster leaders, and with cluster leaders communicating with the front-end and with the other sensor nodes in their clusters. The node layer manages the execution of queries on the sensor node and the interaction with the sensors via the device manager. This code is active on all the nodes. On a cluster member, when a query is to be processed, the node layer first requests the required tuples from the device manager. Then, the query is processed using those tuples and the results are sent to the cluster leader. The cluster leader, elected when the system forms clusters, has in addition to its node processing layer, an active leader processing layer, which receives tuples from the other members of the cluster. The tuples it receives are delivered to each query it has received from the front-end that needs the tuples. The leader layer then processes the queries using the received tuples and sends the replies to the front-end that initiated the query. When appropriate, tuples are aggregated before being sent out.
The FrontEnd issues queries it has received from the GUI to the QueryProxy software running
on the sensors. It keeps track of the queries currently running for the GUI's running on the system and
receives messages from nodes that are cluster leaders. The FrontEnd delivers each tuple to the queries that
require it, does some processing of the tuples and sends a response to the GUI that initiated the query. The
FrontEnd can also receive commands from the GUI instructing it to start and stop queries. The FrontEnd
can also output tuples to a MySQL database running on the same device.
The Java-based GUI allows the user to pose queries, either visually or using SQL, and see query replies. Query replies are saved and can be visualized in tabular form. A map component allows the user to query by region and visualize the topology of sensors in the network. Additionally, the GUI allows the user to obtain the status of each individual node in the network, giving its position and cluster membership. The GUI may be run on any machine that can run Java and Swing and has a TCP/IP connection to a node or Linux machine running the FrontEnd.
The QueryProxy software runs on Sensoria WINSNG 2.0 nodes, running Linux on SH4 CPUs, as well as x86 machines running Linux. Each of the Sensoria nodes has GPS, seismic, and acoustic sensors. A sensor network consists of Sensoria nodes communicating via RF radio using the Directed Diffusion routing protocol running the QueryProxy. GUIs will communicate with selected Sensoria nodes running the FrontEnd over Ethernet.
For more information about the current release of COUGAR, please see the COUGAR Design Documentation in PDF or HTML formats.
Manuel Calimlim
Zhiyuan Chen
Adina Costea
Al Demers
Wai Fu Fung
Johannes Gehrke
David Sun
Yong Yao
Collaborators
Francis Chu, Cornell CS
Joe Halpern, Cornell CS
Daniel Mosse, University of Pittsburgh CS
Alumni
Anton Faradjian, J. E. Gehrke, and Philippe Bonnet. GADT: A Probability Space ADT For Representing and Querying the Physical World. To appear in Proceedings of the 18th International Conference on Data Engineering (ICDE 2002), San Jose, California, February 2002.
Zhiyuan Chen, J. E. Gehrke, and Flip Korn. Query Optimization In Compressed Database Systems. In Proceedings of the 2001 ACM Sigmod International Conference on Management of Data, Santa Barbara, California, May 2001.
Philippe Bonnet, J. E. Gehrke, and Praveen Seshadri. Towards Sensor Database Systems. In Proceedings of the Second International Conference on Mobile Data Management. Hong Kong, January 2001.
Philippe Bonnet, J. E. Gehrke, and Praveen Seshadri. Querying the Physical World. IEEE Personal Communications, Vol. 7, No. 5, October 2000, pages 10-15. Special Issue on Smart Spaces and Environments.
Philippe Bonnet, Praveen Seshadri: Device Database Systems. In Proceedings of the 16th International Conference on Data Engineering, San Diego, California, February 2000.
The COUGAR Project is supported by the Defense Advanced Research Project Agency, the Cornell Information Assurance Institute, and by a gift from Intel. Any opinions, findings, conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the sponsors.