The time dimension increases the complexity of application development for software developers who are building logic using conditional statements (rules) that need to change over time. Time is an observed phenomenon through which humans perceive and record changes in the environment and universe. Time is called a continuum of illusions, dimensions, flow, and the expression of separation between events that occur in the same physical location. Imagine being awakened by the barking of a dog in the middle of the night. Then you will hear footsteps in the kitchen. Just as you were about to report to the police, you remembered your friend Tom sleeping at your house on the weekend, maybe he just took something from the kitchen. When you hear the familiar sound of refrigerator doors and bottles jingling, you are now certain it is him and immediately go back to sleep.

We can see from this short story that the chronological order of events, coupled with their joint possibility, is the reason that triggers us to take further action. In the previous section, we introduced formal logic, which states that if the world is a static place, it will rule the world. No. If we were to find a safe haven in computer language to help us build logic while dealing with time dimensions, just like notes do for music, we would get nothing. To handle the time in the code, we can only use the 'CPU clock'. We often use UML state/flowchart to help us process time, but UML is a 'language' used to specify, visualize, build, and document software system artifacts. UML helps us communicate what we want to build, it is not a framework for building software. Over time, developers not only need to understand the different paths and their outcomes (as described in this blog article on formal logic and inductive reasoning), but also need to understand how these paths change over time. In other words, time increases complexity. The correct rule engine will abstract out complexity so that you can build time-bound logic, but to achieve this, it should support the following:

1. Processing past (processing expired or about to expire information)

You usually have to use information that is only valid for a fixed time period or merge data streams that are not fully synchronized. This is very important in connected homes, connected buildings, or Industry 4.0 applications. The following are several specific examples of the Internet of Things:

If there is exercise in the living room and then there is exercise in the bedroom, then (...)

If there is movement in the living room, but there is no movement in the bedroom for the next 5 minutes, then (...)

This rule applies only when the temperature and humidity data from two different sensors are not more than 10 seconds apart

Check if the state of the machine has changed between two consecutive measurements (and within a window)

2. Processing Now (Combining Asynchronous and Synchronous Information)

You often need to combine asynchronous data flow (streaming IoT device data) with synchronous information (polling cloud service API endpoints) when executing rules.

A simple user requirement, For example, 'Send SMS alert when the freezer temperature is above 4 degrees Celsius' is translated into this rule:' When the freezer temperature is above 4 degrees Celsius, check the asset database (through API) to find the warehouse where the refrigerator is located. Then check the weather at that location (to verify if it is not too hot outside). Then create a ticket in the CRM database and send the SMS to the person operating the freezer in the building. '.

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

Anomaly detection typically comes from time series data and is expressed in two different ways:

The time window for finding outliers (values above or below the average/rolling average) or finding expected data points with standard deviations that differ significantly from the expected values - these data points are mainly statistical. In this case, anomaly detection and prediction rely on the ability of the rule engine to find a good 'fitting algorithm' for observed measurements.