Towards Service-Oriented Networked Embedded Computing

Liz is a site manager at the high-rise CEDAR office building in downtown B city. As one of their major customers has just moved to another site, she wants to evaluate the idea of opening part of the parking space underneath the building to the general public. To help her to reach a decision, she wants to collect vehicle arrival and departure statistics in the parking lot for a period of two weeks. Pablo is a security officer for the CEDAR building. He is investigating complains from people that there are several cars driving extremely fast in certain areas of the garage. He wants to take pictures of those cars and issue warnings to offending drivers. Cameo is a local law enforcement agent in B city. He is in charge of installing chemical sensors at strategic locations throughout the city for terrorism detection. He has installed some of them in the CEDAR building garage, and wants a notification whenever a vehicle carrying certain chemical elements is detected. Although they are from different organizations, Liz, Pablo, and Cameo all plan to use a generic wireless sensor network recently installed in the garage and augment it with special purpose sensors as needed. Systems like these are not readily supported by the current networked embedded system technologies developed by the sensor network research community. Today, sensor network applications are designed using primarily one of the two philosophies: the dada-collection view and the application-specific view. In the datacollection view (see the various sensor database projects [Cougar; tinyDB; GDI]), a sensor network is regarded as data collection fibers where sensor data are streamed to servers. The data can be either aggregated through routing or processed centrally. Although advances have been made on running user queries within the network, the architecture is ill-suited for monitoring and tracking sparse events in a resource-constrained environment. The application-specific view [Shooter] acknowledges the fact that many sensor network system behaviors depend heavily on the physical stimuli, and tries to make the best use of the power and bandwidth resources through exploiting the application-specific dynamics. For example, a microphone-based vehicle tracking system would be designed quite differently from a camera-based system, although many of the system components are similar. Everything is optimized at the design time. The system is rigid and hard to change afterwards. These two philosophies can be viewed as two extremes for handling application logics. In the data collection view, there is no application logic in the network; everything is processed off line. It is quite generic but not always resource optimal. In the application specific view, the application logic is hard wired into the network. The designers have fine grained resource control but the system is rigid and hard to reuse. We motivate here a service-oriented architecture for networked embedded computing, SONGS, where the system is open, retaskable, and resource-aware, a “happy median” between the data-collection and application-specific views. As illustrated in the CEDAR building scenario, we envision that a large-scale networked embedded system is likely to be deployed by