state-centric programming for sensor-actuator network systems · as information-driven sensor...

50 PERVASIVEcomputing Published by the IEEE CS and IEEE ComSoc ■ 1536-1268/03/$17.00 © 2003 IEEE

S E N S O R A N D A C T U A T O R N E T W O R K S

State-CentricProgramming for Sensor-ActuatorNetwork Systems

Distributed embedded systems suchas wireless sensor and actuator net-works require new programmingmodels and software tools to sup-port the rapid design and proto-

typing of sensing and control applications. Unlikecentralized platforms and web-based distributedsystems, these distributed sensor-actuator network(DSAN) systems are characterized by a massivenumber of potentially failing nodes, limited energyand bandwidth resources, and the need to rapidlyrespond to sensor input.

As application developers, wemust fundamentally rethink theorganization and programmingof these deeply embedded sys-tems. What is the appropriatemental model we can use to rea-

son about the collective behaviors of a systemwhen programming a distributed application sothat the application is portable, scalable, androbust? What are the organizational principles fordevelopers to build large applications by mixingand matching various ad hoc communication pro-tocols while shielded from dealing with a multi-tude of communication events? How does thesoftware architecture expose the underlying sys-tem constraints so that application developers canconsider important performance trade-offs?

This article describes a state-centric, agent-based

design methodology to mediate between a systemdeveloper’s mental model of physical phenomenaand the distributed execution of DSAN applica-tions. Building on the ideas of data-centric net-working,1 sensor databases,2 and proximity-basedgroup formation,3 we introduce the notion of col-laboration groups, which abstracts common pat-terns in application-specific communication andresource allocation. An application developerspecifies computations as the creation, aggrega-tion, and transformation of states, which natu-rally map to the vocabulary used by signal pro-cessing and control engineers. More specifically,programmers write applications as algorithms forstate update and retrieval, with input supplied bydynamically created collaboration groups. As aresult, programs written in the state-centric frame-work are more invariant to system configurationchanges, making the resulting software more mod-ular and portable across multiple platforms. Usinga distributed tracking application with sensor net-works, we’ll demonstrate how state-centric pro-gramming can raise the abstraction level for appli-cation developers.

Sensor network programmingSensor-actuator network systems offer unique

advantages over traditional centralized approaches.Dense networks of distributed sensors can im-prove perceived signal-to-noise ratio by reducing

Networked embedded systems must be able to rapidly respond to allkinds of sensing events, even though they have numerous failure-pronenodes and limited energy and bandwidth resources. The designmethodology and software environment described here mediate between the developer’s mental model of physical phenomena and the distributed application.

Jie Liu, Maurice Chu, Juan Liu,James Reich, and Feng Zhao Palo Alto Research Center

average distances from sensor to physi-cal phenomena. In-network processingand actuation shorten the feedbackchain and improve the timeliness ofobservation and response. Untetherednetwork nodes and infrastructurelessmesh network topologies reduce deploy-ment costs. However, the greatest advan-tages of networked systems are improvedrobustness and scalability. A decentral-ized system is inherently more robustagainst individual node or link failuresbecause of network redundancy. Decen-tralized algorithms are also far more scal-able in practical deployment; they mightbe the only way to achieve the large scalesneeded for some applications. Because ofdecentralized systems’ spatial coverageand multiplicity in sensing aspect andmodality, the detection, classification,and tracking of moving, nonlocal, orlow-observable events require cross-nodecollaboration among sensors.

Collaborative signal and informationprocessing (CSIP) algorithms, althoughhaving attractive properties such asrobustness and scalability, are extremelyhard to design, implement, and especiallydebug. The algorithms are highly spe-cialized and must cope with a great dealof uncertainty—in physical hardware,sensor measurements, and communica-tion. Traditional programming method-ologies, such as node- and network-centric interfaces and imperative lan-guages for networked embedded systems,don’t provide adequate abstractions forCSIP applications. They provide systemservices such as networking, sensing, andtask scheduling through a node-leveloperating system. Given the uncertaintyand need to optimize across network andsensing layers, traditional methodologiespush many quality-of-service decisions tothe application developers. For example,because individual nodes and links areunreliable, providing reliable communi-cations between sensors in the networkstacks isn’t always practical.

Most sensor network interfaces onlyprovide primitives to discover commu-nication peers and to send and receivemessages in a best-effort manner. Reli-able communications are implementedat the application level and must bebacked up by fault-tolerant plans to copewith communication failures. As a result,applications are typically constructed asparallel finite-state machines running oneach individual node to anticipate every

possible combination of concurrent sens-ing and communication events. The sys-tem’s global behaviors are the result ofthese local FSMs’ interactions. On theother hand, declarative interfaces such asSQL for databases provide a hardware-independent abstraction. However, CSIPapplication developers must still writecollaborative processing programs tosupport the high-level declarative queries.

The framework we describe here fillsthis important space between high-levelinformation processing and node-levelexecutions. Node-centric programmingabstractions for CSIP applications arefairly difficult to manage. In our ownexperiences with a collaborative single-target tracking system, nearly 40 percentof the code and most of the debuggingeffort dealt with communication and con-currency concerns, even though the sys-tem was built on well-designed com-munication protocols—directed diffusionand GEAR (geographical and energyaware routing).4 The FSM on each nodequickly explodes the code size and com-plexity to respond to the various typesand orders of occurrence of sensing andcommunication events. Implementing amultitarget tracker boosts complexity toa yet higher level, making practical devel-

opment unlikely without significantimprovements in our abstraction.

This complexity will be an even moreserious obstacle for future sensor networkdevelopers, who likely will be domainexperts rather than networking or oper-ating system experts. (They think in termsof physical phenomena and signal pro-cessing instead of communication proto-cols and concurrency management.) Canwe provide a programming model that

exposes a system theory view, consideringcomputation in terms of state updates andshielding programmers from communi-cation, control flow, and node collabora-tion issues? We’ll use a target-trackingexample to demonstrate this approach.

