Ivan in IT and His Paranoia about Cloud Communications


I have a friend named Ivan. Ivan’s from the old country. A really great guy. He likes the Green Bay Packers (it’s kind of required in Wisconsin). He’s fun, married with two little daughters. That’s a problem, but he won’t know it until they become twelve or thirteen. I haven’t given him the bad news yet.

Anyway, Ivan’s real problem is that he’s an IT guy. IT guys are an odd breed. They’re different than us factory automation guys. We’re about making things go faster and getting better quality. It doesn’t matter if we’re making cars, doors, medicine or those little straw umbrellas they put in the girls’ drinks (visiting the little straw umbrella factory is on my bucket list). Factory automation isn’t a club; we don’t have a secret handshake or anything (at least one that they’ve let me in on), but we do have our way of doing things and our own technologies.

Ivan in IT and the rest of his kind have a much broader mission – to protect the electronic infrastructure of the corporation and the assets in that infrastructure. They have all sorts of rituals and processes for doing that. A lot of them I can understand and appreciate. Others I think are, well, nuts. Some of that is because the opponent (hackers) they’re working against is pretty stealthy. They can be attacked and not know it. They can lose millions of customer accounts and not know until long after the theft happened. They really never know if everything is fine or they’re just oblivious to the attack. Paranoia is an asset for IT guys.

So as we go about integrating with the company’s business systems (forward-integration with customers and backwards-integration with vendors) we have to be very conscious of how our work is going to be perceived by Ivan and the other IT guys. If we’re creating any vulnerabilities that are going to make the electronic infrastructure less secure, their paranoia is going to kick in and they’ll stop us pretty quickly.

A pretty typical example of that came up just the other day. A few quality control variables in a Logix processor are pretty important to understanding the operation of a process in the food and beverage industry. There’s a woman who is doing some analysis and wants to collect those variables from three Logix processors at three different remote sites in “the cloud” – the cloud in this case meaning a sequel database.

For those of us who aren’t IT trained, we’d think about this in a pretty standard way. An application in the cloud knows when to collect these things; it sends a message to the processors requesting that data. In this case, Logix processors, being not all that friendly to IT systems, would have one of our products (a RTA box) as a front end. The RTA box would gather the data and make it available in an OPC UA address space. Because the box is an OPC UA server, …

EtherNet/IP Big Data Part 2

EtherNet/IP Big Data

In my last article, I discussed how to use EtherNet/IP Explicit Messages to transfer large blocks of data between an Originator (typically a Scanner like a PLC or PC) and a Target (some end device). In this article I’m going to discuss the various ways you can use I/O Messaging (also called Implicit Messaging) to move large blocks of data. Unlike Explicit Messaging, which moves a specific attribute between Originator and Target, I/O Messaging moves I/O Assemblies between Originator and Target. Understanding all this is critical without a foundation knowledge of CIP (Common Industrial Profile) data.

Here’s a cheat sheet on CIP terminology that you’ll need to understand all this:

CIP Devices: Common Industrial Profile (CIP) devices are devices which organize data in terms of Objects, Instances and Attributes.

Objects: Objects are groupings of like Attributes. For example, the predefined Identity Object is the collection of Attributes like Vendor Number, Revision Number, Product Code, Description and other Identity data.

Instances: Instances are Objects that duplicate the Attributes of an Object Class. A Flow Meter that monitors two water channels might have two instances of Flow Attributes, one for the first channel and one for the second channel.
Attributes Attributes are the data elements of an Object Instance.

Input Assemblies: An Input Assembly is a collection of Input Attributes, or real world inputs, that are collected together to be transmitted to a Scanner as a group

Output Assemblies: An Output Assembly is a collection of Output Attributes or real world outputs that are collected together to be received from the Scanner as a group

It’s critical to understand that an EtherNet/IP Adapter device simply connects the Scanner to the real world. The Scanner sends a set of Output Assemblies to the Adapter and the adapter device sets its real world outputs from the output buffer. The same thing happens cyclically to the inputs. The Adapter device collects inputs and cyclically send those inputs as an Input Assembly to the Scanner.

In normal operation, these Input and Output Assemblies are pretty small. For example, the Output Assembly for a sixteen valve, pneumatic valve is simply sixteen bits long. Likewise, the Input Assembly is typically also sixteen bits; the current state of each of the sixteen valves.
But often, and it’s happening more now than ever, an Adapter device has much more than sixteen bits of data. Sometimes it has 1K or 2K or 10K of data – much more than is allowed in an Ethernet packet, let alone an I/O message. The limits to an I/O message are what fits in a UDP packet (I/O messages travel as UDP packets). That means 1500 bytes, except when a Rockwell ControlLogix or CompactLogix are the Scanner. The I/O message size is reduced to 500 bytes for these devices.
When the Input or Output data you want to transfer exceeds the limits of a Rockwell Scanner or a UDP packet, there are several options:

OPTION 1 – Use Multiple IP Addresses

In a PC environment …

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 http://www.modbus.org/certification.php.

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 – …