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 …

Future of the Factory Floor


I’m hearing a lot of talk about IT protocols and the factory floor. This stems from the fact that the Factory Floor is slowly becoming IT. It’s much like the continents drifting around the globe over time. Continents form, move together, move apart over thousands of years. Continents of IT and the Factory Floor are now moving together.

It’s going to happen a lot faster than some vendors in factory automation would like. It’s also apparent to me that IT is going to absorb the factory floor and make the Engineers who work on the factory floor part of IT. As that happens, I think vendors will respond by making their products have more IT “friendly” features.

If you look at IT kinds of products they use a lot of XML, SOAP, SNMP and Web Services. Things pretty easily integrate. You can find interfaces available on the network, figure out what they do and connect and use those interfaces pretty easily. There are things like WSDL documents that publicly describe what is available. We all know that it’s a lot harder on the factory floor. We have things like EtherNet/IP, DeviceNet, Profibus DP and PLCs.

What’s this evolution going to look like? Well, certainly it’s clear that PLCs will look a lot more like Servers with built-in routers over the next few years. They’ll support Oracle and Sequel databases, HTML5 Web pages and web services. You’ll probably have the ability to write control code in Java or IEC 6-1131. We won’t lose all the factory floor protocols – those things will still do all the hard work of communicating with I/O.

What will be different is that these PLC Servers will be easily integrated with the Enterprise. They’ll look to the Enterprise just like any other Enterprise Server. It’s just that there will be a back end to these devices that does factory floor I/O and Control. With the speed and bandwidth of Servers today and the ability to partition the hardware and software it will be easy to use standard Servers as PLCs in the future. In fact, there is no reason to have the physical footprint of the PLCs we have today. A hardened server will do the trick nicely. I expect that Siemens, Rockwell and other PLC manufacturers will probably become software companies in the future at least in regard to the control currently found in their PLC’s.

The key, of course, is going to be security. That’s where OPC UA comes in. I expect UA to be the prime Transport layer for all the Enterprise / PLC communications in the future. It has the ability to support IT transports like Web Services as well as fast binary. With its adaptable, user configurable and powerful security component it makes the most sense as the prime data mover between the factory floor and Enterprise.

I do expect HMIs to disappear also. Everyone will have their own person HMI on them with their own web pages or dashboard that …

Betamax and HMI’s

BetaandHMIsI’m old enough to remember the war between VHS and Betamax. If you don’t remember, these were the first two tape formats for home video recording. Betamax was the Sony standard, while VHS was the standard from JVC. Eventually JVC won the war, even though Betamax was clearly the superior technology. JVC did a really smart thing. They licensed their technology to any and every manufacturer they could find. Those manufacturers all started putting out nearly identical machines that competed with each other. Price became the distinguishing factor, and the manufacturers outdid each other to see who could sell for the lowest price.

Meanwhile, Sony had its very high quality, superior technology Betamax units. The people who bought them bragged about having better quality machines, implying that they were somehow smarter and more prescient than the rest of us. But in the end, we had the last laugh: Sony couldn’t compete with all the low cost VHS manufacturers and Beta died a slow death. Eventually, those arrogant Betamax users had to go out and buy a VHS machine. (Of course, DVR technology then killed VHS.)

We have a similar contest going on that is going to have some impact on the Industrial Automation industry. Since smart phones were introduced, there have been people who saw the smartphone as a “personal HMI.” The idea is that instead of walking up to one of those Rockwell PanelView screens on the side of the machine, you simply pull out your smart phone and look at the data you’re interested in.

There have always been issues with this. One way to do this is to use your cellular provider to access your manufacturing network. That’s not an option that every management team has readily accepted given the security issues with opening up their manufacturing networks to cellular access. People are doing this, but it’s awkward and requires some significant thinking and planning to pull off securely, and that’s what matters most.

Other management teams have just said NO – you can’t use your smartphone to access machine data. I think that’s shortsighted. The new engineers we’re now getting in the automation industry think of their smartphone as their sixth sense. It’s integral to them. As they grow and mature, you can bet that they’ll be pushing for more access.

Well, there is another way to access machine data from a smartphone – or should I say two ways. I am talking about the contest between NFC (Near Field Communications) and Bluetooth LE. With these technologies, the smartphone doesn’t use its cellular communications to access machine data; instead it accesses the machine data whenever it’s in range over one of these short-range technologies.