Target tracking as a motivating example

Tracking is a canonical problem forsensor networks and essential for manycommercial and military applicationssuch as traffic monitoring, facility secu-rity, and battlefield situational awareness.Given a moving point signal source ortarget in a 2D sensor field, a tracking sys-tem’s goal is to estimate target state his-tories, such as spatial trajectory, on thebasis of sensor measurements. From atracking expert’s point of view, each sen-sor node provides a local measurementuseful in estimating the target state. How-ever, in most cases, only a relatively smallsubset of sensors contribute significantlyto the estimation, owing to sensing-rangelimitations. In this case, a good solutionis a leader-based tracking scheme, suchas information-driven sensor querying,5,6

to fuse information from only the sensorsthat provide high-quality measurements.As Figure 1 illustrates, at any time instant

OCTOBER–DECEMBER 2003 PERVASIVEcomputing 51

In most cases, only a relatively small subset

of sensors contribute significantly to the

estimation, owing to sensing-range limitations.

t, IDSQ designates a single node, locatedclose to the target, as leader. The leadernode fuses these high signal-to-noise-ratio measurements and updates its cur-rent target location estimate, referred toas the belief. This can be done using, forexample, sequential Bayesian filtering.

For most sensor types, owing to thephysical properties of signal propagation,the sensors with high signal-to-noise ratiowill be within a limited range of the leadernode. So, you can minimize the commu-nication cost and latency for gatheringsensor data. As the target traverses thesensor field and the belief evolves to fol-low its motion, the most “informative”sensors might no longer be those closestto the current leader. A nearby sensormight then be selected to replace thisleader on the basis of the updated beliefand a criterion combining resource con-straints with some measure of sensing util-ity (such as mutual information). The cur-rent leader then hands off the belief to thissensor, which becomes the next leader attime t + δ, where δ is the communicationdelay. The process of sensing, estimation,and leader selection repeats.

We term the organization of sensingand the associated data transport tasksin CSIP applications the models of col-laboration among the sensors. In addi-tion to leader-based collaboration, thereare other types of sensor collaboration.Consider another example where a sen-

sor network collaboratively finds a con-tour of constant temperature within thesensor field (see Figure 2). In this case,the state of the tracked phenomenon(that is, the shape of a specific tempera-ture contour) might not be available to asingle sensor or its local neighborhood.Each sensor node might detect a sectionof the contour by locally comparing sen-sor measurements, but the network mustpiece together these partial states to formthe contour object’s global state.

The types of sensor collaboration inthese two examples are quite different.In the first example, the sensor nodes col-laborate primarily to improve sensingaccuracy, and acceptable estimationquality might be achieved using only asubset of the sensors. One node, theleader, plays a key role in fusing others’sensor measurements. In the contour-tracking example, on the other hand, noleader is present, and all sensors thatform the contour are equally important.Each node might locally update andrepair its observation of a contour sec-tion, but the global state can only beassembled from observations of manynodes along the entire contour.

These high-level notions of collabora-tion, although useful as conceptual mod-els for programmers to prototype CSIPapplications, do not directly map to pro-grams under traditional distributed-programming interfaces. System design-

ers must explicitly write code to

• Maintain sensor connectivities in aneighborhood

• Discover the best node for handoff• Invite neighbor nodes into the group• Handle communication delays and

failures

When application complexity increases,traditional programming abstractionsdon’t scale up accordingly. For example,tracking multiple moving targets, aswe’ll describe later, presents additionalchallenges beyond the simple multiplic-ity of targets, such as the need to handleinteractions between multiple trackingleaders as well as the underlying target-sensing behaviors in close proximity.

State-centric programmingCSIP applications, such as target

tracking, are not generic distributed pro-grams. Deeply rooted in these applica-tions are the notion of states of physicalphenomena and models of their evolu-tion over space and time. We can repre-sent some states centrally, as in the pointtarget-tracking example, but must rep-resent others in a distributed fashion, asin the contour-tracking case.

A distinct property of physical states,such as the location, shape, and motionof objects, is continuity in space and time.We typically handle the sensing and con-trol of these states through sequentialstate updates. System theories, the basisfor many signal processing and controlalgorithms, provide the following state-centric abstraction for state updating:

xk+1 = f(xk, uk) (1)yk = g(xk, uk) (2)

52 PERVASIVEcomputing http://computer.org/pervasive

S E N S O R A N D A C T U AT O R N E T W O R K S

Tracking follower node

Tracking leader node

Sensor nodes

Tracking group

Figure 1. Collaborative processing in a leader-based object-tracking scenario. As a vehicle moves through a sensor field,nearby sensors detect it. An electedleader node aggregates data from the active sensors and migrates the information from node to node as thevehicle moves.

where x is the system state, k is an inte-ger update index over space or time, u isinput, y is output, f is the state updatefunction, and g is the output or observa-tion function. This formalization is broadenough to capture a wide variety of algo-rithms in sensor fusion, signal processing,and control (for example, Kalman filter-ing, Bayesian estimation, system identifi-cation, feedback control laws, automata,and so on). State-centric programmingabstractions have been successfullyapplied to synchronous VLSI circuit de-signs and (centralized) control system de-signs. Synchronous languages such as Sig-nal (www.irisa.fr/espresso/Polychrony)and Esterel (www.sop.inria.fr/esterel.org)and mixed-signal visual languages such asMatlab’s Simulink (www.mathworks.com)and Ptolemy II’s CT Domain (ptolemy.eecs.berkeley.edu) are all examples ofstate-centric programming models.

However, in a distributed real-timeembedded system, the formulation is notas cleanly represented as in the abstrac-tion just given. The relationship amongsubsystems can be highly dynamic. Wemust address concerns such as

• Where are the state variables stored?• Where do the inputs come from?• Where do the outputs go?• Where are the functions f and g

evaluated?• How long does it take to acquire the

set of inputs?• Are the inputs in uk acquired syn-

chronously?• Do the inputs arrive in the correct

