In my previous post, I discussed our research work — Kura Wires through which we are aiming to solve some intricacies involved in implementing several use cases in Industrial IoT scenarios.
Today, I would like to give you an overview on how Kura Wires would try to solve a specific and pervasive use case.
The main objective of Kura Wires is to wire or connect reusable components together to allow for the configurable cooperation. For instance, a temperature sensor can be connected to a Kura-powered service gateway to publish its temperature data to a cloud platform in a timely manner. In a similar use case, industrial devices with different protocols can also be connected to the IoT service gateway, leveraging configurable options for publishing specific or filtered data to remote servers or cloud platforms for further aggregation and analysis.
This scenario is probably most often found in factories in which the operator or industrial engineer accumulates data from several PLCs connected to an IoT service gateway and sends the machine production data to the cloud integration platform for further aggregation and analysis.
Before we start discussing how we can solve implementing such a generic Industrial use case, we would like to introduce some terminologies required to understand Kura Wires.
- Composer UI: It is the canvas area for Kura Wires in which the dataflow graph will be created.
- Logical Block: A Logical Block is a visual element in the Composer UI, which is represented as a node in the Kura Wires dataflow graph.
So, inherently a Logical Block can (not always though) have 0 to n number of inputs and 0 to n number of outputs.
Few logical blocks can have either of them, whereas some will have both of them.
- Computational Block: A Computational Block is a Logical Block, capable of receiving, processing, and emitting data to the connected downstream logical blocks. It can be, for example, data store, data filter, or data publisher instances that will be used to manage data.
- Wire: A Wire is a logical connection between the Logical Blocks, which allows us to define a concrete dataflow in Kura Wires.
- Asset: An Asset is a Logical Block that is capable of communicating with specific sensors and/or actuators of Industrial Device using specific protocol implementation.
- Wire Graph: A Wire Graph is a dataflow graph comprising several aforementioned Logical Blocks, which represents an Industrial IoT application scenario.
Wire Graph Example
So far, we have talked about several Kura Wires specific terminologies which we will be using throughout this post to understand more about Kura Wires.
Now, we would like to see how Kura Wires tries to take away the difficulties in implementing the aforementioned scenario. The following diagram shows the Wire Graph implementation for our chosen scenario.
Here, in this example, we can see several Logical Blocks incorporated in the Wire Graph, for instance, different instances of Timer, different types of Asset, DB Store, DB Filter, and Cloud Publisher.
- Timer: It is a specific Logical Block that is configured with a period and triggers an event on every configured interval.
So, Timer 1, Timer 2, and Timer 3 are different instances of the Timer logical block, which are configured with different time intervals.
You can see that the different Timer instances are wired to different instances of Asset.
- Modbus Asset: A Modbus Asset is an Asset representing a Modbus Device in the Wire Graph.
- OPC-UA Asset: An OPC-UA Asset is an Asset representing an OPC-UA Device in the Wire Graph.
- S7 Asset: An S7 Asset is an Asset representing an S7 Device in the Wire Graph.
- DB Store: A DB Store is a Computational Block representing a database storage.
- DB Filter: A DB Filter is a Computational Block, capable of filtering data by creating dynamic database views.
- Cloud Publisher: A Cloud Publisher is a Logical Block that is responsible for publishing data to the configured Cloud Platform.
These different logical blocks in the Wire Graph are properly configured, such as the interval in different instances of Timer, the different channels to read or write data from/to the industrial device, the database storage configuration to store data locally, and the database view query to perform aggregation on the locally stored data and so on.
So, according to our developed Wire Graph, different Timer instances will emit events on configured intervals, which will trigger read and/or write operations on the configured channels, and the device data will be emitted to the downstream DB Store logical block to store the data locally. The DB Store then emits an event to the downstream DB Filter logical block to filter the locally stored data. Thereafter, the filtered data will be sent to the wired Cloud Publisher logical block, which publishes the data to the configured Cloud Platform.
We strongly believe that such visual dataflow programming approach will help users to focus on their own application scenario more rather than writing applications in Eclipse Kura to do the same. Our approach in Kura Wires is very much extensible so that developers can even focus on developing their own Logical Blocks to create a different Wire Graph to implement some different IoT scenarios.