A Rule-Based Middleware Architecture

8/13/2019 A Rule-Based Middleware Architecture

1/8

FACTS A Rule-based Middleware Archi tectu re

for Wireless Sensor Networ ks

Kirsten Terfloth

Freie Universitt BerlinTakustr. 9

14195 Berlin+49 (0) 30 838 75211

[email protected]

Georg Wittenburg


14195 Berlin+49 (0) 30 20256233

[email protected]

Jochen Schiller


14195 Berlin+49 (0) 30 838 75211

[email protected]

ABSTRACT Introducing a middleware abstraction layer into wirelesssensor networks is a widely accepted solution to facilitateapplication programming and allow network organization.In this paper, we argue that although an event-basedapproach is the most obvious solution, it also provides themost natural way to address software development inwireless sensor networks. As a proof of concept, weintroduce FACTS, a very flexible middleware frameworkable to provide support for a wide range of differentapplications. The objective is to combine advantages ofevent-centric processing and rule-based execution while

preserving low resource usage.

Keywords Wireless sensor networks, middleware, event-centricarchitecture, rule-based language, qualitative simulation

1. INTRODUCTIONWireless sensor networks (WSN) comprise a variety offeatures that make software development in this domainrather challenging. Dealing with embedded devices in largenumbers, each of which is prone to error and very restrictedin terms of energy, memory and processing powerintroduces a burden upon the application development.Moreover, the distribution of nodes and their sharedcommunication medium call for multi-hop routingalgorithms and distributed coordination among them. Theintroduction of a middleware layer can alleviate problemsarising from both complex communication and data sharingmethods as well as those that originate at the underlyingsoftware layer.Since the deployment of a middleware layer inevitablyconsumes memory, a decision whether to use this kind ofabstraction has to be deliberated carefully. The moregeneric such a middleware layer, the more likely it is to beused in diverse application scenarios. Furthermore, a clearabstraction model able to combine benefits for supporting

both distribution issues and embedded programming isneeded. A number of solutions have already beensuggested, ranging from tiny enhancements for

programming [1] to full-fledged middleware architectureswith rich sets of services [2, 6, 9].In the latest discussions it has been argued, that event-driven programming is rather complicated from anapplication programmers point of view. Asynchronouswake-ups related to the occurrence of state changes, the

need for non-blocking calls to enable execution andcoordination of multiple events, and the necessary means tomaintain state seem backward to usual imperative

programming. On the other hand, an event-driven paradigmsuites the application domain best: sensor nodes aresupposed to detect certain changes in their environment,react to them appropriately and remain in low-power modein case of absence of events or tasks. Hence, a triggeredaction, thus a push mechanism, is a more natural way tothink of programming for sensor networks.The middleware architecture we introduce in this paper

provides a powerful mental model that emphasizes the useof trigger mechanisms and actions. Combining the

advantages of virtual machines, grouping facilities andmodularity-based approaches as described in [10], andinspired by expert-systems [12], our main abstraction arerules , facts and functions . In this context information which is everything ranging from sensor readings totemporary variables is represented as facts, which arestored in a fact repository and processed by rules. In otherwords, rules encode the information processing relevant toa specific application and are written in a high-levellanguage consisting of the triggering conditions and theactions to be taken accordingly. In contrast to inferenceengines using backward chaining, our rule engine , which isthe scheduling entity for rules, uses forward chaining in

order to provide event-like semantics. Rules may also callfunctions that hook into the firmware or operating systemof the sensor node and perform resource critical operationsin a fast and memory-efficient manner.Facts, rules and functions are local to each node of thesensor network and each node runs its own rule engine.However, facts are also used as the key abstraction fortransmitting information from one node to another, to theentire sensor network, or to a distinct subgroup. Hence, onecan think of it as a node sending one of the facts from its
mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]


2/8

own fact repository to another node, which in turn adds itto its fact repository. Due to the reception of the fact on itsradio interface, the middleware is aware of not being theowner or originator of this fact. However, there is nofurther distinction made between locally created facts andthose received from other nodes over the network.