order through communication?• What is the choice of the update

interval? Are they consistent?

System designers cannot be entirelyshielded from these issues without seri-ously compromising system correctnessand efficiency. These concerns addresswhere and when, rather than how, toperform sensing, computation, and actu-ation, and play a central role in achiev-ing the overall system performance.However, traditional programming mod-els and languages don’t support these“nonfunctional” aspects of computation(related to concurrency, reactiveness, net-working, and resource management)well. We need novel design methodolo-gies and frameworks that provide mean-ingful abstractions for these issues, sothat domain experts can continue toexpress algorithms and write programsin the style of these abstractions but stillmaintain an intuitive understanding ofwhere and when to perform these oper-ations. Domain-specific runtime systemsare to support this design methodologyto ensure correct and efficient executionand allow transparent layering-in of features such as security and reliablecommunication.

Collaboration groupsThe abstraction we provide is the

notion of collaboration groups (or groupsfor short). A group is a set of entities that

contribute to a state update. These entitiescan be physical or logical sensor nodes ormore abstract system components suchas software agents. In this context, werefer to them all as agents.

Intuitively, a group encapsulates twoproperties: its scope and its structure. Agroup’s scope defines its members. Youcan specify a scope existentially or by amembership function (for example, allnodes within some geometric range, allnodes within a certain number of hopsfrom an anchor node, or all nodes thatare “close enough” to a temperature con-tour). Grouping nodes according to phys-ical attributes rather than node addressesis an important abstraction in sensor net-work programming. You can evaluatescope locally or dynamically, as long asyou maintain communication among thegroup members as needed. Scoping iscritical to maintain scalability as sensornetworks grow arbitrarily large.

A group’s structure defines the roleseach member plays in the group. Do allgroup members have equivalent roles?Is there a “leader” member that con-sumes data? Do group members form atree with parent and children relations?The notion of roles shields programmersfrom addressing individual nodes byeither name or address. In fact, in most


Sensor

Networkconnection

Figure 2. Collaborative processing in detecting a contour of physical phenomena, such as a temperature field.The green nodes, which are inside andimmediately adjacent to the contour, actas surrogates for the contour, each storing local information about contourcrossings.

sensor network applications, neithername nor address is important. Redun-dancy by having multiple members withthe same role also improves applicationrobustness over node and link failures.Another advantage of the notion of rolesis that you can induce communicationand control patterns from them, so thatyou can implement highly optimized net-working and control flow protocols atruntime to support group execution.

Formally, a group is a 4-tuple

G = (A, L, p, R)

where A is a set of agents; L is a set oflabels, called roles; p : A → L is a function

that assigns each agent a role label; andR ⊆ L × L are the connectivity relationsbetween roles. Given the relationsbetween roles, a group can induce alower-level connectivity relation E amongthe agents such that ∀ a, b ∈ A, if (p(a),p(b)) ∈ R, then (a, b) ∈ E. For example,under this formulation, the leader-follower structure defines two roles L ={leader, follower} and a connectivity rela-tion R = {(follower, leader)}, meaningthat the follower sends data to the leader.Then, by specifying one leader agent andmultiple follower agents within a geo-graphical region (that is, specifying a mapp from a set of agents A to labels in L), wehave effectively specified that all follow-ers send data to the leader withoutaddressing the followers individually.

At runtime, the scope and structuraldynamics of groups are managed bygroup management protocols, which arehighly dependent on the types of groups.A detailed specification of group man-agement protocols is beyond this article’s

scope, but we can provide examples anddiscuss several protocols at a high level.

Examples of groupsCombinations of scopes and struc-

tures create generic patterns of groupsthat could be highly reusable from appli-cation to application. Here, we give afew examples of groups to illustrate theirwide variety and the importance of beingable to mix and match them in applica-tions. We classify the groups by theirscopes. Within each type of group, theremight be more than one structure. Forexample, a group defined by a geograph-ical region might have a single leader(that is, a leader-follower group), multi-

ple concurrent leaders (a multileadergroup), or no leader at all.

Geographically constrained group (GCG).A GCG consists of a set of nodes locatedwithin some fixed geographical region(the group’s extent). Because physical sig-nals, especially those from point targets,usually attenuate with distance, this typeof group naturally captures the set of sen-sors that can possibly sense a local phe-nomenon. There are many ways to spec-ify the GCG’s geographic shape, such ascircles, polygons, and their unions andintersections. You can easily establish aGCG by geographically constrainedflooding, using protocols such as Geo-casting7 and GEAR to support commu-nication among members. A GCG maydesignate a leader, which fuses informa-tion from all other group members.

N-hop neighborhood group (n-HNG).When the communication topology ismore important than the geographical

extent, we can define scope in terms ofhop counts. We define the members ofan n-HNG as the set of all nodes withinn communication hops from a specifiedanchor node. Because local broadcast-ing uses hop counts rather than Euclid-ean distances, it can be conveniently usedto determine the scope. Usually, theanchor node is the group leader. Thegroup might have a tree structure withthe leader as the root to optimize com-munication. If you can decompose theleader’s behavior into suboperations run-ning on each node, then the tree struc-ture also provides a platform for dis-tributing the computation.

There are several useful special casesfor n-HNG. For example, 0-HNG con-tains only the anchor node itself, 1-HNGsare the anchor node’s one-hop neigh-bors, and ∞-HNG contains all the nodesreachable from the root. From this pointof view, TinyDB is built on an ∞-HNGgroup.2

Publish/subscribe group (PSG). You canalso define a group more dynamically,such as all entities that can provide cer-tain data or services or that satisfy cer-tain predicates over its observations orinternal states. A PSG consists of oneor more consumers expressing interestin specific types of data or services andthe zero or more producers that pro-vide those. You can establish a PSG viarendezvous points, directory servers,or network protocols such as directeddiffusion.8

Acquaintance group (AG). Even moredynamic is the AG, where a memberbelongs to the group because anothergroup member “invited” it. The rela-tionships among the members might bepurely logical and historical rather thandepending on any physical properties atthe time. A member may quit the groupwithout needing any other member’spermission but might have to “clean up



