SPONSORED BY: BECKHOFF
On a recent podcast with Smart Industry magazine, Daymon Thompson, senior product manager at Beckhoff Automation, explores how OPC UA is changing the industrial landscape.
Excerpts follow:
More Than Just Communication
I like talking about updates from any technology. And the OPC Foundation does a great job. They’ve been for quite a few years, always expanding and evolving the technology and the base, either for new technology requirements or user requirements. And they’re always working on new specifications and improving this thing over time. And it’s more than just the traditional things that people think about just OPC UA. It’s not just a communication protocol. It’s actually far more than that, with data modeling to be able to model what an entire machine interface looks like. And there’s been some recent kind of focus on doing new network topologies and really making it a lot easier to enable manufacturers and OEMs to enable their machines to be cloud connected or take advantage of different architectures. And what this is based on is a specification called the OPC Publisher Subscriber Communications Model. And for anybody that really wants to go look it up, it is part 14 of the OPC specification.
…
Machine to Cloud – OPC UA over MQTT
If you get a production line. Being able to set that up so that each one of these devices. Instead of having to know each other and actually every single other device it wants to communicate to. Knowing its name or IP address. It can really just talk to one central location called a message broker. Using this idea of MQTT as the transport. And MQTT, it’s really just the transport mechanism. So inside of it can be binary data, it could be popular JSON. But part of the problem is that the encoding needs to be kind of made up. It needs to be defined. The end user or the machine builder sort of have to sit down and say, well, in my system at the end user, the way that I want data sent to my ERP system, my data collection is in this JSON format or XML format or binary format, where each side of the communications really has to know exactly the format of each data and the data size.
Instead of doing that, OPC UA allows for the data typing to be common between those. So we say, hey, we use OPC UA on the ERP system, or on the data collection side, we use OPC UA on the machine side. Okay, we know how those data types look. And then using OPC UA Pub Sub over MQTT. Now I take the transport mechanism, which doesn’t care what the data is inside, and package it up in a very unified format. So some of the benefits are the machine builders and the end users can spend less time doing specifications on what that data contract between each point should look like and more time just discussing what data they need off of the machine. So removing the whole conversation specification of how the data should be encoded.
And it really helps even from a machine builder standpoint. An OEM can say: Look, if I can supply the data in this standard format, I don’t have to supply that different encoding for multiple different end customers and maybe even possibly write customized code for each one of those end customers that need to be maintained over time. Maintained and understood over time. There’s really a lot of benefits for both OEMs and machine manufacturers by standardizing that and like I said before, not having to choose, hey, I want to use the MQTT protocol because the infrastructure gains, but I have to figure out how to encode it. Now I can do the best of both worlds.
…
Machine to Machine – OPC UA over UDP
So, machine to machine, every manufacturer that has any kind of big line, they’re dealing with multiple vendors supplying the equipment, and sometimes they’re large enough that they can specify every piece of equipment needs to come with brand X. But we’re seeing more and more that that’s not the case. Maybe the experts in certain processes come from different parts of the world and they use different controllers. And then it becomes kind of a game of, well, what’s the common denominator? What kind of fieldbus can everybody speak? Because it’s not just exchanging slow data. We got to actually share some encoder counts or something to keep everybody up to speed. So now we got to figure that out. Like I mentioned, from a manufacturer’s standpoint, then you got to have these specifications for the OEM, and it’s just a lot of wasted engineering time.
So with the development of OPC Pub Sub, it means from that UDP platform, something really fast. You can then kind of stream real time data or near real time data, and it’s vendor neutral. So as more and more manufacturers implement this protocol, then it becomes easier and easier and faster for manufacturers to pull together a line to communicate between those machines. Again, not having to specify buying a bunch of extra hardware, I guess, to make everybody neutral or communications gateways and keeping those things maintained. So I think really at the end, the manufacturers are really the ones that kind of benefit. And the Pub Sub specification, like I mentioned, it allows us to go faster. And I think some people have a stigma that the OPC stack is pretty large and it’s slow. I don’t know about that. But Pub Sub over UDP definitely works a lot faster.
Speaking of that, the other thing I’ll mention is the OPC Foundation is actually working on more fieldbus level kind of communications or controller to controller communications, and that’s also over UDP. And we’re also specifying kind of the future doing that over TSN [Time Sensitive Networking]. So really being able to synchronize between the controllers. Like I mentioned, it’s kind of the beginning, really. The OPC Foundation is really doing a good job of looking into the future, what companies need. And at the moment, the biggest thing to make all this work, honestly, is getting vendors to implement this. More controllers and different automation equipment suppliers are implementing the UDP transport of OPC.