EtherNet/IP Variations

EIPvarI have a lot of customers that want EtherNet/IP. But just like buying anything else, it’s just not that easy.
Just last week I did something that almost no one does anymore. I bought a camera. That’s right: I bought a device designed specifically to take pictures. Still pictures and movie pictures.

And like any other complex buy, it wasn’t as simple as it seemed at first. There are lots of different types of cameras for lots of different purposes. There are cameras for photographing wildlife, cameras for underwater shots, and cameras that you can strap to your head for who knows what reason (the last thing I want is a camera strapped to my head).

EtherNet/IP is something complex, possibly even more complex than a camera. There are a few different kinds of EtherNet/IP and you have to decide what is going to work best in your application.

The EtherNet/IP Scanner is our software that opens connections, send outputs to devices, and gets inputs from devices. It is the “PLC side” of an EtherNet/IP network. The Scanner is usually the controller in the system and there is usually just one controller, but there could be more.

The most difficult part of implementing a Scanner is that the Scanner must be configured. It must know what devices to open, what each IP address is, how many bytes of data are being transferred from each device, and how much to send to each device. How you get that data to it is an application decision. You can read the EDS file for the devices, you can use some custom application program, or, in a lot of cases, you can make the device list fixed. A fixed device list is one where the devices are always going to be there and never change. The tools of a Robot, for example, would be an application where the device list would be fixed. Those tools are going to always be there, day in and day out, and never change.

You want to buy an EtherNet/IP Scanner when you need to control a set of devices on an EtherNet/IP network. Typically, your device is going to be the controller, getting inputs, processing logic against those inputs, and setting outputs. If that’s what you want, then you need an EtherNet/IP Scanner.

An EtherNet/IP Scanner opens EtherNet/IP devices. Those devices, on that end of the network, are called Adapters. Adapters are end devices like valves, I/O blocks, drives, scales, meters and everything else you might find in an automation system. An Adapter has one job: connect the virtual I/O that gets transferred back and forth from the Scanner with the real world I/O. An Adapter takes the Outputs from the Scanner and manipulates real world, physical outputs. An Adapter takes real world inputs, digitizes them and sends them back to the Scanner. If no Scanner talks to it, an Adapter just sits there idling away its time (like some folks I know at big companies).

You want …

Windows Embedded vs. Linux

linuxvswindowsI’m an agnostic. I just don’t care.

No, not regarding religious beliefs. I’m talking about what OS and TCP/IP stacks our customers use.

A lot of what we do is getting customers enabled to do Profinet IO, EtherNet/IP, Modbus TCP, DeviceNet and all the rest. The best way to do that is to integrate our software directly into their OS. That means that we have to be able to work with all the top stacks that people might use.

I never encourage these guys one way or the other. The choice of MQX, uCOS, QNX, VxWorks or Nucleus always seems to be a really important personal decision. In the old days, before I knew better, I might question a decision for one or the other. No more. I learned that the choice of an embedded OS is protected by nothing less than the US Constitution and I’d better keep my opinions to myself. It’s kind of like someone’s choice in women. Some only will date short blondes, while others go nuts over a tall redhead. Those guys will claim it’s about features and functions, but I think it’s more personal preference.

Well, the debate’s on again and this time it’s the embedded Linux vs. embedded Windows front. Both camps are digging trenches, stockpiling weapons and training armies. The war simmered for a number of years, never more than a low-level regional conflict while Microsoft went through its troubles. The embedded version of Windows had security issues, resource issues (it was monstrously large) and a bad reputation on the factory floor.

Now, with the emergence of IT on the factory floor, high-speed processors, massive amounts of low-cost flash and RAM and the need to communicate with the Enterprise, vendors are taking another look. A Windows system has a lot to recommend it. Even though it’s always going to pose security risks, there are good reasons for selecting it for your embedded platform. You can make a pretty strong case that development is easier and that you have much more flexibility on the factory floor.

But you can make a good case for Linux too. It’s less of a resource hog, it’s reliable, it’s arguably more secure than Windows, and it’s a lot less expensive. On the downside, there are lots of different variants to select from, there are possibly fewer platforms that will support Linux, and support can be more difficult to obtain.

Recently I’ve seen a pretty good increase in the number of customers that are building EtherNet/IP Windows devices, Profinet IO Windows devices, Windows OPC UA servers and other Ethernet devices on Windows. Several years ago, Microsoft made a pretty big commitment to the factory floor and has steadily improved its offerings. The original CE was pretty much a disaster, but the later versions and XP Embedded are much improved.

So, what am I planning to do? RTA designs, develops and sells automation devices. System Integrators use our Device Converters to move data around the factory floor and around …


A few weeks ago I had the opportunity to attend the GE Innovation Summit in Orlando. It was a great opportunity, and despite what some have said, I didn’t just go to Florida to scuba dive. I actually spent more time at the conference than in the water.

GE has an interesting business strategy. If you haven’t noticed, they’ve sold off or are selling all their consumer divisions. GE was big with consumers. They built the electric toaster business. They invented the self-cleaning oven. They sold all sorts of appliances directly to consumers for lots of years. It was a huge business for them.

And now it’s gone. They’ve sold their entire appliance business to Electrolux in Sweden. They only thing left is some light bulb business, and I’m betting that doesn’t last through 2015.

Where are they going? The Internet of Things (IoT), or, as they call it, the Industrial Internet.
They believe that the world is changing and that they have a massive opportunity to take a leadership role in a new paradigm. Jeff Immelt, the GE CEO, expressed that new paradigm like this:


What that equation means is that if you equip machines with smart sensors, you securely collect that data someplace where it can be processed using advanced analytic software so you can achieve exceptional results. Results like a 1% decrease in fossil fuel usage. 1% may not seem like a lot, but for things like aircraft engines and locomotives, it’s a massive amount of money for their customers (and GE).