The rest of this paper is organized as follows: First, weestimate FACTS concepts in the context of current researchactivities. Section 3 describes the main architecture ofFACTS in detail and discusses design considerations,

before introducing the prototype implementation in Section4. A coverage algorithm is given in our rule language to

present the expressiveness of our programming abstractionin Section 5, and give a first impression of the overallsystem in practical use. A conclusion and outlook on futurework concludes this paper and once again summarizes thecontributions of our work.

2. RELATED WORKA number of approaches resemble FACTS in certainaspects. The SWARMS project [13] makes use of adistributed virtual shared information space (dvsIS), anadaptation of the Linda tuplespace, to share global stateamong all nodes. The idea of SWARMS is to provideglobal coordination, having the sensor nodes of thenetwork behave like members of a swarm. Elements of thisspace are qualified by XML tags, and are distributedamong swarm members. Our fact repository isimplemented to enable distributed shared memory, soapplications may use this in case they can benefit from it.Otherwise, it functions as local memory for state, data andvariables, and is thus the central coordination entity fornodes. This concept of variable usage is a lot more flexible,since it allows for application specific tuning instead of

predefined functionality.The Generic Role Assignment (GRA) project [4] makesuse of rules to encode node behavior. An algorithm isimplemented by specifying a set of roles a node can assignto itself depending on its local state and that of neighboringnodes. Therefore, a change in state may inherently result ina re-evaluation process of roles of a potentially large set ofnodes, and hence lead to massive communication betweennodes for coordination. Our approach also relies on statefulinformation, but decisions on event occurrence or statechanges have to be implemented by the programmerexplicitly, leading to a more controllable communication

pattern. Although GRA allows a higher abstraction fromcommunication issues, we believe that the domain of WSNdoes not allow making such subsumptions for developers.The introduction of new languages to implementapplications for WSN can be widely observed [3, 7, 11].Design goals combine offering a high-level languageconstruction tailored to domain specific needs and allowinginterpreted, dense byte-code to be deployed on the nodes.

Furthermore, interpretation of code may serve in acquiringmodularity of software components.

3. FACTS ARCHITECTURE

The architecture of FACTS will be introduced in thefollowing pages. To emphasize the issues that wereconsidered during the construction process, they will be

briefly presented in a motivating section.

3.1 MotivationThe main criteria for the design of our middlewarearchitecture are summarized in the following key points:

Event-centric architecture Rule-based language capturing trigger/action

semantics Minimalistic architecture, able to be enhanced at

runtime according to application-specific services Support for distributed shared memory to enable

grouping algorithms Support for cross-layer optimization

To reflect the event-centric domain of networked sensorsand benefit from the inherent data compression of an eventconcept, the middleware design uses the primaryabstraction of events which trigger actions. The overallsystem can therefore be implemented in a resource-awaremanner, allowing nodes to switch to low-power mode incase of absence of events. The formalization of rules is anatural way to express actions triggered by changes eitherin a nodes environment or internal state, or by any

combination of both. Therefore we chose to make explicituse of these semantics and defined a suitable language thatis concise and powerful, but also small in terms of memoryconsumption.As the goal is to allow sets of basic services, depending onthe envisioned application domain, to be implemented andadded to the middleware on demand. Hence, a modulardesign to obtain a highly flexible framework is also a keydesign aspect. Furthermore, the ability to easily share dataamong nodes for coordination algorithms has been provenuseful in WSNs [5]. Our fact repository with its ability toact as a distributed shared memory supports softwarerelying on any kind of grouping or clustering mechanism.

These features are not explicitly provided by FACTS to prevent the pollution of memory with unnecessary services, but can be added in a set of a few rules. Not only data sharing among different nodes of a networkcan be realized through the use of the fact repository ascentral data entity on a node. Algorithms operating ondifferent layers according to the ISO/OSI layering modelcan also exchange information to use it as means to


3/8

