vasabii - Fotolia

What are the IoT industrial automation standards to watch?

PTC's CTO of industrial automation and former Kepware CEO Tony Paine explains why messaging technology is crucial for gathering data from connected devices.

Tony Paine has spent his career pursuing a passion for developing software that interacts with hardware, which he now directs toward the internet of things -- specifically, IoT industrial automation.

In 1996, he joined Portland, Maine-based Kepware Technologies as a software engineer, helping to develop KEPServerEX, a platform for collecting data from a variety of industrial equipment. He was CEO in 2015 when Kepware was acquired by PTC, a major player in computer-aided design and 3D modeling.

As PTC's CTO of industrial automation, Paine directs the development and integration of KEPServerEX and ThingWorx, a platform for applications for IP-connected devices, including the sensors that are central to IoT industrial automation. SearchERP interviewed him at PTC's headquarters in Needham, Mass.

What was Kepware up to before PTC acquired it?

Tony Paine, PTC CTO of industrial automationTony Paine

Tony Paine: When Kepware was born, my partner had thought maybe we could develop a low-cost human-machine interface [HMI] product that would run on Windows. That was back at a time where not only did you develop the actual visualization tools, but you also had to develop the connectivity to the various types of equipment you wanted to collect data from -- known as drivers -- that would plug in to the platform or any application.

Around the same time, standards were born that actually made it easy to collect data from various devices and equipment from many manufacturers, to applications, so that application developers didn't have to worry about this driver problem.

We sort of gravitated to [building] middleware that provided a great, robust generic software interface to equipment, regardless of the vendor, using a technology known as OPC [Open Platform Communications].

That's where we found ourselves two-and-a-half years in and said we're going to focus on genericizing connectivity, giving the data to you in a format that you can consume and understand.

Was that a technology that Kepware had or a standard?

Paine: It was a standard created by the OPC Foundation. Back then, when OPC was first born, OPC stood for OLE [Object Linking and Embedding] Process Control. Remember the old Microsoft Excel technology [allowing] drag-and-drop between applications? It was basically creating a service contract that vendors would adhere to and develop software solutions on top of that OLE technology.

Over the years, OLE has sort of gone behind the scenes. We're up to .NET now [and] HTML5. OPC today really just stands for open connectivity.

Kepware recognized that not everybody wanted to support open standards over the years. Some vendors had their own APIs for sharing information with third parties. So, Kepware was flexible. We basically said, in addition to OPC, we'll support what I would call 'open proprietary interfaces.'

Was it a collection of one-to-one integrations with popular vendors, or was there some more general way of doing it?

Paine: We took some of the same principles from our HMI design and basically said, 'If we have one application that can communicate to a bunch of drivers, why wouldn't we have one application that can connect to a bunch of pieces of equipment, regardless of vendor, so that you can be within one environment?' It allows us to do code reuse and say, 'If we add functionality that is genericized enough, everybody gets it. I don't have to go and touch 100-plus drivers if I do it right.'

One of the things we added was the ability to discover what types of information [were] in a piece of equipment. If we had created one-off applications for every vendor's product, like some of the big vendors do, we would have had to go in and a figure out how to put that into all those applications. In this way, what we did was figure out how to abstract away the vendor-specific details and sort of put in our own special sauce.

What made Kepware an attractive [acquisition] target is we had already abstracted away the vendor-specific details.

Often, de facto standards are the ones that take off. The vendor might have used some industry-standard features or languages, but it's still basically proprietary. Is that what is going on with IoT industrial automation?

Paine: It is. You've still got standards bodies like OPC that are trying to take their standards of yesterday and move them forward and take into account some of the requirements of this new world. For example, historically, OPC has been very much a client-server interface, where the client makes demands on that server. That worked great when you were within … the same four walls. It doesn't work so well over the internet.

So they've created [publish/subscribe-type] capabilities where the OPC server vendor, such as [PTC], could basically … start collecting data and publish that … out into the enterprise.

Vendors who are creating their own interfaces today are at least adopting open standards in how they represent the data: things like JSON [and] XML. Though they may be in a format defined by the vendor, there are tools, APIs [and] platforms that can easily take that apart and interoperate with it.

Which IoT industrial automation standards are you paying the most attention to?

Paine: We'll continue to look at [OPC] because it was born out of the industrial automation space.

I hate the word 'plug and play' because that's so '90s, but it is what it is.
Tony PaineCTO of Industrial Automation, PTC

We're also seeing some IoT standards that are making their way down -- things like MQTT [Message Queuing Telemetry Transport]. That basically is very much a message-queuing technology, where … a device inside a private network could collect data and push it to some external broker, and then that broker would live 'in the wild' where applications could subscribe to it and get notifications when something changes. [It's] much like chat or instant messaging. I don't want to say they're one in the same, but it's the same concept. We're all able to communicate behind firewalls because of the magic of that middleware broker.

The other one that we keep an eye on is AMQP. That was born out of Microsoft. It's the [Advanced Message Queuing Protocol]. That, too, is a vendor saying we have our own way of doing a queue; we're going to call it something else, and there's some overlap with MQTT.

I don't feel like it feels as open as MQTT right now. We're continuing to look at it. If AMQP becomes part of Microsoft Azure, then we'll obviously look at incorporating that in so that we can play nicely with that platform.

MQTT, given its openness, as well as its open data structure format, has been very appealing to a lot of companies.

Why are these IoT industrial automation and messaging standards so important?

Paine: They'll accelerate the integration between applications and devices or equipment that comes from a wide variety of vendors. Everybody can basically adhere to the standard [and] publish how they're going to represent their data. Fortunately, the computer science community has created lots of tools to be able to know how to deal with those standards and provide very rich interfaces so that people can get their data without really thinking about it.

Is only getting notifications when something changes about minimizing data transmission requirements?

Paine: Exactly -- really cut down on bandwidth. The last thing you want to do is have hundreds, thousands of clients connecting and continually polling an industrial automation network. Its primary job is to automate a process and build product. Giving people visibility into the current state is, in many ways, secondary. So, how do you make sure you don't put unnecessary load [on], but you provide the information that's needed when it's needed?

That's what those types of standards allow you to do. And they're very lightweight, so you could run them, obviously, on a high-speed network, but you could also run them out in an oil field, or some radio device that has intermittent communication.

What's the potential if industrial IoT takes off?

Paine: If [it] does what I think it's going to do, you're going to be able to just plug in industrial equipment, power it up, have things automatically discover that it's available and decide whether or not it's worth connecting to.

You aren't going to go in to any factory and see everything from a single vendor. You're going to have a mix and match of best-of-breed components. It's going to be plug and play.

I hate the word 'plug and play' because that's so '90s, but it is what it is.

Dig Deeper on IIoT in manufacturing