FACTS - A Rule-Based Middleware Framework for WSN
Abstract
Combining massively distributed data processing on embedded devices with ad-hoc communication over a wireless medium, Wireless Senor Networks (WSN) are a challenging domain for software development. While applications usually rely on tasking a network as a whole entity, e.g. tracking of objects moving through the network or analyzing temperature derivation of a specific area, management of the constraint resources (energy, memory, processing power, medium access) has to be done locally. Hence a developer has to keep in mind both sides of the story: local interaction of sensor nodes as well as global network behavior for task execution.
FACTS has been implemented to shield a programmer from intrinsic hardware, data and communication concerns without taking the abstraction to a level that limits flexibility. It provides a middleware framework based on rule evaluation local to a node, and enables fast algorithmic solution implementation.
FACTS Architecture
The basic idea of FACTS has been inspired by expert systems, where modular pieces of processing instructions - rules - encapsulate knowledge about when and how to handle data occurring in the system. Filtering hierarchies can be easily expressed with rules as well as event triggers, aggregation functionalities or more complex rule interactions. Data itself is specified in a special format called a fact, thus allowing sensor nodes to transparently exchange facts over the network. Local interaction between nodes becomes easy to express, global network behavior may therefore be the key focus of application developers. Since the system is designed to react on changes relevant to application, the node may go to low-power mode in case no event is triggering rule execution.
The FACTS architecture evolves around the central processing entity called the rule engine, which schedules rules in case they are triggered by incoming facts, and a fact repository that can be understood as a global storage for data.
Figure 1: Components of the FACTS Framework
Whenever a new fact is created due to an outside event, a new data sample or produced by a formerly executed rule, or one of the facts stored in the fact repository has been modified, the rule engine checks whether any rules fire. Rules can be used to specify application-level data processing or encapsulate any middleware service needed, which may include e.g. routing algorithms or filtering schemes. To ensure a predictable behavior of the system, the rules can be tagged with a priority ordering. The rule engine can then schedule the rules accordingly while at the same time serve as a safe execution environment: memory access, interrupt handling and basic communication primitives are completely hidden from the developer.
Ruleset Definition Language
FACTS provides a new language for rule specification, the ruleset definition language (RDL), since this allows for grasping necessary commands for working with WSNs directly at the language level. Not only is it convenient to have a small and precise set of programming primitives at hand, but it also allows for optimizing the language towards the target domain. In our case this led to the elimination of a notion of local variables to avoid the system to malfunction or crash at runtime.
A typical example of interacting rules is illustrated in the following listing of a ping-pong application ruleset, where nodes interact with sending pings and pongs.
| ruleset PingPong
rule button 150 |
|
| Listing 1: PingPong ruleset |
The first rule 'button' has a higher priority than the second rule, thus will be scheduled first in case both rules trigger. A rule is composed of one or more condition(s) stating when a rule is supposed to fire, marked by an arrow pointing to the left (<-) to symbolize the input characteristics. A button fact, on the ScatterWeb platform this equals a fact generated when the event that someone manually pushed a button on the sensor node occurs, has to exists to make the condition return true. Then, all following statements, marked by an arrow pointing to the right (->), will be executed one after another. Retract deletes the button fact for housekeeping reasons, define enables the specification of a new fact named 'ping' which is send broadcast with a transmission power of 15% by the transceiver afterwards. Facts can be transmitted unicast by specifying the receiver's id in the first value, while the second is used to control the transmission power. The 'ping' rule will fire as soon as a 'ping' fact is handed to the rule engine, and execute it's statements accordingly.
For brevity, complex conditions, fact filtering or fact specification with properties, have been omited in this example. For further information a look at the publications or directly into the sourcecode of the rulesets supplied below will be valuable.
Project Components
FACTS-re
The FACTS runtime environment (FACTS-re) is currently running on the ScatterWeb embedded sensor boards (ESBs) (Firmware version 3.0) and the Modular Sensor Board (MSB) (Firmware version 1.0).
FACTS-rc
FACTS-rc is the ruleset compiler for the FACTS middleware architecture. It compiles rulesets either to bytecode that can be executed by the FACTS-re runtime environment on a ScatterWeb ESB or to Haskell code that can be tested in FACTS-hs.
FACTS-hs (not actively maintained)
FACTS-hs is the an functional implementation of the FACTS middleware architecture. It also contains a rudimentary simulator of WSNs for basic testing and debugging. FACTS-hs is implemented in Haskell 98 and runs fine on the Hugs 98 interpreter. It is almost feature complete and well documented. The purpose is to serve as reference for future implementation for real sensor nodes.
FACTS-rls
A collection of popular WSN algorithms such as directed diffusion is implemented as rulesets. Compiled to bytecode with FACTS-rc they can be interpreted on the sensor nodes with the help of FACTS-re.
Relevant Publications
[TeWS06] Terfloth, K.; Wittenburg, G.; Schiller, J.:
Rule-oriented Programming for Wireless Sensor Networks,
International Conference on Distributed Computing in Sensor Networks (DCOSS) / EAWMS Workshop, San Francisco, USA, June 2006
[TeWS06] Terfloth, K.; Wittenburg, G.; Schiller, J.:
FACTS - A Rule-Based Middleware Architecture for Wireless Sensor Networks,
First IEEE International Conference on Communication System Software and Middleware (COMSWARE 2006), New Delhi, India, January 2006
[TeSc05] Terfloth, K.; Schiller, J.:
Driving Forces behind Middleware Concepts for Wireless Sensor Networks,
The REALWSN'05 Workshop on Real-World Wireless Sensor Networks, Stockholm, Sweden, June 2005
Contact: Kirsten Terfloth