Having multiple members with the same role

also improves application robustness

over node and link failures.

after itself” to keep from severing othermembers from the group. An AG mighthave a leader serving as the rendezvouspoint. When the leader is also fixed on anode or in a region, GPSR (greedy perime-ter stateless routing),9 ad hoc routingtrees, or directed-diffusion types of pro-tocols can facilitate communicationbetween the leader and the other mem-bers. An obvious use of this group is tomonitor and control mobile agents froma base station. When all group membersare mobile and no central leader exists,maintaining group connectivity mightbecome quite complex.

Using multiple groupsDespite the fact that there are efforts

to provide a single unified collaborationmodel for all DSAN applications, webelieve that mixing and matching mul-tiple group classes is a more powerfultechnique to tackle system complexity,matching information flow closely to the

algorithm designer’s conceptual modelof information flow without sacrificingscalability or efficiency. Even within aparticular type of group, you can selecthighly tuned communication protocolsfor a specific application to reducelatency and energy cost while maintain-ing the same clear mental model of infor-mation flow.

There are various ways to composegroups. You can do so in parallel to pro-vide different types of input for a singlecomputational entity. For example, in theprevious point target-tracking example,you could use a GCG to gather sensormeasurements and a 1-HNG to select thepotential next leader. You can also com-pose groups hierarchically such that onegroup contains another (or its represen-tative member). For example, while usingmultiple groups to compute target tra-jectory, all tracking leaders of various tar-gets might form a PSG with the base sta-tion to report tracking results.

A state-centric designframework

We implement the methodology ofstate-centric programming over collab-oration groups in a PARC-developedsoftware environment called PIECES (Pro-gramming and Interaction Environmentfor Collaborative Embedded Systems) tohelp model, simulate, design, and deploysensor network applications. So far,we’ve supported the modeling and sim-ulation capabilities of PIECES in a mixedJava-Matlab environment, and we’vedemonstrated these capabilities on achallenging multitarget-tracking simu-lation with realistic sensor and environ-ment models. We’re still designing a run-time execution platform that directlysupports our methodology.

Programming modelFigure 3 shows the basic entities in

PIECES and their relationships. In PIECES,programmers think in terms of dividing


ContaineeContainer

0..*

0..* Host

Host

Hostee

0..*

1

1

1

<<interface>>GeographicallyConstrainedGroup

+setGeoExtent(in geoExtent : Region)

<<interface>>NHopNeighborhoodGroup

...

+setHopCount(in count : int)

<<interface>>State

<<interface>>IOPortAgent

+fuse() : Data

<<interface>>OutputPortAgent

+observe() : Data

<<interface>>IntputPortAgent

+isInputReady() : Boolean+getIputs() : Data

SensorNode-location : Location-sensors : Collection-principals : Collection+sense(in sensor : Sensor) : Data+senseAll() : Data

<<interface>>PortAgent

+getHostPrincipal() : Principal+getContainer() : Group

<<interface>>Principal

+getState() : synchronized State+addPortAgent(in port : PortAgent)+removePortAgent(in agent : PortAgent)+initialize()+updateState() : synchronized void+destroy()+getHost() : SensorNode+moveTo(in group : Group, in utility : UtilityFunction)

<<interface>>Group

+getContainees() : Collection+getRoles() : Collection+getPrincipalsOfRole(in role : Role) Collection+sendToRole(in role : Role, in msg : Message)

Inheritance relations ofclasses or interfaces

Aggregation orcontaining relations

Figure 3. A UML diagram for the base classes and interfaces in PIECES. A principal may host zero or more port agents, while each portagent is contained by exactly one group.

the global state of physical phenomenainto a hierarchical set of independentlyupdatable pieces with one computa-tional entity (called a principal) main-taining each piece. To update the state,principals can request inputs from otherprincipals, with sensing principals sup-porting the lowest-level sensing and esti-mation tasks. Communication patternsare specified by defining collaborationgroups over principals and assigning cor-responding roles for each principalthrough ports. Principals may movefrom node to node to improve perfor-mance and reduce the cost of sensing,computation, and communication. Withgroup-level support, application devel-opers can focus on implementing thestate update functions as if they werecentralized programs.

Principals and port agents. The frameworkcomprises two key components, princi-pals and port agents, as Figure 4 shows.

A principal encapsulates a piece ofstate. Typically, these states correspond tocertain aspects of the physical phenom-ena of interest. (From a computationalperspective, a port agent as an object cer-tainly has its own state, but the distinc-tion here is that these states are not asso-ciated directly with physical phenomena.)The role of a principal is to update its statefrom time to time, a computation corre-sponding to evaluating function f in Equa-tion 1. A principal also accepts other prin-cipals’ queries of certain views on its own

state, a computation corresponding toevaluating function g in Equation 2.

To update its portion of the state, aprincipal can gather information fromother principals. When a principal needsinformation from other principals, it cre-ates port agents and attaches them ontoitself and onto the other principals. Aport agent can be an input, an output,or both. An output port agent is alsocalled an observer, because it computesoutputs on the basis of the host princi-pal’s state and sends them to otheragents. Observers might be active, push-ing data autonomously to its destina-tions, or passive, sending data only whenthe consumer sends a query. A principaltypically attaches a set of observers toother principals, and creates a local inputport agent to aggregate the informationcollected by the remote agents. Thus,port agents capture communication pat-terns among principals.

Note the separate executions of princi-pals and observers. Principals maintainstates, reflecting physical phenomena.These states can be updated rather thanrediscovered, because the underlyingphysical states are typically continuous intime. How often the principal states mustbe updated depends on the dynamics ofthe phenomena or physical events. Theexecutions of observers, however, reflectthe demands of the outputs. If an outputisn’t currently needed, there’s no need tocompute it. The notion of “state” effec-tively separates these two execution flows.

