Top Performance for Industrial IoT

T he Industrial IoT is different from the regular IoT. Mission-critical industrial systems are not like consumer or business IT applications. Performance is crucial. Most IT systems are built around a relational database, a repository of data that clients can add to or access, where a response time of a second or two is acceptable. IT data is typically sent across a network via HTML or XML, which adds complexity to the raw data, and consumes bandwidth. Although fine for office or home use, these technologies are not sufficient for the Industrial IoT.

In a typical industrial system, the data flows in real time. It moves from a sensor, device, or process through the system, often combining with other data along the way, and may end up in an operator’s control panel, another machine or device, or special-purpose data historian. As plant or field conditions change, the data arrives in real time, and the system or operator must react. A robotic arm or other device can send hundreds of data changes per second. Tiny, millisecond fluctuations in the data set can have significant effects or trigger alarms, and often each minute detail needs to be accessed in a trend chart or historical database.

Achieving this kind of performance on the Industrial IoT demands an exceptional approach to data communication.

  • A real-time, in-memory database keeps the data moving. The data needs to flow quickly and effortlessly through the system, and an in-memory database is needed to support these rapid value changes. A relational database, the familiar workhorse of the IT world, is not built for this specialized task. It takes too long to write records, process queries, and retrieve information. Thus, an in-memory, flat-file database, is a good choice, allowing for higher data throughput.
  • High-speed data integration connects any data source with any user. A key task of the in-memory database is to integrate all sources of incoming data. If all communication is data-centric (see below), then every data source can be pooled together into a single, universal data set. This design keeps the data handling as simple as possible, allowing any authorized user to connect to any specified combination of data inputs in real time.
  • Publish/subscribe beats polling. In a publish/subscribe, event-driven model, a user makes a one-time request to connect to a data source, then gets updates whenever they occur. By contrast, polling sends regular, timed requests for data. This wastes resources when data changes are infrequent, because multiple requests might return with the same value. At the same time, polling is also inaccurate during rapid change, because a burst of several value changes may occur between polling cycles, and will be completely lost.
  • High-speed “push” data sources are most effective. The data should be pushed out to the system, and then pushed to the user. In addition to being a better security model, this approach is also more efficient. To “pull” data from a source requires polling, which takes longer and uses too much bandwidth, because each data update requires two messages: a request and a reply. Push technology only requires one message, which is more efficient, consumes less bandwidth, and also enables machine-to-machine communication.
  • Data-centric, not web-centric, design gives the best performance on the cloud. Transcoding data at the source takes time, and requires resources on the device which many smaller sensors may not have. By keeping the data in its simplest format, with no HTML or XML code, the lowest possible latency can be achieved. The raw data flows from the source, through the cloud, to the user as quickly as possible. When it arrives it can be converted to other formats, such as HTML, XML, SQL, etc. Different users, such as web browsers, databases, spreadsheets, and machine-to-machine systems can access a single data source at the point of its arrival, reducing the volume of data flow in the system.

Skkynet’s implementation

Following these principles, Skkynet’s SkkyHub™ and DataHub® provide in-plant or IoT networking speeds of just a few milliseconds over network latency, with a throughput of up to 50,000+ data changes per second. Their high level of performance is achieved by combining real-time, in-memory database technology with publish/subscribe, pushed data collection and a data-centric approach to communication.

The “Hub” technology in DataHub and SkkyHub is a real-time, in-memory, flat-file database, used in hundreds of mission-critical systems worldwide for over 15 years. Designed from the ground up for industrial data communications, the DataHub and ETK work by converting all incoming data into a simple, internal, raw-data format. This raw data can be integrated and transmitted at very high speeds.

At the plant level, the DataHub collects, integrates and redistributes process data in real time. Selected sets of data can be passed seamlessly to the IoT simply by connecting the DataHub or ETK to SkkyHub. At the cloud level, SkkyHub provides the same real-time data collection, integration, and distribution. IoT performance now approaches the actual network propagation speeds of the Internet, with virtually no added latency.

Quite honestly, we shouldn’t expect the typical IoT platform to provide this level of performance. Few, if any, were designed for the Industrial IoT. It should come as no surprise that a concept as disruptive as “Industrial Internet of Things” may require new approaches for proper implementation. And in addition to performance, industrial applications have unique security and compatibility requirements. When choosing a solid, robust platform for Industrial IoT, these are all critical factors to consider.