An IIoT Sensor to Cloud Gateway Solution 3

One of the primary use cases for the IIoT (Industrial Internet of Things) is to collect sensor data and deliver that to an enterprise cloud for enhanced real-time visibility in to remote operational systems.  This is very important for applications such as Oil & Gas, Manufacturing Plant Production monitoring, Healthcare Patient Monitoring and Power Substation Monitoring.  With advances in network infrastructure and the promise of higher bandwidth WAN (Wide Area Network) connections, the ability to pull raw sensor data across the WAN to a backend enterprise cloud where data processing and predictive maintenance solutions can be implemented, and monitored.  Enabling this type of architecture provides great agility for organizations to respond and react to changing conditions for their deployed systems.

There are a few issues that arise when trying to achieve this level of architecture.  The primary issue that presents itself is the sheer volume of data that must be sent from the deployed system back to the enterprise.  Allowing for individual network packets from each sensor is not feasible.  In addition, the amount of data from each sensor is constant whether its actually required on the enterprise side for evaluation.  Given the following diagram below, this architecture does not solve any of the problems that exist today for getting data from the sensors to the enterprise.  Bottlenecks will be seen in the WAN because of the number of data packets that must be handled is large and must be consistent.  As soon as bursts of WAN traffic occur, the ability for the enterprise to gather data for processing becomes increasingly difficult and unpredictable.

Trying to accomplish Sensor to Cloud with traditional solutions is not feasible

To enable a feasible solution today for getting sensor data back to the enterprise requires two key data handling pieces to be put in place.  First, the number of network packets must be reduced.  Second, there must exist some intelligence in the path of data that allows the enterprise side to declare what data it would like to access so that data that is not relevant is not sent.  Also this capability must be mutable as changing conditions must allow for the enterprise side to adjust the set of data it would like to access.

RTI provides a bridging capability called Routing Service exactly for applications such as these.  Routing Service is a logical based bridging solution that enables administrators to configure topic based routes that collect data from publishers on the input side and send data to any subscribers on the output side.  And because Routing Service is based on DDS, it enables the individualized setting of Quality of Service (QoS) on either side of a Topic Route.

One QoS that is available for setting in the Routing Service is Batching of data.  This capability provides an opportunity to batch or coalesce small pieces of data into larger network packets for more efficient transfer of data over the WAN.  The Batching has configuration controls that limit the size of the data packet and that limit the amount of time that exists between outbound packets.  This gives the user complete control over the bandwidth and latency profiles of the sensor data.  The net result is configurable bandwidth shaping solution that dramatically reduces the number of packets sent over the WAN by a factor of 10x or more.

The second capability that Routing Service provides the enablement of the receive side of a topic route to express a data filter that would limit what data is actually sent through the bridge.  For example, if the sensors on the deployed system were temperature sensors, and the receive side was interested in temperature values “ > 100 degrees F”, then the expression this filter could be configured on the receiving side of the bridge and Routing Service will propagate that filter to the original sending side of data.  Therefore data will be filtered at the original writer side and thus limits how many data packets must be sent over the WAN.  This filtering capability is builtin to DDS and thus Routing Service enables the use of it across any topic route in place.

The following diagram shows where Routing Service would be used in such an architecture.

With the use of DDS Filtering and Logical based Routing that incorporates Batching, Sensor to Cloud is possible.

This solution presents a very high level architecture with unique benefits to solve the problem of getting sensor data back to the cloud without the need to process raw data at the deployed site. Please contact us via email to request more information regarding RTI Connext DDS and Routing Service capabilities and using these products to address your specific requirements and challenges.

Additional Reading — Using Connext DDS in applications:

3 comments

Submit a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s