coordinate and tune themselves, enabling networkoptimization based on cross-layering.The middleware architecture of FACTS as shown in Figure1 has been designed to provide a highly flexible frameworkto cope with the limited resources inherent to theapplication domain of wireless sensor networks, butnevertheless equip a developer with a clear mental model.The fundamental concepts are introduced in followingsections.

3.2 RulesRules are used to express algorithms and reactions toexternal events in the system. A rule is a named structurecontaining both a set of conditions and an ordered list ofstatements. A rule fires, i.e. the rule engine executes thestatements belonging to the rule, if all conditions evaluateas true according to the facts in the fact repository. More

precisely, a rule fires if all the conditions are true and atleast one of the facts mentioned in these conditions istagged as modified. This ensures that the system processeschanges in the fact repository in an event-like manner.Furthermore, a rule also has a priority which definesexactly when during one complete run of the rule enginethe conditions of the rule are checked against the factrepository, and based on this it is decided whether the ruleshould fire or not. Multiple rules can have the same

priority, but for these rules the system does not provide aguarantee on the order in which they are executed.

Conditions have one of two forms:Exists: This condition checks whether one particular factexists in the fact repository.Eval: An eval condition checks, whether a booleanexpression is true given the data found in the fact

repository. Statements modify the fact repository orgenerally interact with the rest of the system.

Figure 1 : Component diagram of FACTS architecture: Low-level events start execution by creation of new facts (1),which trigger the rule engine (2) to match rules against fact repository (3) and eventually fires rules (4).

Available statements include:Define : Adds a new fact to the local fact repository andinitializes its properties.Retract: Removes one or more facts from the local factrepository.Set: Changes the value an existing property of one or morefacts in the local fact repository or adds a new property.Send: Transmits one or more facts in the local factrepository to other nodes in the sensor network.Call: Calls a function implemented in native code and made

available by the underlying software layer.An example on how to use these operators to implement atypical algorithm for WSNs is given in Section 5.

3.3 FactsFacts are the central means of representing any kind of datain the system. They are structured as a named set of key-value tuples. Multiple facts with the same name may be

present in each local fact repository without disturbing thesystem. Keys are unique for each facts, values typed. Aspecific key-value tuple is called a property of a fact, withavailable types of values being bool, int, float , and string. Every fact has a few predefined properties which areupdated by the system and available to the programmer asread-only values. More precisely, the keys and types ofthese hard encoded properties are:(int) owner: The network wide unique ID of the sensornode that was the last to modify this fact by either creatingit, adding a new property, or modifying an existing

property.(int) time: The time at which the fact was last modified.

Note that this merely is the perception of the current time


4/8

of the modifying node, which may well be out of sync withthe rest of the sensor network or otherwise inaccurate.(string) id: The network wide unique ID of this fact. It isimplemented as the dot-separated concatenation of the IDof the owning sensor node (which is unique in the sensornetwork) and the time of last modification (which is unique

on the local node, that sets itself as the owner uponmodifying the fact in question).(bool) modified: This boolean flag indicates whether a facthas been modified by either another rule or some externalsystem-generated event during or since the last run of therule engine. As rules only fire when at least one of the factsreferenced in their conditions has been modified, this

property is useful for working on only those facts out of a potentially larger set that have caused the rule to fire andhence might require processing. The modified flag of allfacts is cleared every time an entire run of the rule enginehas been completed successfully.

As facts are dynamically added to the fact repository atruntime and as only facts marked as modified trigger theexecution of rules, modified facts appear as events in thesystem to the application-level programmer, thus allowingfor event-centric programming. Furthermore, facts are alsothe central means of transmitting information betweennodes of the sensor network: The Send statement in a ruleallows for one or multiple facts to be transmitted to anothernode or to be broadcasted to the entire network, possiblyutilizing multi-hop forwarding by other nodes.

3.4 FunctionsA function is a chunk of machine code that interacts withthe firmware or operating system of the sensor node, and

provides an interface that can be invoked by the ruleengine. As such, its main purpose is to provide hooks forthe rules to interact with the software layer below themiddleware and to allow for efficient implementation ofalgorithms featuring critical performance considerations.