Near Field Communications (NFC) is a descendant of the RFID (radio-frequency identification) technology we’ve long used on the factory floor. RFID allows a reader to send radio waves to a passive electronic tag for identification, authentication and tracking. NFC is a similar technology that communicates either by a modulated electric field (not …

Stop the Presses

Stop-the-PressesSTOP THE PRESSES! Major advancement in automation technology is upon us…Rockwellis introducing a Micrologix processor with USB.

Can you believe it? Isn’t it everything you and I have been waiting for with “baited” (whatever that is) breath?

Why next week we might hear that apples are coming to market with another shade of red; TVs with digital tuning and cars with radial tires.

I mean, really, I don’t mind USB. I just don’t think it has much place on the factory floor. Let me explain.

1.       It has no legs – 16feet is about it. You have to be really close to the equipment to get connected. Why do I want to walk halfway across my plant to plug my laptop into this processor? Why can’t I access it from my desk.

2.       There are a number of different standards. One side is, of course, the controller side and the other is the adapter. You have to make sure that you’re the end that your customer needs you to be. And there’s a bunch of different standards. USB 1.0, 2.0 and 3.0. Some of them incompatible depending on the implementation. It’s really not as simple as the Marketing guy saying “we need to support USB” and you doing it.

3.       And then there are power considerations. These USB devices will want power and you have to support it. How much? Well, it varies…

Lots of ways to screw up with USB. That’s one of the reasons I don’t like it.

But I understand why they are doing it. PCs don’t have serial ports anymore. In the effort to get the price of a PC to less than a candy bar, they’ve eliminated the serial port and most everything else. I’m sure over the last 5 years they have had a host of customers asking for USB. And now, they’ve “quickly” responded.


The trend now is to smart phones, IPADs and a host of other wireless devices. They should have just skipped right past USB and made their controllers work seamlessly with these devices. You can bet that in the bowels of Mayfield Heights they are right now thinking about writing specifications for wireless access to those controllers. [I am sure I’m being a bit unfair here – it takes a long time to get anything done in any huge corporation]

OK, here’s what really frosts my cookies about this. Lots and lots of their customers are going to be confused by this. They’re going to think that RA has just introduced some magic way to access PLCs. That the USB port is the magic bullet for uploading and downloading programs and doing data table read and writes.

Believe me it won’t be. It’s going to be the same as a serial port.

On the serial ports, you need a DF/1 protocol to send PCCC messages. And with those messages you can read or write any data item in the controller.

Now those PCCC messages are going …

Personal Area Networks Part 5 of 7

Personal-Areal-Networks-part-5The previous article in this series discussed the characteristics of the physical part of the radio including the frequencies, data rates, power and bandwidth of the radio. Now we are going to address the organization of the information on the “wire” or air in this case.


This part of 802.15.4, and really any other networking technology, is termed Media Access and the low level software that implements the Media Access is called the MAC or Media Access Controller. A MAC is responsible for both organizing the data received from the application into low level data frames, synchronizing access to the medium, checking for errors and a myriad of other things.


One of the tasks of an 802.15.4 MAC is to present the device to the network as one of the two types of devices defined by the 15.4 specification; a Full function Device (FFD) or a Reduced Function Device (RFD).


Reduced Function Nodes have very limited capabilities. RFDs are single purpose end device nodes like a temperature sensor or a light switch. These devices are often battery powered as they need only communicate intermittently. Reduced function Nodes can only communicate with a single Full function Nodes (FFD). FFD nodes can have device capabilities like RFDs but unlike RFDs they can extend the network by serving as network coordinators.


One way nodes can be organized is a Peer Network as shown in Figure 1. Any FFD can communicate with any other node in range. Each RFD associates with one and only one FFD. The PAN coordinator provides the interface and structure for the entire network.



Figure 1 – 802.15.4 Network Organized as Peer Network with Coordinators


A network containing only FFDs is a true peer network with the capability for any FFD to communicate with any other FFD in range. Figure 2 illustrates an FFD network composed of Full Function Devices.


Figure 2 – 802.15.4 Peer Network with all Full Function Devices


There are two types of network coordinators; coordinators and PAN coordinators. Both are FFDs. Coordinators are FFDs that provide links or associations to other FFDs and RFDs. There can be multiple coordinator devices in a PAN but only one PAN coordinator. The PAN coordinator (Red Node in the diagrams) is the “owner” of the PAN and provides the PAN ID that uniquely identifies the network to the outside world.


The 15.4 standard does not define how the PAN ID is selected. Any FFD can decide to chose a PAN ID and become a PAN Coordinator. Other FFDs and RFDs can then associate with it and “grow” a wireless network. [If that sounds somewhat haphazard you need to remember that we are discussing the very lowest level software layer here. There are other higher layers that provide much more structure.]


A PAN coordinator and most FFDs are typically powered nodes while RFDs are often battery powered. The PAN coordinator will usually have access to a wired network and be …