Message Routing¶
1. Introduction¶
In the advent of IoT, lot of devices/sensors are connected to the cloud platform which generates lot of data/messages and these data/messages are being streamed to the cloud for further processing. In the cloud, we need to clean, filter, transform, enrich and then process this streaming messages/data for extracting meaningful information and this to be done on real time in order to process and detect events as soon as possible so that possible business action can be taken immediately.
Message Routing service provides the capability of rule-based filtering, transformation, enrichment and routing of sensor data streams in real time. It allows users to define rules with one or more conditions. Rule’s conditions is checked on every sensor observation data on real time basis and if the rule condition is satisfied the data is sent to the selected destination or sink. Rules allow different sensor outputs to be cleaned, grouped and filtered for the other applications/services to consume. Routing can be done based on identity of sensors, the real-world object being observed, the property being observed, value of the measurement and location coordinates of the sensor. Further, any business rule can be written using expression evaluation which is in line with the concept of zero coding.
1.1 Intended Audience¶
The intended Audience of this document is anyone who wants to have an overview of TCUP Message Routing Service. After reading this document user will understand the capability of TCUP Message Routing Service as an IoT platform.
2. Key Concepts¶
In order to use Message Routing Service, the user needs to understand the basic concepts and building blocks of Message Routing Service. Please refer to the following section:
2.1 Source¶
All observations coming from sensors converges to a single point known as source, so that different rules can be executed by subscribing to the source. The source receives observation from Sensor Observation Service or Device Management Service. Each rule internally reads from source and once the condition is satisfied it sends it to the destination or sink as per the defined routing rule.
2.2 Routing Rule¶
Routing rules are user defined filter conditions, based on which message router routes the sensor observation data stream to different destinations. Message router receives sensor observation data from source. Based on routing rules it filters and posts sensor observation streams to a destination/sink. Other service/user application can receive the filtered observations upon subscribing to the destination’s address.
2.3 Sink¶
Sink is the entity in which filtered messages from the output of Message Routing service gets published for consumers.
3. Functional Capabilities¶
Message Routing service provides the following functional capabilities:
This service allows the user to create rules based on the template provided in the service which consumes an observation from source and republishes it to a sink depending on a set of conditions. Here user have to specify the source (input), condition logic and sink (output) while creating the rule. Once a rule is created it gives a rule ID.
Read and write data into in-memory database and use them in the condition evaluation.
Filtering condition can be based on:
Sensor’s location (latitude & longitude) with bounding box
Sensor observation time
Sensor observed properties and their values
Sensor ID of the sensor posting observations or the asset/Feature ID of the asset which is being observed
Regular expression processing on text type parameters/properties and/or sensor ID
Value Check for Quantity/Count type parameters/properties of sensor
Geo-fencing – ability to detect conditions based location information provided by the sensors. Users can define a location bounding box and then define a rule to generate alert on entry and exit of the sensor in the defined boundary.
Multiple conditions can be logically combined using operators such as AND / OR
Allows to start/ stop the created rules. The rule becomes functional only once it is started.
Statistics related to defined rules can be viewed i.e. number of messages processed, failed and succeeded.
Any data can be stored in the in memory database using a rule, and another rule can read the stored data.
Both, at-most once and at-least once data processing guarantee is supported. User will be able to configure this by setting a flag. At-least once processing will provide reliability.
4. Purpose/Usage¶
Many applications can be built using Message Routing service.
Some of the common usage patterns are as follows:
Rules can be written to clean sensor data for further processing.
To generate alert in a patient care system. Consider the case where care giver wants to have an alert when blood pressure of the patient is beyond the normal range. MR rule can be used to generate this alert. It can draw inferences/conclusion based on sensor data. So instead of sending raw pressure data from sensor, MR allows to define inferences like “high pressure”, “low pressure” etc. on the observed data.
To transform sensor observation data generated in process monitoring system. Consider the case where in a factory there are multiple blast furnace installed whose temperature are being monitored using temperature sensors. Few of the temperature sensor are measuring value in Centigrade and others are in Fahrenheit scale. For further processing and comparison, it is required to convert all the values in Centigrade. MR rule can be used to convert the Fahrenheit values to Centigrade on the fly.
To track school bus and generate alert when bus is going out of the designated boundary. Using MR rule geo-fencing boundary based check can be implemented, which will send an alert to school authority when school bus is out of the boundary.
To track performance of machines in a factory. Consider the case where multiple PCB fabrication machine is installed in a factory sending events continuously. It is required to calculate throughput of each machine to track how many PCB gets fabricated each day. MR is used to keep counter of each machine for every throughput and emits updated throughput every time an event gets generated from the machine. Counter gets reset at the end of the day for each machine.
To generate a special alert when multiple alerts are coming from a sensor in a given time. Consider the scenario where multiple energy meters are installed at a site which can produce different alert type. Now we want to generate a special alert if an energy meter generates more than 10 alerts in a given time. MR rule can be used to keep the counter of the alert produced and send an output alert when number of alert exceeds 10 from a sensor.
5. Examples¶
Message Routing service is used in most of the IoT applications as they majorly deal with streaming data.
Consider an example of fleet management where different vehicles are running in the predefined location boundary. Different location boundaries are created and a vehicle or a group of vehicles are applied to a location boundary. We want to:
Detect if any vehicle moves out of the designated boundary.
Determine vehicle stop and start event
A sensor is attached to each vehicle via gateway, its observation data (message) are being pushed to a MR at an interval of every 10 seconds. Vehicle ID as sensor ID, current position, observation time and speed of the vehicle are being passed as messages.
The four rules mentioned below are to be created for the mentioned use case:
Location boundary - For each vehicle created and stored in in-memory DB using a MR rule.
Geo-fence alert - Rule is created which checks vehicle’s current location with defined location stored in the in-memory DB and provides geo-fence alert in case of entry and exit from the boundary.
Stop event detection - Vehicle when stopped for more than 10 minutes should be considered as stopped or parked.
Start event detection - Vehicle when running for more than 2 minutes should be considered as running.
6. Reference Document¶
Please refer to the following documents for more details about this service:
API Guide