Ruling Networks with RDL:A Domain-Specific Language to Task

Wireless Sensor Networks

Kirsten TerflothInstitute of Mathematics and Computer Science

Freie Universität Berlin, Germany

RuleMLOctober 31th, 2008 - Orlando, Florida

KIRSTEN TERFLOTH RDL: A DOMAIN-SPECIFIC LANGUAGE TO TASK WSNs 2

MOTIVATION: RULES FOR WIRELESS SENSOR NETWORKS

• Abstraction needed for programming wireless sensor networks! Combination of complex properties to handle – embedded devices,

wireless networking, event-centric processing and distribution Domain-Experts (Biologists, Media Designers, ..) instead of

Computer Scientists Fast Prototyping instead of embedded C

• Rule-based programming: Event-Condition-Action naturally fits the domain

Push model (interrupts: radio, sensors, timers) Reactive behavior

Language tailored to domain AND operational model to the rescue!

KIRSTEN TERFLOTH RDL: A DOMAIN-SPECIFIC LANGUAGE TO TASK WSNs 3

GENERAL CONCEPT – FACTS

• Language is essential part of a middleware framework Virtual machine running on the nodes to interpret rules

Memory access completely managed System rulesets can be linked on demand to provide

common WSN features

KIRSTEN TERFLOTH RDL: A DOMAIN-SPECIFIC LANGUAGE TO TASK WSNs 4

DATA ABSTRACTION: EVERYTHING IS A FACT!

• All data visible to a programmer is wrapped in facts Named <key, value> tuples Timestamped for temporal ordering

humidity [value = 77]role [current = „router“]

role [current = „sink“]

request [data = „log_data“, timespan = 20, enabled = true]

aggregateAccEvents

energy [level = „low“]

threshold [temp = 25]

threshold [acc = 100]

KIRSTEN TERFLOTH RDL: A DOMAIN-SPECIFIC LANGUAGE TO TASK WSNs 5

EVENT / CONDITION PART OF RULES

• Conditions: reason about state AND events Syntax: Production rule „WHEN“ Semantics: Event-Condition-Action BUT events are not transient Reactive rules that operate on event and state

• Conditions can feature Test for existance of specific facts Evaluation of values of fact properties (simple and range queries) Unary expressions over both fact properties and sets of facts

• Evaluation of conditions is triggered upon insert/update on fact repository

Deletion of facts is not an event

KIRSTEN TERFLOTH RDL: A DOMAIN-SPECIFIC LANGUAGE TO TASK WSNs 6

CONDITION EXAMPLES I: EXISTANCE

rule bootstrap 20<- exists {newSampleRequest}

• IF „newSampleRequest“

KIRSTEN TERFLOTH RDL: A DOMAIN-SPECIFIC LANGUAGE TO TASK WSNs 7

CONDITION EXAMPLE II: RANGE QUERY AND CONSTRAINT CHECK

• IF „newSampleRequest“ AND value of property sensor == „humidity“AND value of property reqNum > 12 AND <= 100

rule bootstrapHumidity 40<- exists {newSampleRequest

<- eval ({this sensor} == „humidity“)<- eval ({this reqNum} > 12)<- eval ({this reqNum} <= 100)}

KIRSTEN TERFLOTH RDL: A DOMAIN-SPECIFIC LANGUAGE TO TASK WSNs 8

CONDITION EXAMPLE III: CONJUNCTION

• IF „newSampleRequest“ AND nodeID == 3

rule bootstrapIfCorrectNode 11<- exists {newSampleReqest}<- eval ({system owner} == 3)

KIRSTEN TERFLOTH RDL: A DOMAIN-SPECIFIC LANGUAGE TO TASK WSNs 9

CONDITION EXAMPLE VI: UNARY / BINARY EXPRESSION

rule bootstrapAggreagate 11<- exists {newSampleRequest}<- eval ((count {humidity}) > 3)<- eval (({newSampleRequest reqNum} + 1) == 5)

• IF „newSampleRequest“ AND number of humidity facts in repository > 3 AND increment of the reqNum property of „newSampleReq“ == 5