To ensure consistency of state updateover a distributed computational plat-form, PIECES requires that a piece of state,say S, can only be maintained by exactlyone principal. This doesn’t prevent otherprincipals from having local caches of Sfor efficiency and performance reasons,

nor does it prevent the other principalsfrom locally updating the values of cachedS. However, there is only one “mastercopy” for S, all local updates should betreated as “suggestions” to the mastercopy, and only the principal that owns Shas the final word on its values. Thisasymmetric access of variables simplifiesthe way shared variables are managed.

Principal groups. Principals can formgroups. A group gives its members a wayto find other relevant principals andattach port agents to them. A principalmay belong to multiple groups. A portagent, however, serving as a proxy for aprincipal to the group, can only be asso-ciated with one group.

An application can delegate group cre-ation to port agents, especially for leader-based groups. The leader port agent, typ-ically of type input, can be created on aprincipal, and the port agent can takegroup scope and structure parameters tofind the other principals and create fol-lower port agents on them. You can cre-ate groups dynamically on the basis ofprincipals’ collaboration needs. For exam-ple, when a principal responsible fortracking a target finds more than one tar-get in its sensing region, it can create aclassification group to fulfill the need forclassifying targets. A group might have alimited time span. When certain collab-orations aren’t needed, their corre-sponding groups can be deleted.

A group’s structure allows its membersto address other principals through theirroles rather than their names or logicaladdresses. For example, the only inter-face that a follower port agent in aleader-follower structured group needs isto send data to the leader. If the leadermoves to another node while a datapacket leaves a follower agent, the groupmanagement protocol should take care ofthe dangling packet, either delivering it tothe leader at the new location or simplydiscarding it. This kind of leader-follower



y = g(x)

State: x

x | = f (x, u)

u

z = h(x, v)I/Oport

agent

Input port agent

Outputport

agent

Principal

Figure 4. A principal and its port agentsin PIECES. The principal maintains state xand updates it through the evaluation off. The input port agent provides the inputdata for this update. Output port agentsor I/O port agents can be attached to theprincipal to produce g(x) or h(x, v).

group management protocol is built ontop of data-centric routing and storageservices such as diffusion routing and geo-graphic hashing tables,10 whose imple-mentation details are beyond the scopeof this article.

Mobility. A principal is hosted by a spe-cific network node at any given time.The most primitive type of principal is asensing principal, which is fixed to a sen-sor node. A sensing principal maintainsa piece of (local) state related to the phys-ical phenomena, based solely on its ownlocal sensor measurement history. Al-though a sensing principal is constrainedto never move, other principals might beimplemented as software agents thatmove from host to host, depending oninformation utility, performance require-ments, time constraints, and resourceavailability. A principal P might also beattached to another principal Q in thesense that P moves with Q. When a prin-cipal moves, it carries its state to the newlocation, and the scopes of the groups itbelongs to change accordingly.

Mobile principals bring additional chal-lenges for maintaining the state. Forexample, a principal should not movewhile it is in the middle of updating thestate. To ensure this, PIECES restricts thatwhenever an agent is triggered, its execu-tion must reach a quiescent state withoutfurther blocking on either input data orcomputation or sensing resources. Sucha trigger is called a responsible trigger.11

Only at these quiescent states can princi-pals move to other nodes in a well-definedway, carrying the minimum amount ofinformation representing the phenomena.

SimulatorPIECES provides a mixed-signal simula-

tor that simulates sensor network appli-cations at a high level. We implementedthe simulator using Java and Matlab andbuilt an event-driven engine in Java tosimulate network message passing and

agent execution at the collaborationgroup level. Our continuous-time engine,built in Matlab, simulates target trajecto-ries, signals, noise, and sensor front ends.The main control flow is in Java, whichmaintains the global notion of time. Theinterface between Java and Matlab alsomakes it possible to implement functionalalgorithms such as signal processing andsensor fusion in Matlab, while leavingtheir execution control in Java. A three-tier distributed architecture is designedthrough Java registrar and remote-method-invocation interfaces, so that theexecution in Java and Matlab can be sep-arately interrupted and debugged.

Like most network simulators such asns-2 (www.isi.edu/nsnam/ns), the PIECES

simulator maintains a global event queueand triggers computational entities—prin-cipals, port agents, and groups—via timedevents. However, unlike network simula-tors that aim to accurately simulate net-work behavior to the packet level, thePIECES simulator verifies CSIP algorithmsin a networked execution environment atthe collaboration group level. Althoughgroups must have distributed imple-mentations in real deployments, they arecentralized objects in the simulator. Theycan internally use instant access to anymember of any role, although these ser-vices are not available to either principalsor port agents. This relieves the burdenof developing, optimizing, and testing allthe communication protocols jointlywith the CSIP algorithms.

The PIECES simulator estimates com-munication delays by instantaneouslychecking the sender’s and receiver’s loca-tions and computing a randomized delaycorresponding to the group management

protocol. For example, if an output port ofa sensing principal calls sendToLeader(message)on its container group, then the groupobtains the sensor nodes that host thesensing principal and the destinationprincipal, computes the number of hopsbetween the two nodes specified by thegroup management protocol, and gen-erates a randomized delay and a bit errorbased on the number of hops.

Example: A multitargettracking system

We implemented a multiple-target-tracking algorithm with classificationand identity management to demon-strate how state-centric programmingsupports and modularizes the softwaredesign of DSAN applications. You canfind details of the algorithm with classi-fication12 and of identity management13

elsewhere.

Tracking, classification, and identity management

Multitarget tracking is the problem ofestimating the trajectories of multiple tar-gets from a time series of sensor mea-surements, possibly from multiple sen-sors. In single-target tracking, the problemis usually posed as a dynamic estimationproblem of a partially observable Markovprocess, and a Bayesian recursive filterprovides the solution. In multiple-targettracking, in addition to the estimationproblem of tracking each individual tar-get, there is the additional difficulty ofidentifying which track estimate shouldbe associated with which target.

