074. Industrial Networks Series – Interoperability and Ethernet/IP

K: 00:00

With the many platforms that are available, do select and utilize a protocol that doesn’t constraint you to their product only. 

Chris: 00:12

Welcome to EECO Asks Why. A podcast that dives into industrial manufacturing topics, spotlights the heroes to keep America running. I’m your host, Chris Grainger, and on this podcast, we do not cover the latest features and benefits on products that come to market. Instead we focused on advice and insight from the top of minds of industry because people and ideas will be how America remains number one in manufacturing in the world.

All right. So welcome to this episode of EECO Asks Why. Today we have with us, our resident expert, Mr. K, who was our solution architect. And we’re going to be digging even deeper in industrial network topics. Today, we’re going to be spending some time talking about operability and ethernet IP. So K just the term interoperability, how would you define that? 

K: 01:02

Interoperability is the ability of a machine or product being able to exchange or send information and the other node that is receiving it is able to process and utilize the information. So basically if you look at interoperability, it’s  an open platform in where nothing is really proprietary. We’re able to use information from all and every single components that sends data. 

Chris: 01:37

Okay. So. The way I understand that is work with other products, present or future. No restrictions. Is that correct? 

K: 01:46

That’s the gist of it? Yes. 

Chris: 01:48

All right. So let’s talk about Ethernet IP and why that protocol is inter-operable. 

K: 01:52

So ethernet IP can be somewhat confusing to individuals that don’t understand what it is. Because when we’re talking about ethernet that’s your standard term. So for instance, I’m going on the internet. We commonly refer that yeah. Just hook up to the ethernet. 

Okay. Where it’s easier to bring that information up versus you’re in an IEEE802.3 or whatever. But ethernet is that foundation that ethernet IP works off of. So when we understand that ethernet IP works off of the standard TCP IP, which stands for transmission control protocol, and then the IP version is your internet protocol. So keep that in mind when we get a little bit further. 

When we’re talking about ethernet, IP course, ether, net is still referring to the ethernet that it’s running off of, but the IP on internet and doesn’t mean internet protocol. It means industrial protocol. So there’s your distinguish of ethernet and ethernet IP. It’s gets confusing, but, yeah, the gist is, that’s what it means. 

Now with ethernet IP, how’s it interoperable? Well, if you look at it, it’s using the same media as your standard ethernet, your four pair or your two pair, and it’s using the same jack. It’s using basically your standard office or enterprise level ethernet.

What’s different about it is ethernet IP managed by ODVA is the governing body of CIP ? Your common industrial protocol, which entails ethernet IP, control net, device net, so on and so forth. These are the governing body that manages and the standards and specify how protocols and whatnot are supposed to run are supposed to work.

But it’s the term operability is, there’s not a restricted product. As long as you meet the specification of ODVA, every single vendor or manufacturer is able to play in that realm. 

Chris: 04:19

ODVA. What is that stand for? 

K: 04:22

It’s the open vender device association, something very similar to that. But they are the governing body for what ethernet is. Eithernet IP. And so when, say a manufacturer, obviously ODVA deals a lot with Rockwell Automation. But if another manufacturer such as a EATON or Yaskawa or ABB or whoever it is wanted to connect, you utilizing ethernet IP, they would follow the specification of what ODVA has specified, and get certified and put out their products. 

So there’s really no restriction in terms of what it can and cannot use. There’s a certain groups that they have to follow. Assemblies , instances, so on, so forth. So as long as those are met ODVA says, Hey, it’s all open for whatever you guys want to do.

Chris: 05:23

Right. And at that point, those devices or the it’s all talking at that point ? 

K: 05:28

Correct. So it utilizes ethernet IP and ethernet IP is based on object oriented. So it has a TCP object. It has a device object. And it gets into the point where all these objects are sent and everything is based on your OSI layers. Your seven layers. OSI basically stands for your open system interconnect which is based on the seven segment of ethernet. 

Once the ethernet IP are utilizing that same stack. They’re able to communicate and send data to and from each device as you would on the standard ethernet connection.

Chris: 06:15

Okay. That helps a lot. So thank you for that, K. And let’s move to device profiles. Now, if we’re talking interoperability ,at the end of the day, we’re trying to move data in a meaningful way. From those smart devices that are out there, it seems like every day we’re getting information from vendors about this new solution or this new product that’s able to move this data across this industrial platform, whatever it may be. 

Can you walk us through a typical device profile that we may run into on a plant floor? I know you you’ve done a lot with VFDs. Variable frequency drives. But there’s so many different devices out there.  Walk us through typically what you would see in a device profile when you’re working with this on the floor in a plant environment. 