They detailed at the conference how a single engine on a flight from Orlando to Chicago now generates 2 Terabytes of data. Analysis of all that data has vastly improved the in-service time at Delta airlines. They have decreased the number planes out of service from an average of thirty-five to around fifteen or so. That’s almost a 60% decrease in out-of-service airplanes, meaning they can probably afford to drop the number of planes in their fleet by one or two. I haven’t checked the prices on a 737 or an MD88, but I would bet they’re not cheap to own.

GE is going after results like this in several markets like transportation (aviation, rail), medical and oil and gas. They have the expertise to equip the machinery with sensors, the technology to move the data securely, and the advanced analytic engines to identify actions to generate those exceptional outcomes. It really does look like a good strategy to me.

So what does that mean for all of us who develop, market and sell less glamorous industrial equipment like scales, valves and drives?
The IoT for consumers and the larger market is a question mark. It’s moving fast and what’s going to happen tomorrow won’t really be clear until tomorrow comes. But in our world, that’s not entirely true. Our industry moves slower and more methodically. We don’t drop everything we’re doing today when a …

OPC UA Server Object

UAobjectsThere’s a lot of interest around the globe for OPC UA. One of the drivers is that UA is an extension of the original OPC which I have been calling OPC Classic. I named it after Classic Coke. Though UA isn’t the same throwback after a terrible experiment that Classic Coke was.

The more I learn about UA the more I marvel at its complexity and simplicity. It is both very powerful and at the highest level, very easy to understand. The power comes in the Type System, Object Model, multiple transport layers and ability to wrap other protocols.

For the past several days I have been studying the Server Object. Like everything else in UA there are layers and layers of complexity to it.

The Server Object is, like almost all UA Objects, an instance of a Type Definition. In its case, its Type Definition is the ServerType which is itself, a subtype of the BaseObjectType. All the type definitions for UA are neatly grouped under the root node. From the Root Node in every Server you can follow the reference to the Types Object. From there you can follow the reference to the ObjectTypes Object. And from there to the BaseObjectType which is the parent of the ServerType. A Client can follow references from the Root Node through the Types Object to find the definition of any Object in a UA Server.

The Server object, which is required as part of the Core Server Facet, neatly organizes a lot of information about the Server and makes it easily available to Clients who want to know the capabilities of the Server, its current operational status and any diagnostic information that the Server can provide. Since all Profiles are based on the Core Server Facet, a Client can count on being able to find this information by reading the Attributes and properties of the Server Object. A Client can find the Server Object from the Root Node of the Server by following the reference to the Objects Object and then to the Server Object.

In the Server Object you will find a number of different kinds of references:
ORGANIZES – An Organizes reference serves no purpose other than to establish a relationship from one the source Object to the nodes it organizes. The Root Node, for example, uses Organizes references to relate the base View, Objects and Types Objects to it. The View Node Organizes all references to the currently existing Views in a system. The Server is the destination node for a Organizes reference from the Objects Object.

COMPONENT – A component reference implies a “stronger” relationship between the Source Object and the Destination Object. A Component reference through a hasComponent reference implies that the destination Object is part of the Source Object. The Server Object, for example, has hasComponent references to the ServerCapabilities Object, VendorServerInfo Object and Namespaces Object. Whenever the destination is complex, meaning it is more than just a simple variable, UA requires that a hasComponet …

Data Modeling in Industrial Automation

datamodelingIn lots of ways the Industrial Automation business has been pretty unsophisticated for a very long time. There’s lots of reasons for this. IA uses PLCs and these have been pretty unsophisticated since, well, their creation.

PLCs have always had the identical structure. Get Inputs in, process the logic, set new Outputs…repeat forever. The data types were pretty limited. Binary, Integer and Floating Point and arrays of those items for the most part. Then later on, structures were included and then user defined structures.

Logic wasn’t any better. You had subroutines but software engineering principles that were well-developed and used in higher level languages generally weren’t applied to Ladder Logic development tools. IEC 6-1131 has done a good job improving some of this but ladder is still ladder. The polymorphism and inheritance that you find in a C++ isn’t even whispered about when it comes to ladder.

Another factor that has kept Industrial Automation in the dark ages is that most data is just binary. It’s a sensor input like a photo eye or an actuator output like a gate. The data being processed has relationships to other data but those relationships were pretty much ignored. The fact that the photo eye was part of the folder device on a packaging machine was ignored. It provided little value in the “old” days.

EtherNet/IP and Profinet IO and all the other factory floor protocols haven’t done anything to change the way that we look at factory floor data. It’s still just plain old inputs and outputs. An Ethernet application layer protocol like EtherNet/IP or an application layer protocol like Profinet IO may have some semblance of object based structure but none of that is really present in the communications. It’s still a bunch of inputs in and outputs out.

The techniques that have evolved in the higher level languages used in general computation just haven’t been used on the factory floor. The evolution there was different. From day one, people who built business systems had to think about relationships. They had to consider how one piece of data was related to another piece of data. They had to consider this as they collected it, as they stored it and as they reported it. It was central to all their thinking.

To do this they created all sorts of techniques and technologies for data modeling. In the ‘80s, one of the seminal ideas for data modeling was engineered by G.M. Nijssen. Deemed NIAM, short for “Nijssen’s Information Analysis Methodology,”. Later is was called ORM, or “object role modeling.” This approach shows representations of relationships instead of showing types of entities as a rational table. That’s a lot of gobblygook but it means that ORM shows relationships and constraints.

Today, because of the superb capabilities of OPC UA, we now have the first real ability to model information on the factory floor. In UA, we have a true extensible Type Definition system and a real ability to describe data, device, machines, lines, anything …