A rules engine is a software tool that enables developers to model the world in a declarative way. Rules engines are powerful automation machines that come in various shapes and flavours. Different types of engines were built to address different problems and some have overlapping functionality. It can be difficult to figure out which type of rules engine best suits your needs.

In order to help you evaluate, we have defined a testing benchmark composed of seven core rules engine capabilities.

We have then taken the seven most common types of rules engine technologies (and our very own Waylay rules engine) and we have tested and scored each one against this benchmark.

This is what we found.

Jump to results

Eight rules engine technologies for Internet of Things automation

01 | Forward Chaining Engines

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.

Most of the IoT platforms on the market today have a rules engine of this type: Redhat Drools, Cumulocity, Eclipse Smart Home, AWS Rules, Thingsboard etc.

02 | Condition-Action Engines

Condition-Action rules engines don’t allow multiple conditions, which makes them on one hand very limited in their logic expression capabilities and on the other hand - much more scalable.

Condition-Action rules engines (if this - then that) are sometimes extended with the ELSE statement (if this - then that - else - that). A popular example for this category is ifttt.com

03 | Flow Processing Engines

Flow ­based programming is a programming paradigm that defines applications as networks of "black box" processes. These processes, a.ka. functions, are represented as nodes that exchange data across predefined connections by message passing. The nodes can be reconnected endlessly to form different applications without having to change their associated functions.

Some of the most popular examples of flow engines are Yahoo! Pipes, Node-RED (and its clones) and Eclipse Kura.

04 | Decision trees / Decision Tables

A popular way of capturing the complexity of conditional rules is by using decision trees, which are graphs that use a branching method to illustrate every possible outcome of a decision. There are several products on the market that offer rules engines based on decision trees/tables.

The open source rules engine Drools for example has an extension to integrate with decision tables, using an excel sheet in combination with snippets of embedded code to accommodate any additional logic or required thresholds.

05 | Stream Processing Engines

Stream processing is the processing of data in motion, in other words, computing on data directly as it is produced or received. Upon receiving an event from a data stream, a stream processing application reacts to the event immediately. The application might trigger an action, update an aggregate, or “remember” the event for future use.

Some of the most popular engines are Storm, Spark and Flink.

06 | CEP Engines

Complex event processing, or CEP, is event processing that combines data from multiple sources to infer events or patterns that suggest more complicated circumstances. The goal of complex event processing is to identify meaningful events.

Most of the IoT edge-based rules engines are either of this type (some current examples are Litmus, Foghorn, WSO2) or of the flow processing type (similar to node-RED).

07 | Finite State machines

A state machine can be used to describe a system in terms of a set of states that the system goes through. A state is a description of the status of a system that is waiting to execute a transition. A transition is a set of actions to be executed when a condition is fulfilled or when an event is received.

AWS Step functions and IoT Explorer from Salesforce are FSM-based rules engine.

How to evaluate rule technologies for IoT automation?

When evaluating any new tool, it’s good practice to look at how powerful it is (its depth of functionality), how easy it is to use (its level of complexity) and how ready it is to support your future needs (based on your growth trajectory and features you may need).

In the case of a rules engine, when looking at the depth of functionality we need to assess if it supports building complex logic, how well it handles the time dimension and how it deals with uncertainty.

Ease of use can be assessed by looking at things like how clear the intent of the rule is, if there is a visual representation of the logic you are building and how easy it is to simulate, test and debug rules.

Evaluating the engine’s readiness to grow as your business needs grow can be done by checking how well it responds to changes, how easy it is to extend and integrate with third-party systems, and how well it can scale.

We explain in depth why each of these criteria is important and how they are relevant to differnet IoT use cases in our How To Choose A Rules Engine e-guide. Check it out to better understand which combination of features and functionality you need to be looking at for your particular IoT business case.

01 | Modeling complex logic

Real-life application logic is complex, it will inevitably involve more variables than any textbook example. Combining multiple non-binary outcomes of functions (observations) in the rule, beyond Boolean true/false states. Dealing with majority voting conditions in the rule. Handling conditional executions of functions based on the outcomes of previous observations.