3.5 Derived ConceptsComplementing the basic components of the distributedexpert system, the following concepts are helpful to fullyunderstand and communicate about the system:

3.5.1 SlotsA slot is the primary means for addressing facts and their

property values in the fact repository. It is a tupleconsisting of two patterns, one identifying the fact and oneidentifying the property key, and a list of conditions thatfurther specify which subset of the fact repository is to beaddressed. The property key pattern may be omitted if onlythe fact itself, rather than one of its properties, is ofinterest.

3.5.2 RulesetsA ruleset is the construct equivalent to a component inother middleware architectures. It is a set of rules andrelated facts that together provide a certain services in thesystem. Rulesets have a well-defined interface in terms of aset of facts that trigger the execution of their rules. They

encapsulate locally used rules and facts in their ownnamespace which is implemented as dot-separated prefix tothe name of the fact it contains.Rulesets may explicitly provide services as identified by awell-known descriptor, or require them to be present on alocal system when being installed. This allows for theconstruction of a dependency graph at compile time and

possibly for automatic loading of rulesets at runtime. Onthe downside, one has to be aware of possible excessiveresource usage in case of automated functions, a drawbackthat should be investigated extensively at design time.Experiences gained by implementing a few commonalgorithms typical for wireless sensor networks show that a

ruleset is typically in the magnitude of ten to twenty rulesand a similar amount of facts. Of course, these numbers aremerely rough estimates and vary depending on thecomplexity of the functionality to be implemented. The

possibility to add such ruleset-like library functions to thesystem according to application needs once againemphasizes the powerful and adaptable design of FACTS.

3.5.3 Globally Shared Information SpaceFacts have an unique ID that is the concatenation of the IDof the owning node and the time when the fact was lastmodified. Only one fact can be modified on a node at anygiven time. The fact repository may thus contain variousfacts from different nodes, being the knowledge base of thenode owning it. This knowledge is composed ofinformation about its current state, events it has spotted in acertain time interval or communicated details ofneighboring or potentially reachable nodes in the network.

3.6 Design Details and ConsiderationsThe concepts as described above were only rough sketcheswhen the work of formalization was begun. Severaldecisions were made during the design phase of the project,which eventually led to the final semantics of our system.This section lists important details of our design and the

considerations details that led to these decisions.

3.6.1 Sets of FactsAs facts are addressed by their name which is notrequired to be unique evaluating a slot against the factrepository may result in a set of multiple matching facts.Hence, a condition or statement that takes a slot as a

parameter may either process a single fact or a set of factsdepending on the content of the fact repository at runtime.


5/8

For a condition to return true when evaluated against agiven fact repository, it is sufficient if at least one of thefacts matched by the slot satisfies the constraints stated inthe condition. A statement however will be executedseparately for every single fact matched by the slot, whichwill lead to multiple executions of the same rule. In case of

a statement containing multiple slots, the statement isapplied sequentially to all possible combinations of thematching facts, i.e. the cross product of the respective setsof facts. If only one specific fact is to be processed, this caneither be achieved by carefully naming the facts, or by

providing more specific constraints in the form ofconditions as additional parameter of the slot as explainedin the following section.

3.6.2 Filtering Facts for Processing by a StatementApart from addressing a fact by its name, a slot isfrequently required to be more specific about exactly whichfact from a potentially large set of matching facts to workwith. In order to do so, a slot can filter the set of all factswith matching names by providing further constraints onthe required values of properties of selected facts. This isdone in the form of a list of conditions that can be specifiedas additional parameter for slot refinement. Obviously, theresult includes only that subset of facts where all conditionson slot parameterization are met. It is up to the application-level programmer to ensure that the properties of factsdiffer enough for selection to isolate a specific single factin case this is required by the application. The systemsupports this by providing an unique ID for each fact in thefact repository and therefore making any fact directlyaccessible via the read-only id property.