To illustrate this data association prob-lem, we consider the scenario shown inFigure 5. When two targets come near


Figure 5. Data association problem: asmultiple objects come close to eachother, the sensor system must properlyassociate measurements with hypothesesof objects to identify them. Without discriminatory characteristics such ascolor, resolving whether the vehicles havecrossed paths or merely passed by eachother is impossible.

each other in space, an ambiguity mightoccur: either the targets actually crosspaths or they approach each other andthen diverge. Without further evidenceregarding the target identities, the bestwe can do in this case is to explicitlyquantify the degree of ambiguity so thatthe tracker doesn’t falsely conclude thatthe two targets have either crossed pathsor merely passed by each other.

In practical situations, we can oftendistinguish two targets from each otheron the basis of their signal features. Aclassification algorithm can extract dis-criminatory information and make infer-ences about target identity. With a clas-sifier’s help, an identity managementalgorithm can help resolve data associa-tion ambiguities. Figure 6 presents anexample scenario. When targets diverge,the tracking system can collect classifi-cation evidence. Such evidence shouldupdate the identity of both the localtrack and the remote track with whichthe local track has been mixed. Identitymanagement is responsible for main-taining this global consistency of identi-ties among tracks.

Implementing such a system using anode-centric programming interface is

extremely complicated. We can designthe trackers as mobile agents that followtargets.4 However, each tracker mustrespond to many kinds of events, suchas aggregated sensor data from nearbynodes, handoff messages from one ormore track leaders, suppression messagesto prevent it from initiating duplicate tar-gets, classification data from differentkinds of sensors, identity informationrequests from other agents, identityupdate information from other agents,multiple kinds of handshaking messages,and so on. Worse, these messages areinterleaved because of agents’ concur-rent progression and the communicationuncertainties. The logic that reacts tothese messages must cover all the com-binations of ordering of events. If theagents are built using flat FSMs, thenumber of states and transitions quicklybecomes unmanageable.

Distributed implementation in PIECES

In terms of the states of the physicalphenomena, the user cares about twokinds of target information in this appli-cation: the targets’ positions and identi-ties. We can estimate positions by fusingthe energy measurements from the sen-

sors near the targets. We can update theidentity information by either local clas-sification or identity management acrosstracks. We have designed the PIECES sys-tem as a set of communicating multipletarget trackers (MTTrackers), where eachtracker maintains the trajectory and iden-tity information about a target or a set ofspatially adjacent targets. An MTTrackeris implemented by three principals: atracking principal, a classification prin-cipal, and an identity management prin-cipal (see Figure 7).

A tracking principal updates the trackposition state periodically. It uses a GCGwith a leader-follower relation to collectprimitive local-position estimates fromother sensors close to the target. Thetracking principal is the leader, and allsensing principals within a certain geo-graphical extent centered around the cur-rent target position estimate are the fol-lowers. The tracking principal also makeshopping decisions on the basis of its cur-rent position estimate and the node char-acteristic information collected from itsone-hop neighbors via a 1-HNG.

Figure 8 shows sections of the Tracking-Principal code in PIECES. When the principalis initialized, it creates the agents and cor-responding groups. Behind the scene, thegroups create follower agents with spe-cific types of outputs, indicated by the sen-sor modalities. Without further instruc-tions from the programmer, the followersperiodically report their outputs to theinput port agents. Whenever the princi-pal is activated by a time trigger, itupdates the target position using thenewly received data from the followersand selects the next hosting node on thebasis of neighbor node characteristics.

Both the classification principal and theidentity management principal operate onthe identity state, with the identity man-



?

1. Classificationperformed in regionwith color cameras.Vehicles classifiedby type and color.

2. Vehicles enter region withgray-scale cameras.

3. Vehicles cross. Data associationambiguity encoded.

4. Vehicles diverge spatially,but identity is ambiguous.

6. Identity management reasonsthat the other car must be the yellow car.

??5. One vehicleenters region witha color camera andis detected to bethe blue car.

Figure 6. Identity management scenario:when two vehicle trajectories cross undera gray-scale camera, their identities aremixed. When we expose one vehicle to acolor camera to reveal its identity, we alsodetermine the other vehicle’s identity.

agement principal maintaining the “mas-ter copy.” In fact, an MTTracker createsthe classification principal only when tar-gets must be classified, and it “suggests”its computational results to the identitymanagement principal. The classificationprincipal uses a GCG to collect class fea-ture information from nearby sensingprincipals in the same way that trackingprincipals collect location estimates.

The identity management principalforms an AG with all other identity man-agement principals that might have rel-evant identity information. They becomethe member of a particular identitygroup only when targets intersect andtheir identities mix. Both classificationprincipals and identity managementprincipals are attached to the trackingprincipal for their mobility decisions.However, the formation of an AGamong these three principals also pro-vides the possibility that they can maketheir own hopping decisions withoutchanging their interaction interface.

SimulationFigure 9 shows the progression of

tracking two crossing targets. The smallsquares represent sensor nodes, the linesrepresent vehicle trajectories, coloreddots represent the current beliefs of vehi-cle positions, and the vehicles’ identitiesare depicted using green and red. Ini-tially, when the targets are well sepa-rated, as in Figure 9a, each target istracked by a tracker whose sensinggroup is pictured as a shaded disk. Thehosting node of the tracking principal isplotted in light blue, and the hosts forcorresponding sensing principals areplotted in white. Since the targets are

well separated, each identity group con-tains only one member, the identitymanagement principal of a tracker. Asthe targets move toward the center ofthe sensor field, the sensing groups movewith their respective track positions.

In Figure 9b, the two separate trackinggroups have merged. A joint trackingprincipal, now hosted by the yellow node,updates tracks for both targets. The sys-tem merges the tracks because trackingthe targets jointly, rather than indepen-dently, when they approach each other ismore accurate owing to the effect of sig-nal superimposition. Finally, as the tar-gets diverge, the merged tracking groupand tracking principals split into two,

