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.
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.
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
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.
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.
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.
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).
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.
The Waylay rules engine is an inference engine based on Bayesian Networks (BN).
The engine models rules using the Smart Agent concept that consists of Sensors, Logic and Actuators. It decouples logic from sensing and actuation. This provides very simple and compact logic representation, further enhanced by the use of the DAG model.
The Waylay rules engine models the information, control and decision flows independently. This empowers the rules designer to have full control over the rules execution.
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.
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.
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).
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.
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.
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.
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.
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.
|Modeling Complex Logic||Modeling Time||Modeling Uncertainty||Explainability||Adaptability||Operability||Scalability|
Please note this list is not exhaustive and only includes some of the most common rules engines.Close
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.
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.
|Rules Engine||Smart Home||Conn. Buildings||Industry 4.0||Edge||Health Care||Agriculture||Track./Utilities||Smart Cities|
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.