Delivering IIoT Data Across the Enterprise

Arlen Nipper, president and chief technology officer at Cirrus Link Solutions, a supplier of IIoT, SCADA, and MES applications, explains that, “data easily understood by OT (operations technology) functions—for example, temperature—may be unusable in the IT realm without more clearly defined parameters describing the data. The IT world may look at a piece of temperature data with no idea if it is scaled across a range like 0 to 4095, Celsius or Fahrenheit, and so on.”

To address this lack of data understandability across systems, Nipper says some companies are solving this problem by manually editing tags in multiple applications outside of OT. “But that process is time consuming, error prone, and inefficient,” he says.

A few months ago, Automation World reported on the launch of the Sparkplug Working Group. This group was designed to address the data transferrance issues noted by Nipper. More specifically, the Eclipse Foundation, which hosts the Sparkplug Working Group, describes the work of the group as being focused on “the definition of technical specifications and associated implementations that rationalize access to industrial data, improve the interoperability and scalability of IIoT solutions, and provide an overall framework for supporting Industry 4.0 for oil and gas, energy, manufacturing, smart cities, and other related industries.”

Nipper explains that Sparkplug is “an open source software specification that provides MQTT clients with a framework to integrate data. The specification articulates three goals:

• Define an MQTT Topic Namespace optimized for IIoT;
• Define MQTT State Management to take advantage of continuous session awareness; and
• Define the MQTT Payload.”

Basically, Sparkplug adds features including birth certificate and death certificate (session awareness) to help contextualize plant floor data. Sparkplug defines how to publish and represent plant floor data so that any subscriber knows what it is and how to use it. This is an important addition to MQTT as MQTT only serves to publish data to a broker and deliver it to multiple consumers. MQTT, on its own, does not include a methodology for data representation. 

Nipper, who also happens to be one of the co-inventors of MQTT, provides another example to illustrate how Sparkplug can contextualize plant floor data for use by any system, anywhere. “Consider a Modbus protocol asking for register 40,027 returning a value of 2047.  Most data consumers will have no idea what 2047 represents. Is it a temperature? Is it a pressure? With Sparkplug, instead of calling the register 40,027, it would say: compressor temperature, scale from 0 to 100 degrees Celsius, tied to ‘X’ asset device, is 27 degrees Celsius. With all of the necessary textual information for the data included, instead of one proprietary piece of data, it becomes shareable across the enterprise.”

Beyond the basic transferrance of data, Nipper notes that, with Sparkplug, machine learning and artificial intelligence applications can use the same standard interface for data without having to know and understand the entire OT environment. “They can subscribe to the OT data and use it immediately for IT functions,” he says.

For more information about the Sparkplug Working Group, visit https://sparkplug.eclipse.org.