An Object-Centric Programming Framework forAmbient-Aware, Service-Oriented Sensor Networks

Manish Kushwaha, Isaac Amundson*, Xenofon Koutsoukos*,Sandeep Neema, Janos Sztipanovits

Vanderbilt UniversityNashville, TN 37235, USA

{manish.kushwaha, isaac.amundson, xenofon.koutsoukos}@vanderbilt.edu

Chang Hong Lin, Wayne WolfPrinceton University

Princeton, NJ 08544, USA

Abstract— Classical programming languages are too low-leveland not well-suited for large scale sensor network applications.Volatile connections and dynamic network topologies render thedevelopment of sensor networks very complex. In this abstract,we describe our current work on a service-oriented frameworkbased on object-centric, ambient-aware programming. Object-centric refers to the programming model wherein objects arefirst class elements that represent external physical entitiesallowing the application developer to program at a higher levelof abstraction. Ambient-aware is a paradigm that incorporatesnetwork volatility into the programming model. We outline sucha framework and describe the main individual components.

I. INTRODUCTION AND MOTIVATION

Wireless sensor networks (WSNs) are inherently dynamic innature due to node mobility, failure, and unreliable communi-cation links. It is therefore imperative that WSN applicationsconsider dynamic network topology in order to ensure theircorrect execution. Unfortunately, tackling the issue of dynamicnetwork behavior places a substantial burden on the program-mer. In addition to an application’s core functionality, theprogrammer must implement low-level WSN operations suchas robust communication protocols, resource managementalgorithms, and fault tolerance mechanisms. Not only does theimplementation of these components require substantial timeand effort on behalf of the programmer, but it also increases therisk of deploying incorrect code, due to the often unanticipatedbehavior of distributed network applications.

In this abstract, we propose an object-centric ambient-aware programming framework, enabling the programmerto develop WSN applications without having to deal withthe complexity and unpredictability of underlying networkdynamics. In object-centric programming, objects are firstclass programming elements representing physical phenomenabeing monitored by the network. The basic idea behind sucha framework is to provide programmers with a higher levelof network abstraction, allowing applications to be developedfrom the viewpoint of the object.

Object-centric programming can be used for a variety ofapplications such as mobile vehicle tracking, fire detectionand monitoring, and distributed gesture recognition [1]. Ges-ture recognition on a moving object requires logical entities

∗The work of these authors is partially supported by a grant from MicrosoftExternal Research.

for keeping track of the object collaborating with imageprocessing components as well. A typical sensor network willconsist of a series of slightly overlapping video surveillancenodes. When a human target is detected, the applicationspawns a tracking agent, which migrates across the networkfollowing the real-world object. Meanwhile, image-processingcomponents are employed to identify the object’s varioushand movements and facial expressions. These algorithms aretypically resource intensive and require collaboration amongseveral nodes. While monitoring the object, the tracking agentmust simultaneously locate various remote image processingcomponents, and forward collected imaging data.

Object-centric programming by itself does not address theissues of network failures and dynamic network topology.The programming model must be enhanced for encompassingthe dynamics of wireless networks and if possible, provideguarantees for the correct operation of software applications.Communication failures in traditional application program-ming are handled on an individual basis as exceptional events.In WSN programming, communication failures are not excep-tions, but normal operational behavior, and must therefore betreated as such. Ambient-oriented programming has emergedas a paradigm for mobile computing [2] and provides severalcharacteristics that are useful for robust sensor network ap-plications. The basic idea of ambient-aware programming forsensor networks is dynamic service discovery initiated by themonitored object in order to manage the required resources inthe changing network topology. Further, such objects shouldbe reflective to allow for reconfiguration and error recovery,organize the distribution of collaborative tasks, and ensure thatthe application cannot be blocked, for example, due to a linkfailure.

To develop such a programming paradigm, our frameworktakes a service-oriented approach to behavioral decomposi-tion. In a service-oriented WSN application, each activity(sensing, aggregation, service discovery) is implemented asa separate service. The advantages of using a service-orientedarchitecture for WSN applications are similar to those of web-services. Services are modular, autonomous, and have well-defined interfaces that allow them to be described, published,discovered, and invoked over a network. These propertiespermit services to be dynamically composed into complete

