arrow-data-point-fb
arrow-data-point-fb
arrow-data-point-fb
arrow-data-point-fb
arrow-data-point-fb

Get to the data point

June 28, 2018
Collecting the data is easy; getting paid for it is not

The controls industry is buzzing these days over the Industrial Internet of Things (IIoT). I have always prided myself on staying up with technology and being relatively fearless when it comes to trying out new things. Having said that, I am not yet firmly on the bandwagon when it comes to IIoT, but I might be warming up to the prospect.

For me, the issue hasn’t really changed in all the years I have been in the industry. What is the point of all this additional information if it is just sitting out there in a sensor or valve on a machine? The beauty of this wealth of additional information is realized when it is gathered up in some fashion and presented in a meaningful format. The trick isn’t how we gather it up and make it pretty, but who is going to pay for that to happen.

An end user purchases a machine or process to produce something that its current machine or process doesn’t. It wants more widgets per hour or the same widgets in a different package. As long as the machine makes parts, who cares how it happens? Well, if they don’t care, the common wisdom is they should.

If you strip away all of the fancy names, IIoT is really just data leveraging another highway upon which information can travel. Others have come before it. Industrial networks have been around from the start of the PLC age. Data Highway, DeviceNet, ControlNet, Ethernet, Profibus, Modbus—even the names suggest the movement of information along some path. The newer versions count on an innovative way to get information from the end device back to a collector of data. Now, before I get a whole army of vendors mad at me, there certainly is a big difference between what the early networks were doing and the sort of information available in products such as IO-Link and others. But, at the end of the day, we are still left with a pool of information available to be digested and formulated into something of use to someone.

My years as an OEM taught me that, while my clients would love to have additional information available to them to assist with keeping their machine making parts efficiently, not one of them was willing to invest the capital for me to spend an appropriate amount of time developing a solution that would give them what they desired.

I don’t think any one of them was blind to the possibilities. These were some very smart individuals, companies and corporations. The difficult point to get beyond is the hard-coded fact that machines have been around for hundreds of years that did just fine without a single bit or byte of supporting information cluttering up the design. How can one justify spending a significant amount of capital to tell them information that history says didn’t really matter in the grand scheme of things? When something breaks, we fix it.

For the past seven years, I have been an end user of the same machinery I use to build. The perspective from this point of view is somewhat out of skew with my former vista. I can spend some time and resources on optimizing a line to maximize production, only to face the sad truth that, as soon as I walk away from that line, the performance is going to depend on something other than my firsthand attention to keep it running like a fine-tuned engine.

With a little more time at my disposal, I have taken the liberty to add features to much of the OEM equipment in our facilities. This sort of activity would have gotten me fired in my OEM days but are a welcome addition to our maintenance and production teams as it gives them tools at their disposal to help keep that peak efficiency long after we walk away from the line.

In retrospect, I have done nothing more than utilize the type of information that was available in those earlier network protocols. I can indicate if a device is on or off. I can monitor the network connection and provide messages when a connection becomes intermittent or severed. I can present the control system graphically to help the user to better understand the magic that happens inside the box. None of this is new, but I see real value in what it does for our teams.

Here is where the real potential of the newer technology comes into play. Let’s take a simple sensor, for example. My value-added diagnostic screens provide a visual prompt to tell the viewer if a sensor is off or on. Not much more is gleaned from this.

With the Industrial Internet of Things, we are suddenly exposed to not only the digital state of the sensor, but everything from make, model, voltage and current levels, temperature and things not even imagined when the prospect of networking devices first came up.

Sure, most of this information was available in the processor, but now we are talking about the device on the furthest reaches of the wires that start out in our panel. These parameters can even be stored and used to replace a device without any additional effort applied because the new device will assume the settings of the replaced one.

Okay, so what I have told you thus far probably isn’t all that new to you. The IT part of my brain is absolutely locked down by the mere concept of billions and billions of devices out there, all wanting to talk to some higher life form such as PLC, computer or the cloud.

The prospect reminds me of Carl Sagan talking about all the lights up in the heavens and how each one of those is a star, just like our own sun, with planets orbiting about that point of light, and how all those points of light are blotting out the light from billions more lights that are stars with planets orbiting them, as well.

How in the heck can we possibly connect to all of these points of light, these devices with a story to share, when we don’t even have networks in place to bring the plant-floor information up to the management level.

Well, some vendors must have heard of my plight or the roar from so many people like me out there who feel overwhelmed, as I do, by the weight of so much information there for the taking.

Trending now are vendors who have realized that not every piece of information is going to get gathered up in some master trap of information and spit out to the crowds of people who must be clamoring for it. Instead of creating some grand solution that fits all, vendors are doing what vendors always end up doing—they look after themselves. This might sound a bit harsh, but, let’s face it, if you are Brand X and you only make process valves, do you care if the photoeye from Brand Y can work on your data-collection system? This “look after ourselves” mentality isn’t restricted to the end devices, and that is all to our benefit.

Within the past few years we have been upgrading some well-used equipment with some newer models. While we made these purchases with a clear intent to put a new machine in where an older version once stood, we have come to the realization that the newer machines have the ability to talk on a network. Wouldn’t it be great if we could network these all together and do something with them?

Well, the vendors had the same thing in mind and somewhere back around the first visit with the vendor representative, a notion of some network software was discussed. As it turns out, most vendors had this vision early on when they were developing new products, and software was developed to make the monitoring and management of like product lines easier for the end user.

I recently hosted a series of visits from my favorite group of automation vendors and learned that my hope of a software solution that taps into the IIoT data stream, without requiring me to write all the code, may already be here.

Most of these solutions involve software that runs independently of the actual control platform. The great thing about this discovery is I can still program my machine application and not be concerned about the data-collecting part of it. I am still a little concerned about the impact on my IT department, but I am willing to give this some consideration as I continue to look for ways to improve the OEE of my production lines.

Live demonstrations of these solutions during the summer months will provide some clarity.

ALSO READ: The keys to designing and building machines for the IIoT

About the author: Rick Rice
About the Author

Rick Rice | Contributing Editor

Rick Rice is a controls engineer at Crest Foods, a dry-foods manufacturing and packaging company in Ashton, Illinois. With more than 30 years’ experience in the field of automation, Rice has designed and programmed everything from automotive assembly, robots, palletizing and depalletizing equipment, conveyors and forming machines for the plastics industry but most of his career has focused on OEM in the packaging machinery industry with a focus on R&D for custom applications.