An alternative design would have been to implementimplicit filtering of the facts based on the conditions of therule in question. While this would allow for a simplersyntax, there are several disadvantages:

Statements may access facts that are notreferenced in the conditions. Adding conditionsfor filtering purposes alone would bloat theapplication-level code.

Questions would arise on the proper orderconcerning statement processing: All statementscould be executed sequentially for all matchingfacts (horizontal execution), but with the samelogical implication each single statement couldalso be applied to each matching fact beforeexecuting the following (vertical execution). Noneof these two options seems intuitive enough to beacceptable by an application-level programmer or

preferable due to its inherent properties. Statements would have different semantics

depending on which rule they appear in. Thiswould not only be confusing but also violate the

idea of strict decoupling of conditions andstatements within a rule, as detailed in the nextsection.

3.6.3 Separation of Conditions and StatementsEven when associated with the same rule, conditions andstatements are clearly separate entities. Conditions arespecified to only take care of firing a rule and should notresult in unintentional side effects. On the other hand,statements only alter the fact repository or interact with thesystem, thus can be totally ignored by the rule engine whendetermining whether to fire rules. Clearly, statements dohave exactly the same semantics independent of the callingrule. However, this also implies that the filtering of exactlywhich facts to process needs to be done for each statementseparately, and hence is independent of the conditions ofthe rule.

3.6.4 Adjusting Ownership of Modified FactsWhenever a node changes the properties of a local fact, theowner property of the fact is set to the ID of modifyingnode. The goal is to keep the global namespace of factsintact and to ensure that sensor readings processed withinthe sensor network are clearly marked as such. If theoriginal fact is to be preserved while processing, a copyneeds to be made beforehand. The copy is then owned bythe local node and can therefore safely be modified. In caseonly changes to facts owned by the local node are intended,one has to add a filtering condition to slots which state thatonly facts whose owner property matches the ID of thelocal node are to be processed.

An alternative solution proposes facts to be owned by thelocal node exclusively, i.e. independent of any filters.Updates would then result in changes just in case thecurrent executing entity is also the owner of the fact andotherwise leave the fact untouched as read-only. It turnedout that while allowing for the same functionality to beimplemented, these semantics resulted in bloated code

because of bad interaction with sending facts across thenetwork: In this case, facts can be seen as packets, and

packet properties, thus facts properties, needed to beupdated slightly for each hop they travel on the network.Having to make a copy before being able to process a

packet would not only waste memory but also result in

unreadable code.

3.6.5 Usage of Local VariablesUnlike JESS [12], a reference expert system we examinedtor language formalization, our system does not support thenotion of local variables to which a specific fact can be

bound within a rule. We consider binding facts to variablesat runtime to be too expensive in terms of memory usagefor an embedded system. As proven above the syntax of


6/8

filtering on slots is able to provide the same functionilty,while lowering system overhead for memory management.Due to this optimization it will be possible to give boundson memory consumption of a future implementation evenat compile time.

4. PROTOTYPE IMPLEMENTATIONFACTS as introduced in the previous sections was firstimplemented as purely functional prototype in the Haskell

programming language. The following section explain thereasons why this somewhat unusual approach was taken,gives an overview of the implementation and presentsrelevant code fragments.

4.1 RationaleAs [14] points out, a functional design or a prototype can

be most useful even if the ultimate goal is an imperativesolution. In our case the advantages were as follows:

Initially, the basic concepts were not wellunderstood beyond traditional event-centricarchitectures and their exact semantics changedrapidly while new requirements andinterdependencies were discovered. During this

phase of rapid iterative prototyping, the emphasison concise functional definitions helped the

project to stay coherent. The definitions of functions obtained from the

prototype can serve as formal specification of thesystem. Also, the definitions of the data types can

be used as basis for a grammar. Eventually thisapproach can lead to the construction of acompiler for this grammar able to translate humanreadable rule definitions into an intermediateformat or byte-code, suitable for deployment inthe sensor network.

Higher order function and their capability of usingfunctions as parameters makes the code base verycompact and easy to maintain, while at the sametime preserving type safety.