K: 06:56

Yeah. So VFD, let’s start there. I think that’s a good topic to go look at. I previously mentioned ethernet IP is object oriented. So when we’re looking at data,  you have your specific encapsulated  packages that has the information of, okay, where am I sending it to? What type of speed am I going to command this VFD? What am I getting back from this VFD? All these are objects and instances and attributes that are within this device profile.

When we’re talking about integrating, say into a control logics platform, the device profile itself is defined within the software. When we’re connecting to it, we define the IO assembly that we’re trying to connect to. So ethernet IP allows two different types of connections.

One is a explicit messaging. And two is implicit. The implicit acts as a connected IO. Where explicits is a class two, which is more of a event driven. For instance, if I wanted to get information from a VFD and it doesn’t have faults changing all the time. I would trigger to get that information only when they there’s a fault that occurs.

Just to clarify, our speed, our reference, and any data that are live, we want to have and utilize that in your implicit IO connection. We’re now, if we kept reading the faults, you’re going to get the same fault of nothing, nothing, nothing. Until actually a fault happens. So that’s wasted bandwidth, wasted processor overhead that is being utilized if we don’t properly select what type of messaging where you’re standing or utilizing. 

Chris: 09:01

Very good. Think about our listeners right now for a minute and potential gotcha moments with operability that engineers could consider or should consider rather. When things may not go right. Do you have any examples there? 

K: 09:16

Yeah. So typically if there’s an issue with interoperability first of all, we, we’ve got to make sure the components that you are utilizing is designed for Ethernet IP or, or has been specified or certified by ODVA. That’s the first and foremost. The next thing we need to consider is are you following the specification of those objects that has been specified?

So if, if you take a step back and we’re talking about VFD, whether it’s ABB, Yaskawa, Allen Bradley or many of these other vendors. When I say interoperability, the speed reference, it’s always going to be in this group. You’re a command reference, it’s always going to be in this group. So there’s a defined location of how things have to be group in order to be interoperable. Because if I had a VFD one and I wanted to it with VFD two, utilizeing ethernet IP, the generic commands should be identical. I could bring manufacturer a and replace it with manufacturer B and all the functions should remain exactly the same. Now that being said, ODVA allows a vendor specific objects.

That allow the vendor to input different types of additional information to do different functions. Now those are not associated with the standard. So that could be where the troubleshooting would come into play. If it’s two different products, we have to be certain that, okay, this particular object or class is the same as manufacturer a and B.

Chris: 11:17

Gotcha. I’ve heard a lot of times. On a similar path protocol converters. And customers that are working with that and operability, what should they consider when you’re working with a protocol converter? Trying to go that route. 

K: 11:30

So protocol converters are utilized from going to one industrial protocol to another. Just because a vendor A doesn’t support vendor B’s protocol. One thing we need to consider is the amount of data being translated at what speed it’s being translated. Because while protocol converters can exchange information, there’s some buffering going on there. And the application will determine which protocol converter or which hardware is selected to perform the task.

Chris: 12:11

Okay. That makes sense. I just need to keep all that in mind when you’re doing that conversion. 

K: 12:16


Chris: 12:16

Very good. So, K. What advice you have a lot of experiences as our listeners are aware, what would you like to provide to the people that are listening consider when they look at their network or devices or overall interoperability? What advice would you give those listeners out there? 

K: 12:34

So with the many platforms that are available, do select and utilize a protocol that doesn’t constraint you to their product only. So if you utilize an ethernet IP , most other manufacturers and vendors will support that protocol.

That is definitely something to consider. If you’re looking directly for DeviceNet there’s many vendors that support that, but it’s, it’s more of a less seen or utilized protocol. But do look at an industrial ethernet base protocol, because as much data’s are being moved and transmitted , that definition of interoperability, the other computer, component or hardware has to be able to utilize that information. And the constraints comes into if you’re not seeing it as a fast enough speed you may not get everything. So considering the protocols, ethernet IP just, I, I would definitely say go ethernet base. It’s just, you can’t get around it. The market share has grown bigger. And eventually everything will be resided on ethernet. 

Chris: 13:56

Absolutely. Particularly if the trends continue and why they do here in America. So that is definitely the baby horse. So looking at operability where other products present or future no restrictions.

So. K. Again, this has been a great episode. Hopefully we brought a lot of value to our listeners about this topic specifically. Please continue to follow and give us ideas for future topics that you’d like to learn more about to centering your industrial network. And we’ll be sure to schedule our man, K to come in and drop some more of his wonderful knowledge with us to thank you, sir.