Rules engines

A rule engine is simply a software construct that executes actions on events. For example, if the humidity in a room exceeds 50%, send an SMS message to the owner. These are also called Business Rule Management Systems (BRMS). 

Rules engines may or may not have state and be called stateful. That is, it may have a history of the event, and take different actions depending on the order, the amount, or the patterns of events as they occurred historically. Alternatively, they may not maintain state, and only inspect the current event (stateless): 

Simple rule engine example.

In our example of a rules engine, we will look at Drools. Drools is a BRMS developed by Red Hat and licensed under the Apache 2.0 license. JBoss Enterprise is a production version of the software. All objects of interest reside in the Drools working memory. Think of the working memory as the set of IoT sensor events of interest to compare to satisfy a given rule. Drools can support two forms of chaining: forward and backward. Chaining is a method of inference taken from game theory. 

Forward chaining takes in available data until a rule chain is satisfied. For example, a rule chain may be a series of if/then clauses, as shown in the preceding diagram. Forward chaining will continuously search to satisfy one of the if/then paths to infer from an action. Backward chaining is the converse. Rather than starting with the data to be inferred from, we start with the action and work backward. The following pseudocode demonstrates a simple rule engine:

Smoke Sensor = Smoke Detected
Heat Sensor = Heat Detected

if (Smoke_Sensor == Smoke_Detected) && (Heat_Sensor == Heat_Detected) then Fire
if (Smoke_Sensor == !Smoke_Detected) && (Heat_Sensor == Heat_Detected) then Furnace_On
if (Smoke_Sensor == Smoke_Detected) && (Heat_Sensor == !Heat_Detected) then Smoking
if (Fire) then Alarm
if (Furnace_On) then Log_Temperature
if (Smoking) then SMS_No_Smoking_Allowed

Let us assume that:

  • Smoke_Sensor: Off
  • Heat_Sensor: On

Forward chaining would resolve the antecedent of the second clause, and infer that temperatures are being logged.

Backward chaining tries to prove that the furnace is on, and works backward in a series of steps:

  1. Can we prove the temperatures are being logged? Take a look at this code:
      if (Furnace_On) then Log_Temperature
  1. Since the temperatures are being logged, the antecedent (Furnace_On) becomes the new goal:
      if (Smoke_Sensor == !Smoke_Detected) && (Heat_Sensor == Heat_Detected) then Furnace_On
  1. Since the furnace is proven to be on, the new antecedent comes in two parts: Smoke_Sensor and Heat_Sensor. The rules engine now breaks it up into two goals:
      Smoke_Sensor off
Heat_Sensor on
  1. The rules engine now attempts to satisfy both the subgoals. Upon doing so, the inference is complete.

Forward chaining has the advantage of responding to new data as it arrives, which can trigger new inferences. 

Drools' semantic language is intentionally simple. Drools is composed of the following basic elements:

  • Sessions, which define the default rules
  • Entry points, which define the rules to use
  • When statements, the conditional clause
  • Then statements, the action to take

A basic Drools rule is shown in the following psuedo code. The insert operation places a modification in the working memory. You normally make a change to working memory when a rule evaluates to true.

rule "Furnace_On"
when
Smoke_Sensor(value > 0) && Heat_Sensor(value > 0)
then
insert(Furnace_On())
end

After all the rules in Drool execute, the program can query working memory to see which rules evaluated to true using syntax, like the following:

query "Check_Furnace_On"
$result: Furnace_On()
end

A rule has two patterns:

  • Syntactic: The format of data, parity, hash, range of values.
  • Semantic: Value must belong to a set in a list, the count of high-temperature values must not exceed 20 in 1 hour. Essentially, these are meaningful events. 

Drool supports the creation of very complex and elaborate rules to the point that a database of rules may be needed to store them. The semantics of the language allows for patterns, range evaluation, salience, times when a rule is in effect, type matching, and work on collections of objects. 

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.226.222.12