The availability of our functional prototype allows to runtest cases and check the semantics of the system very earlyin the development process. The result is a smoothcodebase without known inconsistencies or dead code.Furthermore, the codebase is perfect in the respect thatnothing can we removed without losing functionality.

4.2 OverviewThe core of our system is implemented as a Haskellmodule. Its public interface contains constructors for thecondition and statement primitives and functions to createrule, fact and function entities as well as slots and rulesets.

For evaluation purposes we also implemented functions toconstruct a sensor node and set up a sensor network. and

based on these run a simulation. Using these mechanisms acore set of rulesets has been implemented as additionalHaskell modules and is available to be used in test runs ofthe system.

Following the functional paradigm, the simulation runs byiteratively transforming the current state of the sensornetwork including all nodes and their respective rule andfact repositories into the subsequent state. For all nodesthe conditions of their local rules are checked against thefact repositories and the statements are executed if thegiven facts suffice for the rule to fire. In order to implementunique IDs of facts the simulation environment provides atimer counter that is increment whenever a fact is modifiedand set to an steadily increasing well known value after acomplete run of the simulated rule engines on all nodes has

been completed. The current notion of time of the sensornodes is thus known for each simulation step which allows

for the simulation to supports the injection of facts to thefact repositories of one specific are all sensor nodes. Asexternal events appear to the rule engines as new facts intheir repositories, the injection method can be used tosimulate sensor readings at certain points in time during thedeployment of the sensor network.

4.3 Relevant Code FragmentsListing 1 is a shortened version of the main loop of thefunctional simulation.

1 pr ocessSt at e : : [ Event ] - > St ate - > St at e2 pr ocessSt at e event s s t at e =

3 ( St at e ( st ep + 1) next St epTi me4 ( Net wor k ( map cl eanNode newNodes) ) )5 wher e6 next St epTi me =7 t i me + si mul at i onStepTi me8 ( St at e st ep t i me net wor k) =9 st at e ( Stat e _ newTi me10 ( Net wor k newNodes) ) =11 processNet wor k ( processEvent s12 st at e curr ent Event s) net work13 cur r ent Event s =14 f i l t er ( \ ( Event event St ep _ _) - >15 ( event St ep 15 == st ep) ) event s

Listing 1 : Main loop of functional simulation

A simulation step is broken down into several operations:In lines 13 to 15 the events for the current simulation stepare filtered out of the global event list. Lines 10 to 12 first

process these events by updating the state of the networkaccordingly, The new state is then used as input for thecentral processing of the network in the same line. It resultsin a new list of nodes the facts of which have theirmodi f i ed property cleaned up in line 4 as a final


7/8

operation. Together with the calculation of the time for thenext simulation step in lines 6 and 7 this concludes thetransformation of the current state.Listing 2 shows the complete logic that decides whether tofire a rule or not and updates the simulated state of thesensor network accordingly.

1 appl yRul e : : St at e - > MAC - > Rul e - > St at e2 appl yRul e st at e mac3 ( Rul e name _ condi t i ons st at ement s)4 | oneFact I sModi f i ed &&5 al l Condi t i onsAr eTr ue =6 f ol dl ( \ st at e - > appl ySt at ement st at e7 mac) st at e st at ement s8 | ot her wi se = st at e9 wher e10 oneFact I sModi f i ed = or ( map11 ( checkFact s f act s) condi t i ons)12 al l Condi t i onsAr eTr ue = and ( map13 ( checkCondi t i on f act s) condi t i ons)14 f act s = get Fact s st at e mac

Listing 2 : Determination of rule execution

Taking the MAC address as ID of the current sensor nodeand the rule to be applied to its fact repository as additional

parameters, this function can be broken down into thefollowing operations: As can be seen in lines 4 and 5, a rulefires only if at least one fact is tagged as modified and allconditions of the rule evaluate as true. If this is the case, arule is applied by folding its statements into the currentstate of the simulation in lines 6 and 7, otherwise the stateis returned unchanged in line 8 as the rule did not fire. Thecalculations whether a fact referenced in the conditions has