02 | Modeling time

Dealing with the past (handling expired or soon-to-expire information). Dealing with the present (combining asynchronous and synchronous information), Dealing with the future (forecasting for prediction and anomaly detection).

03 | Modeling uncertainty

Uncertainty is unavoidable, and the rules engine should have a mechanism for accounting for it in the way it builds logic. Noisy sensor data or even missing data is common in IoT applications where we often deal with wireless sensors which ARE fully dependent on the battery lifespan, intermittent network connectivity or with network outages making API endpoints unreachable.

04 | Explainability

The rules engine should include explanation capabilities that make it easy for its users to understand why rules fired (or not) and identify and correct errors. In other words, being able to build and run complex logic is important, but the engine’s internal complexity should not come in the way of its users being able to easily test, simulate and debug that complexity. Users require a high level of understanding and transparency into decisions with inherent risk.

05 | Adaptability

Flexibility: Things inevitably change, both on the business side (changing customer requirements for a particular family of devices) and on the technical side (API changes) and the rules engine should be flexible enough to support change with the least friction possible.
Extensibility: In order to account for future growth, the rule engine should be capable to support extensions and integration with external systems, such as third-party API services.

06 | Operability

Operational scalability: When deploying applications with many thousands or possibly millions of rules running in parallel, the engine should effectively manage the large volumes, by supporting templating, versioning, searchability, bulk upgrades, rules analytics.

07 | Scalability

Although horizontal scalability is more of an implementation effort than a capability of a particular type of rules engine, to enable easy sharding, the rules engine should provide a good initial framework and abstractions for distributed computing. Sharding is a well known concept in database design and refers to a component that can be horizontally partitioned, which enables linear scaling - deploying n times the same component leads to n times improved performance.

Rules Engine Benchmark Results

Modeling Complex Logic Modeling Time Modeling Uncertainty Explainability Adaptability Operability Scalability

  • Forward Chaining engines: Redhat Drools, Cumulocity, Eclipse Smart Home, AWS rule engine, Thingsboard
  • Condition/action: ifttt.com
  • FBP engines: Yahoo! Pipes, Node-RED (and various clones), Eclipse Kura. Most of the SaaS automation rules engines are of this type.
  • Stream Processing engines: Apache Storm, Flink, Samza
  • CEP engines: WSO2, Litmus or Foghorn.
  • FSM engines: AWS Step functions, IoT Explorer from Salesforce
  • Decision trees: Drools decision tables, OpenL Tablets

Please note this list is not exhaustive and only includes some of the most common rules engines.

The right automation tool for the Internet of Things

IoT application design is quite different from typical IT solutions, in that it bridges the physical world of Operations Technology (OT) with sensors, actuators and communication devices, and the digital world of Information Technology (IT) with data, analytics and workflows. In an enterprise environment, IoT is very complex, not only because IoT deployments in large organisations will almost certainly need to quickly scale to thousands and then hundreds of thousands of devices (or sensors) and more, but also because the solution needs to work across all other enterprise systems and comply with specific enterprise software requirements. This bridging of two worlds has important and unique consequences over how business logic and business rules are built within the IoT application.

Rules Engines Score per IoT Vertical

The scores displayed below don't consider all IoT requirements for a given vertical, but only focus on those requirements that are applicable to automation in particular and using a rules engine to implement the most typical automation scenarios per that vertical.

Automation requirements per IoT vertical market

How do the different rules engines score per IoT Vertical?

Rules Engine Smart Home Conn. Buildings Industry 4.0 Edge   Health Care Agriculture Track./Utilities Smart Cities
Score: ∑ vertical[category] * rules[category]


IoT application development involves working across multiple dimensions, combining streaming data with data at rest to connect physical products with people and business processes. Building logic by configuring rules straight into your code is sub-optimal. Using a rules engine may alleviate the problems, if the engine meets a number of core capabilities that respond to the specific requirements of IoT.

Get the full benchmark report

Rules engine blogs

Request a demo

Email us