rIoT Engine Block Diagram and Functionality-A Brief Review
Main components of the rIoT Technology are rIoT Explorer and rIoT Engine
rIoT Engine: rIoT Engine is the worker component that provides connectivity between the field and the time-series services. To push data to the cloud service, rIoT Engine needs to map the field data into the time-series data structure. The mapping information is included in a configuration file. Without the configuration file, rIoT Engine is not able to push data into the cloud. rIoT Engine can work on both Linux and Windows targets
rIoT Explorer: Unlike rIoT Engine that works non-stop, rIoT Explorer is only invoked by the user to create or modify the configuration or monitor the values in the rIoT Engine in real-time. rIoT Explorer allows the users to download the configuration into the rIoT Engine. rIoT Explorer is a Windows application.
There are a number of built in client interfaces (a) that connect to the process to get the process data. Currently, rIoT Engine supports OPC DA Client and Modbus TCP Client as the native built-in client interfaces. In addition, rIoT Engine provides a simulation client interface to simulate client points. Simulated client points are great tool in learning the system and troubleshooting. Simulation interface supports the following methods of simulating data:
Ramps
Random values
Steps
Built in drivers use the host device services (b) such as IP stack or serial drivers to connect to the field.
Open Client Interfaces or OCI’s (c) allow the user to write their own client drivers. rIoT Engine exposes a set of standard API’s to access the core Engine. Users can call these API’s to push data to the Engine. OCI codes (d) can be developed by third party users or developers and the object codes can be included in the Engine assets and downloaded into the Engine. Currently, we have developed DNP3.0 Client using OCI interfaces, but as explained, users can develop their own OCI’s.
After data is brought into the engine, they are stored in database elements called streams. Each stream belongs to a device. Therefore, data hierarchy on the client side looks like the following:
Built-in client streams (e) host the values that are received through the built-in client interfaces. Data received from the OCI’s is stored in the OCI streams (f).
In addition to bringing data from the process, users can write their own scripts and manipulate the data. An example of useful scripts is aggregating data from different sources and presenting them in a single stream. Scripting (g) can be used for more advanced applications such as monitoring the system resources (memory, CPU, etc.) and pushing them into the streams. The data generated by the Engine scripting is pushed to the scripting streams (h).
Event criteria (i) determines when a client stream is required to be sent to the cloud or notifications services (upstream services). The following list shows the Engine event criteria:
Change in Value: Data is sent to the upstream services if the new value is different from the old value
Dead band: Data is sent to the upstream services if the new value is greater or less than the last transmitted value by a configurable dead band
Equal to Value: Data is sent to the upstream services if the new value equals to a preconfigured value. In this case, data is transmitted only once
Greater Than: Data is sent to the upstream services if the new value is greater than a threshold. In this case, data is sent only once. The stream value has to go back below the threshold by a configurable dead band before the Engine sends it again. This dead band is built into the scheme to prevent excessive transmissions if the value is fluctuating around the threshold
Less Than: Data is sent to the upstream services if the new value is less than a threshold. In this case, data is sent only once. The stream value has to go back above the threshold by a configurable dead band before the Engine sends it again. This dead band is built into the scheme to prevent excessive transmissions if the value is fluctuating around the threshold
Periodic: Data is sent periodically
Please note that more than one event criteria can be attached to a single stream. For example, imagine you have an analog value like pressure of a pump that you need to have periodic reading. However, you need to see the values in case of a sudden change of the pressure. In this case, you can attach this stream to Periodic and Dead-band event criteria.
Snapshots (j) are similar to event criteria in determining which values need to be transmitted. However, snapshots are more involved regarding the definition of the streams. In summary, snapshots create an image of the system around an event. To define a snapshot, user needs to identify a stream as the leading event that starts the process. There are other streams that are captured in the snapshot but do not start the snapshot. If you consider the leading event time as the time 0, you can specify values of the desired streams at different negative or positive times to be included in the report. Note that there is no limit on the number streams or intervals you include in the scheme. An example of snapshot reports is when you receive an alarm. You want to know the value for some of the parameters at different intervals leading to the alarm and status of the equipment that are supposed to take correcting actions to remedy the situation after the alarm happens.
Mapping groups (k) determine the destination of the client streams. Mapping groups use event criteria and map the client streams to one of the following upstream services:
Servers
REST API Interfaces
Email and notification services
Server interfaces, are cloud services that represent a structured tag or stream organizations. In the servers, data streams are created permanently, either by pushing the first data sample or by creating the structure upfront. Currently, there are three build-in Server Interfaces (n) supported by rIoT Engine: AT&T M2X, Wonderware InSights and GE Predix. New server interfaces can be supported by adding Open Server Interfaces or OSI’s (q). Similar to OCI’s, the body of the code implementation for the OSI’s (t) resides outside of the Engine but the code objects can be listed in the Engine assets and downloaded into the Engine. There are standard API’s exposed by the Engine that can be used by the developers to write their own code to interface with the Engine.
Server streams (l) contain the values for the built-in Server Interfaces. Similarly, OSI streams (m) belong to the OSI components. Mapping component maps the client streams to the server or OSI streams.
Unlike servers, there are other services that an explicit tag or stream organization does not need to be created. In this case, user can push data to the service by defining the right parameters for that service. Open REST Interface (o) is designed to support these services. Currently, the Engine supports Microsoft Power BI and Verizon ThingSpace, however, other interfaces can be defined by specifying the parameters easily. The mapping component maps the client streams to the right data structure to be sent to the service.
In addition to the server interfaces and REST endpoints, client streams can be managed to trigger email or text notifications (p) directly from the Engine. The message body and text is configured in the mapping component.
After the data is ready to be transmitted to the cloud services, it is passed to the transmission component. Transmission layer uses Transmission Criteria (r) to throttle the communication. As data arrives to the transmission layer, they are queued so that the previous events can be sent. An event is removed from the queue after Engine receive acknowledgment from the service indicating that the data is received. Transmission criteria is in charge of parameters such as number of events in a payload, retries and retry intervals.
Transmission component uses system services (s) from the host machine to send the messages out. A typical message is sent using TLS technology to make sure data transmission is secure and the cloud service is authenticated.
The built-in web server in the Engine is the component that provides for local communication between Engine and Explorer. Communication between two side is secure and authenticated using TLS technology.