been modified and whether all conditions are true statelines 10 to 13 respectively.

5. EXAMPLE: COVERAGEThe goal of the coverage algorithm in a wireless sensornetwork scenario is to determine which areas of ageographic region are covered by the sensor network, andwhere redundant information can be gained. The collectedinformation may be used to selectively power down sensornodes in order to extend the total lifetime of the sensornetwork, a situation applying usually to densely deployednetworks.A partial listing of the rule-based implementation of the

coverage algorithm is given in listing 3. Following name ofthe rule, conditions are listed prefixed with .

1 sendRange2 Retr act Ti mer. expi r edSl ot4 - > Def i ne "r angeFact "5 - > Set ( "r angeFact " "xMi n")6 ( posXSl ot - Syst em. t xRadi usSl ot )7 - > Set ( " r angeFact " "xMax" )

8 ( posXSl ot + Syst em. t xRadi usSl ot )9 - > Set ( "r angeFact " "yMi n")10 ( posYSl ot - Syst em. t xRadi usSl ot)11 - > Set ( "r angeFact " " yMax" )12 ( posYSl ot + Syst em. t xRadi usSl ot )13 - > Send 0 Syst em. t xPower Sl ot14 ( "r angeFact " [ ( ( "r angeFact " "owner ")15 == nodeI DSl ot ) ] )16 - > Def i ne "r angeSendFact "1718 xyMi nCover ed19


8/8

The example of the coverage algorithm illustrates how ourmiddleware provides intuitive event-like semantics andabstraction from low-level communication details.Furthermore, it shows how remote data transparently

becomes available for local processing while still preserving the semantics of global adressability.

6. CONCLUSIONIn this paper we presented the fundamental concepts andthe prototype implementation of our middleware approachFACTS, which is able to provide a highly flexibleframework for applications in wireless sensor networks.The goal is to alleviate challenges in programming arisingfrom the underlying embedded hardware, asynchronousevent-handling, and distribution issues of sensor nodes byintroducing a rule-based programming environment.To determine the state of each single node, as well as tocoordinate groups of dedicated nodes in a simple way,FACTS uses a single data management facility, the factrepository. This may serve as distributed shared memory,as well as to maintain state and temporal data. Rules can bespecified to implement algorithms and take care of

processing of sensor data. With its modular design theoverall system is aimed to be especially suitable for therestricted resources of wireless sensor networks and allowsfor application specific adaptations, envisioned to be

performed even once deployed.

7. FUTURE WORKAfter establishing the semantics of the FACTS system andsmall-scale qualitative simulations, there are two major

directions in which to proceed:

On the implementation side, we will replace our functional prototype and custom made simulation environment withan imperative implementation that can run on both morewidely used network simulators and eventually on a real-world sensor network platform. We plan to enrich ourcurrent qualitative data with quantitative measurements andfinally verify our findings in real-world scenarios.

On the application-level side, we plan to extend tofunctionality of our middleware by implementing morealgorithms and services commonly used in wireless sensor

networks in the form of rulesets. This will lead to questionsabout the dependencies between rulesets and theirinteractions at runtime. We envision that rulesets willeventually be used as drop-in components for sensornetworks that extend the capabilities of a deployed wirelesssensor network while making these advantagestransparently available to the application that runs on themiddleware.

8. REFERENCES[1] A. Dunkels, O. Schmidt and T. Voigt. Using Protothreads for

Sensor Node Programming. In REALWSN'05 Workshop on Real-World Wireless Sensor Networks , Stockholm, Sweden,June 2005 .

[2] B. M. Blum, P. Nagaraddi, A. Wood, T. F. Abdelzaher, S.

