Marissa, what is the role of the motion controller in the Industrial Internet of Things [IIoT], and what software is involved?
I would take it a step beyond the motion controller and say that the programmable automation controller [PAC] plays the largest role in the IIoT. That’s because, in addition to having the machine logic, PACs include the motion control as part of their routines and often have an embedded human-machine interface [HMI], as well. The beauty of this approach is that the program does not need to share tags between devices because components are on the same device using the same logic. Not only does this slash programming time, it also facilitates IIoT capabilities.
Here is an example: Position error—which used to be very specific to the motion controller—is automatically accessible by the embedded HMI. If that embedded HMI has web-server capabilities, which many of them do, the HMI can immediately send out an alert to the local operator and also to a plant manager via e-mail or SMS [short message service]. This is much better than the traditional approach of having the motion controller send the error to the PLC [programmable logic controller], with the PLC then having to process the data only to send it out to the HMI—which may or may not have a web server. This complex data transfer between devices is eliminated, as the logic is written on one programming software downloaded on one hardware device. It’s so tightly integrated that you can easily get information anywhere.
Ensuring that the developer creating the embedded HMI can create different user groups and credentials is critical. This allows the programmer to create a custom instance of the HMI, depending on the user.
The ease of information flow within the machine is important, but so is the ease of information flow between machines. The IEC 61131-3 programming standard ensures that a machine developed by one manufacturer speaks the same language used by another. This greatly benefits integrators because they can more easily get two different machine systems to talk to each other, a necessary step toward IIoT. Organizations like OMAC [Organization for Machine Automation and Control], which is promoting the PackML standard, are taking IEC 61131-3 to the next level by not only recommending how a system should be programmed but also by developing a standard set of tags that machines should make available to other machines in the network.
What about low-level devices, such as pneumatic valves and position sensors? Isn’t everything supposed to be part of the IoT?
The challenge lies in taking data from low-level devices and turning it into useful information. One approach is to do processing at the level of these devices and then send the results either over a high-performance control bus or directly to the cloud. This is a very expensive approach and doesn’t help gather or centralize the data. Alternatively, we’re seeing huge growth in the popularity of IO-Link, a serial-based protocol that can collect basic data from temperature sensors, solenoids, pneumatic valve manifolds, etc., without expensive overhead.
By leaving the bus simple, this data can be collected and made useful by processing on the PAC or PLC that has to exist in every machine system. By going with a PAC, which also has an embedded HMI for web publishing, users can then take that information and put it on the network, wherever it needs to go. Imagine a pneumatic system with a sensor continuously monitoring sound in decibels. The only data that needs to be sent to a PAC IO-Link is the current dB. The PAC can have custom IEC 61131-3 function blocks developed by the manufacturer that may work on multiple controllers. These function blocks may check if there is an odd pattern in the noise, to say, ‘Ah, there might be a leak.’ The programmer can take that alert and send a message to a maintenance level user of the HMI before the pneumatics fails.
How is the information getting from the machine to the cloud, and what about the software involved?
There is still a big division between the factory floor and IT. Especially for manufacturing companies with multiple facilities in various states, or countries, storing data in an external server or the cloud is ideal. From the software side, component manufacturers need to help make machine builders’ lives as easy as possible when working with IT.
Most machine builders are comfortable programming a PLC or PAC in IEC or similar languages, so companies should look for manufacturers that take an integrated approach to machine control to make the flow of information easy but who also make it easy to share that information to IT servers. Another standard being driven out of Europe is OPC-UA [OPC Unified Architecture]. This client-server protocol has expanded significantly, allowing a universal way to transfer data either machine-to-machine, machine-to-SCADA, or machine-to-server. Because of its flexibility, OPC-UA is rapidly becoming the IoT standard. Look for suppliers that have software tools built-in to easily create an OPC-UA connection in just a few clicks and allow developers to share data simply by sharing a few tags within an IEC 61131-3 program. Once it is accessible on a server, let IT take care of the rest.
Is the information useful in the cloud? How does the critical data get into the operator’s hands, on the plant floor?
It depends on the use case. Anyone thinking about the IIoT, whether they are a machine operator, OEM machine builder, or factory owner, should first develop a use case. A factory floor manager, for example, may want overall equipment effectiveness [OEE] information. This type of information is usually not something that is to be shared with a broader public sphere, so it is best to use an internal server. However, factory floor managers can often be far away from the machine, or not at their desks, but still need to look at OEE. The use case drives the solution: If the machine has an embedded HMI with a web server, a user can connect to it from an iOS or an Android platform, enter his or her credentials, and view the machines’ OEE, no external cloud needed. This in-factory network is often referred to as ‘fog’ computing.
Another example is a purchasing agent who needs to monitor yield data for multiple factory lines in multiple locations. An external server is the only answer. To minimize risk of exposing sensitive company information, the program may publish only the total output, rather than yields. Although this solution demands the use of a cloud server, it illustrates the need to use restraint when sending any data to an external server for two reasons: generally, it’s less secure than keeping it on an internal or ‘fog’ network, and most plans charge companies to send and store data to an external cloud.
Marketers have done a great job of promoting Industry 4.0, but each user needs to step back and ask, ‘How can I use the information?’ The cloud may not be as necessary as you might think.
Isn’t all of this connectivity driving up cost?
It can, but it doesn’t have to. Where it gets expensive is three or four years in the future, when your company is ready for IoT, but you specified devices that make it difficult or impossible to communicate via web server or OPC-UA, or you chose traditional, fragmented design rather than single-machine PACs that make data flow significantly easier. To mitigate this mistake, you can buy incredibly expensive sensors that go from temperature control straight to an external cloud, bypassing all the other devices on the machine. From there, you’ll have to program a whole customized layer or web site using someone else’s software to make the data useful. You don’t want to be this guy.
Instead, deploy IIoT smartly: make it part of the machine design on Day One. If you are building a new application, you are in the perfect position to transition, even if it’s not something that your organization is considering right now. The choices you make today can save hundreds of thousands of dollars later on.
Also, select low-level devices that support buses like IO-Link so you can get data out of them affordably. Use standard protocols that are cost effective and allow you to use data from many sources. Use a single programming software on a single controller to simplify programming. Be sure the machine controller has the ability for a client-server relationship without necessarily requiring another additional gateway. That way, if you do need to start routing information to different locations, you can do it right in your IEC-based program. Don’t forget fog computing. If your PLC has an embedded HMI that is web-server capable, you might be able to satisfy all your IIoT use cases without the use of a cloud at all. And if you do need to, be sure the controller you choose has software that makes it easy to share to an OPC-UA server, so IT can do what IT does best.
Smart choices make converting to IIoT very affordable, but the choices need to be made now.
Connect With Us
