It seems everyone is talking these days about enterprise systems and how to get the Industrial Internet of Things (IIoT) and big data into their daily lives. With the development of Internet Protocol version 6 (IPv6), the pool of IP addresses available to assign to devices expanded exponentially. This means that pretty much every electronic device in a design can be on a network. While this sounds like a great thing at first look, it can be frightening if we imagine ourselves as traffic cops, trying to manage all data that is crisscrossing the universe of automation.
To gain some perspective on this, let’s just assume that the job of connecting all the devices is done, and there is this great repository of information just waiting to be tapped. For the designer of a control system, the job is done. The devices all talk to each other, and the machine or process is doing what it was intended to do. Lurking in the background of the obvious task of your control system, however, is all this extended data. Sensors can tell you not only if they are turning off and on, but how well they are doing it. Valves can report back if they are taking longer than usual to shift from one position to another. While this sort of information is great, for the designer of a control system this offers up a whole different level of complexity to the design, if one is to capitalize on this information. Someone, after all, needs to add programming to do something with all this new information.
Our plant recently went through an interesting journey that took us from manual data collection to a live-stream system in which machines were automatically reporting a count indicating each package that was produced or case that was closed. Attempts to do this sort of thing in the past have always met with some pushback because just collecting the data isn’t enough. The managers and supervisors don’t know what do with this wealth of information. The solution we selected had organized that data into easy-to-understand packets of information and then prompts for some input from the user to explain the blips it sees in production. Our system works because the data is presented in a manner that makes it easy to understand for the end user. The data collection experiment got me to thinking about machine design and, specifically, how we can leverage the wealth of information that comes with IIoT to help make machines easier to use and maintain.
The key to the successful propagation of information is to make sure that the right information is getting to the right user. Our designs tend to focus on the human-machine interface as our go-to source of information. Display screens are high-resolution and provide an awesome means of conveying meaningful data to the user. The challenge, however, is to make sure we don’t provide too much information because that is just as bad as not enough. Let’s say, for example, that we take up the challenge of IIoT and put all that wonderful data from the sensors, valves, actuators and drives on our operator screen. We could end up with tens or hundreds of screens’ worth of information. The value of that information, however, might get lost in the sheer size of it. Let’s face it: It might be cool to know that my sensor has an internal temperature of 107 °F, but it might not necessarily be groundbreaking information to throw at the operator who is just trying to make boxes.
Vendors seem to be paying attention to this thirst for knowledge, but also, knowing that we don’t necessarily want all of the knowledge, have a way to organize the block of data into readable segments. For a number of years, network-capable devices have come with the option of add-on profiles. These profiles can best be described as a universal translator that taps into the pool of data coming from a device and organizes it into bits and bytes that make sense to the reader of the information. The programmer of the control system can then pick out the parts they need to make the device function and leave the rest of the information for another day. That day, for most programmers, is further down the development of a project where we have time to sort through the “also included” information and determine what might be of interest to, for example, the maintenance technician or a quality engineer.
A notable change is the emergence of on-machine troubleshooting. This differs from the center of knowledge presented on an operator screen by putting the diagnostic indicators on the machine, close to the device itself. The HMI might still be used to announce that a fault condition exists, but the maintenance tech would then be directed to a node mounted at a specific location on the machine where further diagnostic indicators would point to the cause of the stop in process.
On-machine diagnostics aren’t new. I/O distribution blocks have been around for a while now. These offer some diagnostics in the form of a light to indicate when a sensor is on or valve output is energized. What is new is distributed I/O nodes that have diagnostics built-in. The node device has a multi-line display that provides not just off/on indication for the various modules attached to it, but true diagnostics for those modules. From the main node, errors will indicate if a module is faulted or a specific I/O point on a module is shorted or open. These nodes can also store configuration for individual modules that permits swap-out replacement when one fails.
At first glance, one might say that having the multi-line display on the field I/O isn’t really all that great, as long as the main operator station has been programmed to reflect the status of all the field devices. The key here is that, in a traditional system, the programmer must spend hours programming the operator screen to display all these diagnostic points. By utilizing these newer field I/O systems with the node-level advanced diagnostics, the need to program has been taken out of the equation. Even if the programming has already been developed, it hasn’t gone to waste because the programmer can still use that to display data on the main operator screen. The bonus is having some of those diagnostics right there on the machine where the maintenance person can best use them.
Take care when selecting your next field I/O system as not every vendor has the newer diagnostics at the node level. One vendor of pneumatic components for machine control has really gone the extra mile to bring value to the IIoT experience. I expect that the other vendors will be burning the midnight oil to bring their products up to par.
The surge to use the data available with IIoT devices will continue to grow, and the end users of machines are going to want to see that in new machine designs. As the technology gets ever more advanced, the workforce is going to be ever challenged to keep up with the trends. Hardware manufacturers who recognize this fact will be ahead of the game, and it is worthwhile to take a look beyond the usual cast of characters when picking out components for new designs.
ALSO READ: Case study: Mueller moves from preventive to predictive maintenance
Any new product offering needs to be intuitive. With the list of new devices growing exponentially, it would be hard to keep all the documentation at hand for technicians to refer to. A device that leads a user to the information being sought is the desired outcome. Many devices today have built-in Web pages. These are great troubleshooting tools, as they don’t need specific software to access them and can display information, as well as provide an interface to configure and program the device.
It is worthwhile to take some time to learn what new products are out in the marketplace. You may be pleasantly surprised to see what is available and the direct impact it can have on your design and commissioning time. Better yet, don’t be afraid to look at some of the smaller companies or lesser-known brands as this is where some of the most innovative ideas come from.
