Straight talk on industrial integration

Hybrid environment of proprietary and open-source standards will persist.

By Kevin Parker September 10, 2017

As the Industrial Internet of Things (IIoT) unfolds, will it avoid the pitfalls that have plagued previous generations of integration tools? If there can be such a thing as irony in industrial automation, then it’s ironic that the myriad device drivers originally promulgated for supervisory control and data acquisition (SCADA) integration continue to play such a big role in industrial environments, even for emerging areas like industrial cybersecurity.

"It is an integration sticking point," said Tony Paine, CTO, industrial automation, at PTC. "While the reality of having individual device drivers for integration of many different data sources will persist for some time to come, the layer of abstraction above the device driver, the application programming interface, can be distilled into a half-dozen to a dozen or so standards."

Given the mix of devices in the installed base and in the new generations of technology coming on line, Paine sees a hybrid approach continuing for some time. "When it comes to new technologies, product designers realize that devices no longer stand alone. Rather than every supplier writing one-off device drivers, they will likely choose from a menu."

Middlemen remain relevant

Examples of standards relevant to these efforts include transport protocols MQTT, CAP for small sensors, AMQP from Microsoft, and web services in a generic sense, Paine said, adding, "Through the OPC Foundation, suppliers are coming together to insure interoperability."

The OPC interoperability standard defines an interface between clients and servers, as well as servers and servers. When the standard was first released in 1996, its purpose was to abstract PLC-specific protocols, e.g., Modbus or Profibus, into a standardized interface allowing SCADA systems to interface with a "middle-man" who would convert generic OPC read/write requests into device-specific requests, and vice versa.

More recently, "the new sensor gateways are a way to network many different type sensors, acting as a connectivity bridge for use of these transport protocols," said Paine. Gateways are moving down to the sensor level, just as control functions are.

"Even if middleware modalities are still often needed, that also will be an appliance," said Paine.

The same kinds of concerns apply to modeling and the propagation of digital twins. "Everyone will have a modeling scheme, but we don’t want to map to every vendor. The OPC-UA standard plays a role here, providing companion specifications on how to model a given protocol," said Paine.

An ecosystem of your own

The automation companies have gotten pretty good at adapting what works in consumer and commercial markets to the industrial marketplace. Fieldbus standards like HART, Profinet, and Ethernet IP originated from major automation suppliers having the resources to create an ecosystem of their own. However, the standards have subsequently been released to open source.

"A lot of great, formerly proprietary information has been made available," said Paine, "but the decision still has to be made to support a particular standard."

That’s one reason why Paine is convinced further progress in interoperability and integration depends on partnerships that reduce development risk, provide guidance for users, and solve what is at the end of the day a kind of chicken-or-egg conundrum.

Kevin Parker, senior contributing editor, CFE Media, kparker@cfemedia.com.

This article appears in the IIoT for Engineers supplement for Control Engineering and Plant Engineering.

– See other articles from the supplement below.


Author Bio: Senior contributing editor, CFE Media