and each tracking principal proceeds totrack one target separately as shown inFigure 9c. At this point, the targets’ iden-tities are mixed, so the system creates anidentity group containing the two track-ers’ identity management principals.

Figure 10 shows a snapshot of a morecomplicated multitarget crossover sce-nario. Three tracks (whose identities aredepicted using red, green, and yellowrespectively in Figure 10a) have crossedeach other in the past, so their identitiesare mixed. The corresponding identitymanagement principals form an identitygroup. At the time of this snapshot, theidentity management principal in thebottom-right corner is collecting classi-


Localestimations

Sensing principal

Localestimations

Sensing principal

Remoteidentities

Localidentity

Identity management principal

LocalidentityPosition

Tracking principal

TF: TrackFollowerHF: HandoffFollowerCF: ClassFollower

SharedCopy

SharedOriginal

SharedOriginal

Multiple target tracker

Geographicallyconstrained

groupGeographically

constrainedgroup

1-hopneighborhood

group

Acquaintancegroup

Remoteidentities

Localidentity

Identity management principal

Localidentity

Classification principal

SharedCopy

SharedCopy

HandoffLeader

SharedCopy

ClassLeader

TrackLeader

Localestimations

Sensing principal

TF TF HF TF HF CF

Figure 7. The distributed multiobjecttracking algorithm as implemented in the state-centric programming model,using distributed principals and agents.Notice that the state-centric model lets developers focus on key pieces of stateinformation that the sensor networks aretrying to create and maintain, thus raising programming’s abstraction level.

fication information and identifying thetrack as the red target. So, it communi-cates with its peers in the identity man-agement group (top-right and bottom-middle principals) to update theirrespective targets’ identities as well. Thebar chart in Figure 10b shows theupdated identity. Defining the acquain-

tance group and its interface in this wayallows these spatially distributed iden-tity management principals to commu-nicate with each other. This gives devel-opers the necessary abstraction to focuson the functional aspect of identity man-agement algorithms without worryingabout communication details.

What should be the appro-priate programming mo-dels for DSAN applica-tions? Is a network simply

wireless “wires” that can ship one sen-sor’s reading to another? Is a sensor net-work a distributed database, reducingprograms to filters and queries on thedata? We have presented a methodol-ogy that views a sensor network as adistributed platform for in-network sig-nal and information processing. Mobileprincipals, each maintaining a portionof the state of the physical phenomenaof interest, interact with each otherthrough collaboration groups. Havingwell-encapsulated state variables up-dated by the execution of principalsgives designers a natural abstractionthat is close to those of system theories.Mobility lets principals follow the phe-nomena spatially, minimizing latencyand resource consumption. Theabstraction of collaboration groupsshields designers from complicatedcommunication protocol managementand event-handling issues while sup-porting a rich variety of models ofcross-node interaction.

We’re still implementing the state-centric programming methodology inPIECES, especially the specific types ofgroup interaction protocols, the resourceallocation mechanisms, and the runtimesupport systems. However, we believethat this is an important first step in for-mulating and understanding the modelsof collaboration among distributedagents and the programming of collec-tives for sensing, computation, and con-trol applications in DSAN systems.



Figure 8. Sections of TrackingPrincipalcode illustrating the creation of multiplegroups to collect inputs for the trackingprincipal. PIECES computes the state estimate and then inserts it into the track()

function without considering where theinputs are collected from.

public class TrackingPrincipal extends MobilePrincipal {...private InputPortAgent _sensingAgent;private InputPortAgent _handoffAgent;private BeliefState _trackBelief;private UtilityFunction _utilityFunction = new InformationUtility();...public void initialize() {

// This principal is the client of the sensing agent._sensingAgent = new InputPortAgent(this);// Create a GCG with a geometric extent to specify the scope// the _sensingAgent as the leader, a follower sensing type,// and a follower report period.GeoConstrainedLeaderGroup sensingGroup = new

GeoConstraintedLeaderGroup(geometricExtent, _sensingAgent,energySensorClass, reportPeriod1);

//This principal is the client of the handoff agent._handoffAgent = new InputPortAgent(this);// Create a 1-HNG with the _handoffAgent as the leader,// a follower sensing type, and a follower report period.HopNeighborhoodGroup handoffGroup = new

HopNeighborhoodGroup(1, _handoffAgent,nodeCharacteristicsSensorClass, reportPeriod2);

}

// The principal is awakened every 1 second by a time trigger.public void react(WakeupEvent event) {

//Compute the new target belief state.updateState();//Choose the next host of this principal.moveTo(_handOffGroup, _utilityFunction));

}

// Key function to update the state of the track.public synchronized void updateState() {

if(_sensingAgent.isInputReady()) {_trackBelief = track(_trackBelief, _sensingAgent.getInputData());

}}

...}

ACKNOWLEDGMENTSThis work is partly supported by DARPA under con-tract F30602-00-C-0139 through the Sensor Infor-mation Technology Program. We also thank DanLarner and Jaewon Shin for inspiring discussionsand help in implementing the multitarget-trackingexample discussed here.


Figure 9. Tracking two simulated crossing targets. The small squares represent sensor nodes, the lines represent vehicle trajectories,colored dots represent the current beliefs of vehicle positions, and the vehicles’ identities are depicted using green and red. (a) Pieces creates the geographical constrained group for each target. (b) When the two targets cross, their groups merge. (c) Thegroup splits as the targets diverge.

(b) (c)(a)

(b)(a)

1.0

0.5

0

1.0

0.5

0

1.0

0.5

0

1.0

0.5

0

Figure 10. Simulation results for trackingfour moving targets. After the red, green,and yellow targets mixed in the past, theacquaintance group is established for identity management. When new identityinformation is collected, a distributedrenormalization across this group resolvesthe target identities. (a) The tracker groupand tracking results. (b) Bar charts of eachtrack’s identity after renormalization.

REFERENCES1. D. Estrin et al., “Next Century Challenges:

