Ruling Networks with RDL: A Domain-Specific Language to Task Wireless Sensor Networks Kirsten Terfloth Institute of Mathematics and Computer Science Freie Universität Berlin, Germany RuleML October 31th, 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 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“) 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} 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} humidity? 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  