Son and J. A. Stankovic. An Entity Maintenance andConnection Service for Sensor Networks .The First International Conference on Mobile Systems,Applications, and Services (MOBISYS `03), California, May2003 .

[3] P. Lewis and D. Culler. Mat: A Tiny Virtual Machine forSensor Networks. In ASPLOS-X , San Jose, USA, October2002.

[4] K. Rmer, C. Frank P. M. Marron and C. Becker. GenericRole Assignment for Wireless Sensor Networks. In ACMSIGOPS European Workshop 2004, Leuven, Belgium, 2004.

[5] K. Whitehouse, C. Sharp, E. Brewer, and D. Culler. Hood: A Neighborhood Abstraction for Sensor Networks. In ACM MobiSys 2004, Boston, USA, June 2004.

[6] S. R. Madden, M. J. Franklin, J. M. Hellerstein and W.Hong . TAG: a Tiny Aggregation Service for Ad-Hoc Sensor

Networks . In OSDI 2002 , Boston, USA, December 2002. [7] D. Gay, P. Levis, R. von Behren, M. Welsh, E. Brewer and

D. Culler. The nesC language: A holistic approach to net-worked embedded systems. In: Programming Language De-sign and Implementation (PLDI) , June 2003.

[8] K. Rmer and F. Mattern: Event-Based Systems forDetecting Real-World States with Sensor Networks: ACritical Analysis . In DEST Workshop on Signal Processingin Wireless Sensor Networks at ISSNIP , Melbourne,Australia, December 2004.

[9] T. Liu and M. Martonosi. Impala: A Middleware System forManaging Autonomic Parallel Sensor Systems. In ACM SIG-PLAN , San Diego, USA, June 2003.

[10] K. Terfloth and J. Schiller. Driving Forces behindMiddleware Concepts for Wireless Sensor Networks ,In The REALWSN'05 Workshop on Real-World WirelessSensor Networks , Stockholm, June 2005 .

[11] O. Kasten, K. Rmer: Beyond Event Handlers: ProgrammingWireless Sensors with Attributed State Machines , InI EEE/ACM International Conference on InformationProcessing in Sensor Networks (IPSN) , Los Angeles, USA,April 2005.

[12] Jess, the Rule Engine for the Java Platform.http://herzberg.ca.sandia.gov/jess/

[13] Carsten Buschmann, Stefan Fischer, Norbert Luttenbergerand Florian Reuter: Middleware for Swarm-Like Collectionsof Devices, In IEEE Pervasive Computing Magazine , Vol. 2,

No. 4, 2003.

[14] S. Thompson: Haskell The Craft of FunctionalProgramming. Addison-Wesley, Second Edition, 1999.
http://../sensornetze/papiere/entity_maintenance.pdfhttp://../sensornetze/papiere/entity_maintenance.pdfhttp://www.vs.inf.ethz.ch/publ/papers/wsn-events.pdfhttp://www.vs.inf.ethz.ch/publ/papers/wsn-events.pdfhttp://www.vs.inf.ethz.ch/publ/papers/wsn-events.pdfhttp://page.mi.fu-berlin.de/~terfloth/mw_forces_realwsn05.pdfhttp://page.mi.fu-berlin.de/~terfloth/mw_forces_realwsn05.pdfhttp://www.vs.inf.ethz.ch/publ/papers/kasten-beyond-2005.pdfhttp://www.vs.inf.ethz.ch/publ/papers/kasten-beyond-2005.pdfhttp://www.vs.inf.ethz.ch/publ/papers/kasten-beyond-2005.pdfhttp://www.vs.inf.ethz.ch/publ/papers/kasten-beyond-2005.pdfhttp://page.mi.fu-berlin.de/~terfloth/mw_forces_realwsn05.pdfhttp://page.mi.fu-berlin.de/~terfloth/mw_forces_realwsn05.pdfhttp://www.vs.inf.ethz.ch/publ/papers/wsn-events.pdfhttp://www.vs.inf.ethz.ch/publ/papers/wsn-events.pdfhttp://www.vs.inf.ethz.ch/publ/papers/wsn-events.pdfhttp://../sensornetze/papiere/entity_maintenance.pdfhttp://../sensornetze/papiere/entity_maintenance.pdf

Documents

A Rule-Based Middleware Architecture