What is a forward chaining rules engine?

An inference engine using forward chaining applies a set of rules and facts to deduce conclusions, searching the rules until it finds one where the IF clause is known to be true. The process of matching new or existing facts against rules is called pattern matching, which forward chaining inference engines perform through various algorithms, such as Linear, Rete, Treat, Leaps etc.

‍

When a condition is found to be TRUE, the engine executes the THEN clause, which results in new information being added to its dataset. In other words, the engine starts with a number of facts and applies rules to derive all possible conclusions from those facts. This is where the name “forward chaining” comes from – the fact that the inference engine starts with the data and reasons its way forward to the answer, as opposed to backward chaining, which works the other way around.

How about backward chaining?

In backward chaining, the system works from conclusions backwards towards the facts, an approach called goal driven. Compared to forward chaining, few data are asked, but many rules are searched. Backward-chaining rules engines are not suited for dynamic situations and are mostly only used as expert systems in decision making.

‍

What are some examples of forward chaining rules engines for IoT?

Most of the IoT platforms on the market today actually have a rules engine of this type. Here are a couple of examples of automation tools built on forward chaining engines that are available on the market at the moment we are writing this blog post: Redhat Drools, Cumulocity, Eclipse Smart Home, AWS Rules, Thingsboard and many more.

‍

Should you use forward chaining engines to model complex logic?

Condition action rules engines provide a good framework for expressing conditional (Boolean) logic. However, combining multiple non-binary outcomes of functions (observations) in the rule is not possible with forward chaining engines, since conditions are applied on Boolean (true/false) outcomes.

‍

Forward chaining engines “collapse” on the majority voting requirement almost immediately, since they search inference rules until they find one or multiple where the IF clause is known to be true. This means that several, potentially contradicting rules may fire at the same time and the engine needs to deal with conflict resolutions to decide which one to execute. Adding majority voting into to this mix is too much to handle.

‍

Conditional executions of functions based on the outcomes of previous observations is not easy, as forward chaining rules engines expect all data to be present at the moment rules are evaluated.

‍

Are forward chaining engines explainable?

For simple problems, forward chaining engines provide us with an easy way to design rules. In fact, there is nothing easier to grasp than if-this-then- that type of rules! However, adding more conditional statements into a rule leads to very complex analyses, which hinder the understanding of the rule’s intent.

‍

Moreover, the actual conditions of the rules, which often include thresholds and other Boolean expressions, are written and buried somewhere in the code, and are as such difficult to expose to the outside observer. As a workaround, during the design phase, rules are often represented as graphs with conditional outcomes  as labeled “arrows”. However, these graphs are nowhere to be seen or inspected once the rule is implemented.

‍

Simulation, debugging and decision tracking (why has the rule fired at runtime) is not a trivial task, since the data determines which rules’ paths are selected and used. Moreover, as described earlier, the conflict resolution requires a priori selection of the conflict resolution strategy, which is not part of the rule but often a configuration parameter of the rules engine.

‍

Are forward chaining engines adaptable?

Changing rules is possible with forward chaining engines but always problematic, as conflict resolution needs to be re-evaluated every time a condition in the rule changes.

Adding third-party API services to forward chaining engines is not a straightforward task and it is often accomplished directly in the code, leading to the API endpoints being directly coupled at the rule level. Since thresholds and other conditions are also often defined in the code, it is difficult to reuse the same API services across multiple instantiated rules.

‍

How easy are forward chaining engines to operate?

Applying the same rule across many IoT devices for example is possible as long as thresholds and other conditions do not change across devices. Anything more complicated is extremely difficult to achieve with FC, since many inputs to the rules are buried deeply inside the code.

‍

Are forward chaining engines scalable?

Forward chaining rules are stateless, which means that you can easily run multiple rules in parallel, but you can not distribute the load to different processes while executing one instance of a rule.

This is an excerpt from our latest Benchmark Report on Rules Engines used in the IoT domain. You can have a look at a summary of the results or download the full report over here.

‍

‍