The time dimension increases the complexity of application development for software developers that are building logic with conditional statements (rules) that need to change over time.

‍

“Time is an observed phenomenon, by means of which human beings sense and record changes in the environment and in the universe. Time has been called an illusion, a dimension, a smooth-flowing continuum, and an expression of separation among events that occur in the same physical location.” — whatis.techtarget.com

‍

Imagine that you wake up in the middle of the night to the sound of your dog barking. You then hear footsteps from your kitchen. Just as you’re about to call the police, you remember that your friend Tom is sleeping at your place over the weekend and it’s probably just him getting something from the kitchen. As you hear the familiar sound of the fridge door and bottles clinking, you are now sure it’s him and immediately go back to sleep.

What we can see with this short story is that the order of events in time, in combination with their joined likelihood is what triggers us to take further action. In the previous section, we have introduced formal logic, which would govern the world if the world was a static place. It isn’t.

If we were to look for a safe refuge in computer language to help us deal with the time dimension while building logic, similarly to what music notes are doing for music, we would find nothing.

‍

To deal with time in the code, all we have at our disposal is a “CPU clock”. We often make use of UML State/Flow diagrams to help us with time, but UML is a “language” for specifying, visualizing, constructing, and documenting the artifacts of the software system. UML helps us communicate what we want to build, it’s not a framework for building software.

With the introduction of time, the developer needs not only to understand the different pathways and the results of those pathways (as explained in this blog post on formal logic and inductive reasoning), but she also has to grasp how these pathways change over time.

In other words, time adds complexity. The right rules engine will abstract away the complexity so you can build time-bound logic, but in order to do that it should support the following:

‍

1. Dealing with the past (handling expired or soon-to-expire information)

You often have to use information that is only valid for a fixed period of time or merge data streams that are not fully in sync. This is important in connected home, connected building or industry 4.0 applications. Here are a couple of specific examples to IoT:

• If there is motion in the living room, followed by motion in the sleeping room, then (…)
• If there is motion in the living room but no motion in the sleeping room within the next 5 minutes, then (…)
• Apply this rule only if temperature and humidity data from two different sensors comes no more than 10 seconds apart
• Check if the state of the machine has changed between two consecutive measurements (and within a window)

‍

2. Dealing with the present (combining asynchronous and synchronous information)

You often times need to combine asynchronous data flows (streaming IoT
device data) with synchronous information (polling cloud service API endpoints) at the time a rule is executed.

A simple user requirement such as: “Send an SMS alert whenever the freezer temp is above 4 degrees” translates into this rule: “When the freezer’s temperature is above 4 degrees, check the asset database (over API) to find the location of the warehouse where the freezer is. Then check the weather at that location (to verify if it is not too warm outside). Then create a ticket in the CRM database, before sending SMS to the person that operates the building in which the freezer is located”.

‍

3. Dealing with the future (forecasting for prediction and anomaly detection)

Anomaly detection is typically derived from time series data and it is usually formulated in two different ways:

finding outliers (values that are highly above or below the average / rolling average) or finding the time window in which the standard deviation is higher than the expected value
data points that differ too much from expected values – which are mostly statistically derived. In this case, anomaly detection and forecast rely on the capability of the rules engine to find a good “fitting algorithm” for the observed measurements.

‍

‍

We argue in our white paper How To Choose a Rules Engine: Seven Things to Look at When Automation for IoT that logic and time are two of the biggest challenges that using a rules engine can solve. A third one is brought about by the concept of uncertainty.

‍