applications. Because many WSN applications will consist ofmultiple services on multiple nodes, planning, scheduling, andservice discovery mechanisms are built in to the framework.These mechanisms are designed to function effectively in thepresence of unreliable communication links.

The object-centric paradigm has been successfully usedin the EnviroSuite programming framework [3]. EnviroSuiteprovides a high level of abstraction, however its modularitycan be enhanced following a service-oriented approach foradding software components. In EnviroSuite, fault-tolerancecan be achieved by employing periodic heartbeat messages tonodes surrounding an object of interest and can be improvedby incorporating ambient-aware functionalities.

II. PROGRAMMING FRAMEWORK

Fig. 1. Architecture

In our proposed framework (Figure 1) there are four maincomponents, viz. end-user programming interface, serviceplanner, network service scheduler and node manager.Programming interface is responsible for injecting servicerequests into the sensor network. The end user writes anobject application using the services registered in the servicerepository. The service repository keeps a registry of all theservices discovered in the network. The repository can besimilar to the UDDI registry that is used for most web-services.The output of this component is a service request in a service-request-query-language.Service planner takes the service request as the input andgenerates a service graph of constituent services listed inservice repository. In general, a service request is expandedinto constituent services until no more services need to beexpanded. Services are expanded based on the inputs theyrequire to run. Consider a vehicle tracking application inwhich the user wishes to track any vehicle in an area ofinterest. Figure 2 shows the service graph for the vehicletracking service. The service requires vehicle classification andposition as inputs. A vehicle classification service providesclassification and position data but requires a logical object forthe vehicle. A vehicle is sensed by a vehicle sensing service,after which the logical object is created.Network service scheduler (NSS) will schedule services atthe sensor nodes that provide target sensing functionalitieswhile satisfying certain constraints, for example on the numberand locations of the nodes. NSS requires runtime information

Fig. 2. An example service graph and its schedule on sensor nodes

of the services provided by nodes as well as their properties,such as location, remaining power, etc. The output of NSSconsists of service configuration messages which are sent tonodes for composing the service graph.Node manager is responsible 1) configuring the node ser-vices based on a configuration message, 2) initiating servicediscovery, and 3) managing the local runtime service andresource information required by the NSS. The node managerwill initiate service discovery to locate the services to runon the object following the current service. An integral partof the node manager is a service discovery protocol. Thenode running service discovery sends out a publish messageindicating its interest in discovering services in the network.All the nodes that receive the message respond with aninformation message containing information for the availableservices and the cost for using these services, for example,with respect to power. The receiving node processes thisinformation and builds a local service database.

III. IMPLEMENTATION

Currently, we are developing the runtime infrastructure thatis necessary for supporting the execution of object-centric,ambient-aware applications. Our target platform is Mica motesrunning TinyOS. The services include object related servicessuch as objection creation, management, and migration serviceas well as node manager and network level components suchas network service scheduler, service planner, and servicerepository. We use galsC [4] for sensor node programmingbecause it provides an actor abstraction for sensor nodes thathandles elegantly asynchronous communication. Using theactor abstraction provided by galsC, we can employ actorsas the building blocks of services.

REFERENCES

[1] C. H. Lin, T. Lv, W. Wolf, and B. Ozer, “A peer-to-peer architecturefor distributed real-time gesture recognition,” in IEEE InternationalConference on Multimedia and Expo (ICME), 2004.

[2] J. Dedecker, T. V. Cutsem, S. Mostinckx, T. D’Hondt, and W. D. Meuter,“Ambient-oriented programming,” in OOPSLA Companion 2005, 2005.

[3] L. Luo, T. Abdelzaher, T. He, and J. Stankovic, “Envirosuite: Anenvironmentally immersive programming system for sensor networks,”in ACM Transaction on Embedded Computing System (TECS), 2006.

[4] E. Cheong and J. Liu, “galsc: A language for event-driven embeddedsystems,” in DATE ’05: Proceedings of Design, Automation and Test inEurope, 2005.