EtherNet/IP Big Data

rta-blog-image-templateTransferring large data sets in EtherNet/IP using Explicit Messaging
I keep a big bag next to my desk. It’s filled with questions I’ve gotten over the years from customers. Some of them are really good and make me think. A lot of them are just good questions that always confuse the casual user of a technology like EtherNet/IP, and others, well, some of them are just peculiar.

I remember one guy that sent me an email asking about the battle for the Argonne Forest in World War I. He wanted to know how the battles of the 77th Infantry Division affected the progression of the overall battle in Europe. Wow! I admit to being a history buff, but I’m not a professor of World War I history.

Well, I looked into the bag, and for today’s article I spread out a bunch of questions on my desk that all revolve around EtherNet/IP assemblies, moving huge data sets over EtherNet/IP and making your EtherNet/IP device look like two devices. It’s a bit technical, and if you’re new to EtherNet/IP, you may just want to watch my video introduction to EtherNet/IP or read the 6.5 things you have to know about EtherNet/IP.

The reason that moving lots of data over EtherNet/IP is important to so many people today is because today, more than ever, they have devices that generate lots of data. This hasn’t been a big issue in the past, but it is gathering steam. More and more devices are going to become archivers, archiving all sorts of production, maintenance and operational data. That data needs to get transferred someplace, and since the device support EtherNet/IP, that’s the apparent first choice.

It’s just that it isn’t always easy to do that. There’s two messaging options in EtherNet/IP, Explicit and Implicit, and in today’s article I am going to focus on how to move large data sets with Explicit Messaging.

Explicit Messaging is the mechanism in which an Originator (the one “originating” the message) sends a service code (an action to perform) to a Target. The Originator is usually a PLC but doesn’t have to be. The service code can be one predefined by the EtherNet/IP specification or a vendor service code created by the vendor to support some special service, like transferring a large data set. The Target receives the message, performs the service requested in the message, and returns a response that includes a status code.

It’s important to know that this can be, but usually isn’t, a scheduled service. There is no requirement for an Originator to ever send an Explicit Message. The Originator can send it every 50msecs or every 50 days or once and never again. It’s strictly at the whim of the Originator.

EtherNet/IP Explicit Messaging is pretty simple and straightforward if you are setting the drive’s ramp time to 50msec or getting the value of Input 17 or issuing a command to start a recalibration process. But if you are sending a message requesting …

Modbus Conformance

Modbus_ConformanceIf you’re a device manufacturer and you’ve ever developed an EtherNet/IP Adapter, BACnet/IP Server or a ProfiNet IO Slave device, you are cognizant of conformance testing. These organizations are sticklers for making sure that products are not released to the market without validating that they have the minimal required functionality. This is very typical of most industrial protocols. Most trade organizations specify a protocol test that has to be successfully executed to get a certification statement or logo that a device vendor can use to indicate that the device conforms to the specification of the technology.

This is, of course, extremely important to a lot of very big, very important customers like automotive manufacturers. They don’t want to spend their time sorting out the whys and wherefores about why product X doesn’t work well with product Y. In fact, it’s absolutely the last thing in the world that they want to be doing. They want to buy a certified product specifically so they won’t be fighting that battle. They know that there is high probability that your certified product is going to perform correctly in their application.

Modbus has been a little late to this party. For a lot of years, there was no conformance test for Modbus products. A developer would create something, test it in some fashion, and ship it. It was left to the user to figure out what worked and what didn’t work.

In the time since, the Modbus Organization has remedied this problem. They not only established a test procedure, they contracted with the University of Michigan to implement it. You now have two options for certification of your Modbus Slave device or Modbus TCP Server device.
One, you can self-certify. That means that you download the test and execute it yourself. You pledge that your product meets the minimum functionality of a Modbus device as specified by the test.

Two, you can purchase testing from the Modbus Organization. The test lab at the University of Michigan will perform the test for you and validate your device. That, of course, is going to cost you some cash and some time. But you get a second set of eyes and third party testing.
You can find out all about testing, including what tests to perform and what options are available, by visiting the Modbus Organization certification web page at

If you visit that site, you will notice that only your Slave or Server device can be tested. There is no test for Master or Client devices. The Controller side of many programs cannot be certified through the trade organization’s test facility.

You will also note on that site that only Modbus TCP Server devices can be tested. The Modbus Conformance test is designed for Modbus TCP Ethernet devices, not Modbus Serial devices. To test a Modbus RTU Serial device, you must use a gateway that can connect your Modbus Serial device to a Modbus TCP Client. Any Modbus Router can be used for the test, …

OPC UA Use Cases

OPCUAPatience is not a virtue that many of us have. Almost nowhere is that more apparent than when we push the little button and start what always seems to be an endless wait for the elevator doors to slide open. That wait is important to building operators, but it is of vital concern for facilities like hotels where slow running elevator systems can ruin an otherwise excellent guest experience.

Ignore elevator maintenance and slow elevators is what you get. But worse than that, the building owner may unknowingly also be experiencing high energy usage, excessive heating in the drive system enclosure, and excessive noise generation, which all lead to a shortening of system life, and in excessive cases, safety issues. Knowing that status of elevator operation is critical to providing excellent service to the building owner.

Remote monitoring is critical to providing excellent elevator service and avoiding long term outages that affect building owners and tenants. There are many items to monitor, but few of them are regularly monitored in the one million thirty thousand elevators and escalators in North America. There are hundreds of items to monitor, but some of the crucial ones include:

• Travel time
• Energy usage
• Control System Temperature
• System Power Factor
• Door Cycle Times
• Total Operating Hours

OPC UA is an excellent solution for providing this type of monitoring for all the same reasons that make UA such an effective tool on the factory floor.
Remote Monitoring – OPC UA is especially effective in situations where a remote piece of equipment must report to a supervisory system when an operational discrepancy is reported. Since UA uses standard Ethernet communications, any physical layer – including wired, wireless, cellular and satellite – can be used to move OPC UA messages.

Event Handling – OPC UA contains a sophisticated Event management system. OPC UA Client devices can select the variables to monitor, can select under what conditions a variable’s value is published, and set the rate at which the remote devices’ variables are monitored.

Security – For business reasons, elevator vendors prefer to keep data like operating cycles out of competitor’s hands. This is more important if the elevator builder is remotely sending commands to the system to change operating parameters as the system ages, or in response to a high temperature environment or utility power charge at a particular time of the day. UA provides excellent security in this kind of situation.

Information Modeling – Using a standard, open information model makes it much easier for the elevator manufacturer, their customers, and third-party after-market vendors to build applications that use elevator data. Using standard objects with informative Meta data means that dashboards, handheld applications and other monitoring systems can be quickly and easily constructed. Manufacturers and customers tracking the frequency of problems can lead to reduced call frequencies, lower maintenance costs and the avoidance of injuries – all increasing bottom line profits for both the operator and the manufacturer.

Standard Interfaces – …

Industrial Ethernet Security

IndustrialEthernetsecurityI admit it. All this security talk makes my head spin. I didn’t go to Harvard. I didn’t go to MIT. I learned Computer Science at a school whose best attribute is that it’s kinda close to Yale. I’m not a wiz kid in security by any stretch of the imagination.

I really try to look at things a practically. Because I’m not that smart, I really look for simplicity. And that’s really what distresses me. Whenever the subject is security there isn’t a lot of simplicity to be found.

All I can tell from the reading I’ve done is that security is good and no security is bad. Everything after that confuses the issue for me.

There is a lot of technical-sounding terminology. There’s concepts like “defense in depth.” There’s the threats like “denial of service.” And then there are all the security protocols. If you’re like me, you have a general understanding of things like HTTPS, 802.1x, PKI, encryption technologies and all the rest. Not many of us are anything close to experts on these topics, even though part of my job to know about stuff like this.

So today I read that EtherNet/IP is working on a “secure” EtherNet/IP. I’m sure the same is in progress for Profinet IO.

I have two questions. One is “Really?” The other is “Why?”

I’ll start by asking the obvious question: Why do these networks need to be secure? Yes, I know that seems preposterous. Yes, I know it seems silly. But bear with me for a moment.

Those networks exist to move inputs from a field device to a controller and outputs from a controller to a field device. They really don’t have any other function. They are well-designed for that and really good at it.

I have this argument all the time with the PI and ODVA people. These are not information networks. They are I/O networks. They are not well adapted to moving information from the factory floor to the Enterprise. It’s a perversion to try to make them do that. They’re as cumbersome at moving information as I am doing a waltz. Yes, I can take my Buick and drive it in the Indianapolis 500. It will make it around the course, but it’s not really built for that.

Now, if the system needs to connect the controller to the Enterprise, that’s a connection that I can understand. The best way to do that is to use a separate NIC card and talk to the Enterprise on that second Ethernet channel.

The alternative, an alternative I don’t like, is to use the same Ethernet network as the I/O network. I wouldn’t do it this way, but you could. You could move information from the controller to the Enterprise over the same physical network as the I/O network. To do that, you should use an information protocol like OPC UA, MQTT, AMQP, XML or something of that ilk. If you did that, you would do it over a …

EtherNet/IP DLL

EIPDLLOne of the things I find odd about life is how some of the simplest things cause some of the greatest frustrations. Shoelaces are the first thing that comes to mind. Why are shoe laces so long? Do they just make one size for the large boots? It seems that every pair of shoes I buy has shoelaces that are twice what I need.

My list is long and I won’t bore you with it, but there is a frustration that all vendors of EtherNet/IP Adapters face and that’s what I’d like to address today. That frustration is testing. There isn’t a decent way to put together a decent test program that can validate your Adapter’s functionality in your QA or production system.

A lot of people use a CompactLogix PLC or other controller, but that’s hardly a nice solution. It’s hard to log tests to a database from a PLC, plus that’s a pretty expensive solution. It’s also a solution that needs a highly trained and valuable PLC programmer to set up and maintain.
A better solution is now available. We are just releasing a DLL for Windows and a set of Python test scripts that you can use to create a simple EtherNet/IP Windows test system. We are using that in our production test and giving it away to people when they purchase an EtherNet/IP Adapter Royalty Free Source code stack.

Some people have used royalty free EtherNet/IP controller code to create that solution, but now you have all the functionality of the RTA Scanner source code without the expense of licensing it.
Here’s what you can do with it:

• Open an EtherNet/IP connection with an EtherNet/IP Adapter device

• Read and Write any Attribute in any EtherNet/IP Object using Explicit messages. This is perfect for setting your configuration when you commission a new EtherNet/IP device.

• Test your I/O messaging by doing cyclic communications. You can send outputs to your Adapter device and get back your inputs. If you’re really ambitious, you can set up an I/O module and do closed loop communications

• Interface your data and the results of your testing with a database through standard Python extensions.

I’m really excited about making this functionality available and look forward to getting your comments, questions and suggestions.