KIRSTEN TERFLOTH RDL: A DOMAIN-SPECIFIC LANGUAGE TO TASK WSNs 10

ACTION PART OF A RULES

• Statements feature Basic fact manipulation

Define / set / retract Domain-specific part of the language

Share facts with remote nodes Sample sensors Invoke hardware functionality

• Execution Atomic: When a rule triggers, all statements are executed in order Events arising are buffered to avoid race conditions

KIRSTEN TERFLOTH RDL: A DOMAIN-SPECIFIC LANGUAGE TO TASK WSNs 11

SEMI-CONCLUSION

• Execution semantics Evaluation of rules complies to a priority ordering No binding of facts to variables: Pattern matching

• Language constructs so far allow for Definition of global rulebase (node-local)

ruleset forwarding fact rt_entry [next = 4, sink = 15, cost = 3]

rule forwarding 100<- exists {data_sample}<- exists {rt_entry}-> send {rt_entry next} 100 {data_sample}

KIRSTEN TERFLOTH RDL: A DOMAIN-SPECIFIC LANGUAGE TO TASK WSNs 12

HOW TO ADD MODULARITY TO ENABLE RE-USE?

• Rulebase size is very limited (e.g. 17 KB of ROM on MSB ) Building a cohesive rulebase for all possible rules

envisioned is not an option

• Language features no binding options for variables• All forward chaining is done by pattern matching on names

and values• How to provide a generic interface to match a diversity of

facts?

KIRSTEN TERFLOTH RDL: A DOMAIN-SPECIFIC LANGUAGE TO TASK WSNs 13

PATTERN MATCHING AND MODULARITY

ruleset forwarding fact rt_entry [next = 4, sink = 15, cost = 3]

rule forwarding 100<- exists {data_sample}<- exists {rt_entry}-> send {rt_entry next} 100 {data_sample} humi

dity?

• Switch of perspective: declarative -> functional Understand rule to be a function Polymorphism / function overloading is missing!

KIRSTEN TERFLOTH RDL: A DOMAIN-SPECIFIC LANGUAGE TO TASK WSNs 14

GENERIC MATCHING

• Extention of possible types for property values boolean, integer, String Add: name

• Extension of matching capability to enable referencing to different facts

• Benefit: Expression of relational references across rules and ruleset is possible

KIRSTEN TERFLOTH RDL: A DOMAIN-SPECIFIC LANGUAGE TO TASK WSNs 15

RELATIONAL REFERENCING

humidity [value = 32]

humidity [value = 30]

temperature [value = 17]

data_sample [sensor = humidity]

KIRSTEN TERFLOTH RDL: A DOMAIN-SPECIFIC LANGUAGE TO TASK WSNs 16

TRANSPARENT FORWARDING

ruleset TransparentForwarding public name data_sample = „data_sample“public name humidity = „humidity“fact rt_entry [next = 4, sink = 15, cost = 3]

rule forwarding 100<- exists *{data_sample sensor}<- exists {rt_entry}-> send {rt_entry next} 100 *{data_sample sensor}

rule sensor_humidity 99<- exists {humidity}-> define data_sample [sensor = humidity]

KIRSTEN TERFLOTH RDL: A DOMAIN-SPECIFIC LANGUAGE TO TASK WSNs 17

REMARKS

• Additional language features Named filters for frequently requested constraints Straight-forward integration into modular rulesets Namespaces and scoping added

Public/private visibility of names and facts

KIRSTEN TERFLOTH RDL: A DOMAIN-SPECIFIC LANGUAGE TO TASK WSNs 18

CONCLUSION

• RDL is a domain-specific language explicitly designed for wireless sensor networks

High level of abstraction from hardware percularities Manual stack management Event buffering Interrupt handling

Forward chaining to derive next state Declarative nature, support for modular rule bases added

• FACTS: middleware framework for RDL programs http://cst.mi.fu-berlin.de/projects/FACTS/index.html http://cst.mi.fu-berlin.de/projects/FenceMonitoring/