Scalable Coordination in Sensor Net-works,” Proc. 5th Ann. ACM/IEEE Int’lConf. Mobile Computing and Networking(ACM/IEEE MobiCom 99), ACM Press,1999, pp. 263–270.

2. S. Madden, M.J. Franklin, and J.M. Heller-stein, “Tag: A Tiny Aggregation Service forAd-Hoc Sensor Networks,” Proc. 5th Symp.Operating Systems Design and Implemen-tation (OSDI), USENIX, 2002.

3. J. Liu et al., “Distributed Group Manage-ment for Track Initiation and Maintenancein Target Localization Applications,” Proc.2nd Int’l Workshop Information Process-ing in Sensor Networks (IPSN 03), LNCS2634, Springer-Verlag, 2003.

4. Y. Yu, R. Govindan, and D. Estrin, Geo-graphical and Energy Aware Routing: ARecursive Data Dissemination Protocolfor Wireless Sensor Networks, tech. reportUCLA/CSD-TR-01-0023, Computer Sci-ence Dept., Univ. of California, Los Ange-les, 2001.

5. M. Chu, H. Haussecker, and F. Zhao, “Scal-able Information-Driven Sensor Queryingand Routing for Ad Hoc Heterogeneous Sen-sor Networks,” Int’l J. High-PerformanceComputing Applications, vol. 16, no. 3, Fall2002, pp. 90–110.

6. J. Liu, J.E. Reich, and F. Zhao, “Collabo-rative In-Network Processing for TargetTracking,” EURASIP J. Applied Signal Pro-cessing, vol. 2003, no. 4, Mar. 2003, pp.378–391.

7. Y.-B. Ko and N.H. Vaidya, “Geocasting inMobile Ad Hoc Networks: Location-BasedMulticast Algorithms,” Proc. IEEE Work-shop Mobile Computer Systems and Appli-cations, IEEE Press, 1999.

8. C. Intanagonwiwat, R. Govindan, and D.Estrin, “Directed Diffusion: A Scalable andRobust Communication Paradigm for Sen-sor Networks,” Proc. 6th Ann. Int’l Conf.Mobile Computing and Networking (Mobi-Com 00), IEEE Press, 2000.

9. B. Karp and H.T. Kung, “Greedy Perime-ter Stateless Routing for Wireless Net-works,” Proc. 6th Ann. Int’l Conf. MobileComputing and Networking (MobiCom00), IEEE Press, 2000.

10. S. Ratnasamy et al., “GHT: A GeographicHash Table for Data-Centric Storage,”Proc. 1st ACM Int’l Workshop WirelessSensor Networks and Applications (WSNA2002), Sept. 2002, pp. 78–87.

11. J. Liu, Responsible Frameworks for Het-erogeneous Modeling and Design of Embed-ded Systems, PhD dissertation, Univ. of Cal-ifornia, Berkeley, 2001.

12. M. Chu, S. Mitter, and F. Zhao, “Distrib-uted Multiple Target Tracking and DataAssociation in Ad Hoc Sensor Networks,”Proc. 6th Int’l Conf. Information Fusion,2003.

13. J. Shin, L. Guibas, and F. Zhao, “A Dis-tributed Algorithm for Managing Multi-Target Identities in Wireless Ad-Hoc Sen-sor Networks,” Proc. 2nd Int’l WorkshopInformation Processing in Sensor Net-works, 2003.

For more information on this or any other comput-ing topic, please visit our Digital Library at http://computer.org/publications/dlib.



the AUTHORS

Jie Liu is a member of the research staff at the Palo Alto Research Center. His re-search interests include software architectures; programming models; simulationand synthesis tools; ad hoc networking; mixed-signal and hybrid systems; and theirapplication in modeling, simulation, and design of distributed real-time embeddedsystems. He received his PhD in electrical engineering and computer sciences fromthe University of California, Berkeley. He is a member of the IEEE and the ACM. Con-tact him at PARC, 3333 Coyote Hill Rd., Palo Alto, CA 94304; [email protected].

Maurice Chu is a member of the research staff at the Palo Alto Research Center inthe Embedded Collaborative Computing area of the Systems and Practices Labora-tory, where he investigates the development of efficient inference and estimationapplications for sensor network technology. He received his PhD in electrical engi-neering and computer science from MIT. His research interests include distributedinformation processing, communications and information theory, graphical models,learning and inference, and recognition in vision systems. Contact him at PARC,3333 Coyote Hill Rd., Palo Alto, CA 94304; [email protected].

Juan Liu is a member of the research staff at the Palo Alto Research Center. Herresearch interests include signal processing, statistical modeling, detection and esti-mation, network routing, information theory, and their applications to distributedsensor networks. She received the 2002 IEEE Signal Processing Society Best PaperAward for Young Authors and is a member of the IEEE. She received her PhD in elec-trical engineering from the University of Illinois, Urbana-Champaign. Contact her atPARC, 3333 Coyote Hill Rd., Palo Alto, CA 94304; [email protected].

James Reich is a member of the research staff at the Palo Alto Research Center. Hisresearch focuses on scalable collaborative signal processing approaches and program-ming models for real-time in-network processing of sensor data. He received his MS inelectrical and computer engineering from Carnegie Mellon University. He is a mem-ber of the IEEE. Contact him at PARC, 3333 Coyote Hill Rd., Palo Alto, CA 94304;[email protected].

Feng Zhao is a principal scientist at the Palo Alto Research Center, where he directsthe Embedded Collaborative Computing Area in the Systems and Practices Labora-tory. He is also a consulting associate professor of computer science at Stanford Uni-versity. His research interests include networked embedded systems, model-baseddiagnosis, qualitative reasoning, control of dynamical systems, and programmingtools. He is the founding editor in chief of the ACM Transactions on Sensor Networks.He received his PhD in electrical engineering and computer science from MIT. Con-tact him at PARC, 3333 Coyote Hill Road, Palo Alto, CA 94304; [email protected].

state-centric programming for sensor-actuator network systems · as information-driven sensor...

Documents