Download this article as a .PDF.
The Internet of Things (IoT) has tremendous potential to change the way plant managers and machine builders do their jobs while increasing efficiency and productivity, according to industry experts. By 2030, some estimate the Industrial Internet of Things (IIoT) could be worth a jaw-dropping $7.1 trillion to the U.S. economy.
Yet, despite the hype, developing this potential has been frustratingly slow. Rolling out the IoT infrastructure is a huge undertaking that only large companies with mature, established business processes seem eager to tackle. Many are wary of strange new terms like “cloud-based computing,” “gateways,” and the myriad Ethernet-based protocols. Little wonder that a recent survey by Forrester Research found 23% of global enterprise respondents use the IoT, compared to only 14% of respondents from small and medium-size company.
Many people developing IoT technology focus on enterprise-level platforms that provide top-down approaches to deploying IoT. Even for companies that have made the “switch,” an IoT application might only capture a fraction of the machine data available, not really giving the whole picture. That makes it difficult to create reliable and repeatable predictive maintenance and performance optimization algorithms. Even worse, some IoT approaches may capture too much data, making it tough to find the meaningful information. Successful IoT applications must be based on knowing what data is important to stakeholders and how they will use it.
Engineers are growing tired of hearing about the promises IoT will deliver. Instead, they want to know how to use it now, even if they don’t have all of the pieces ready to go. Fortunately, there is an easier way to get started: Simply focus on one discrete machine or application. Rather than developing an entire enterprise approach and working down to the machines, start with the machine and work up to the enterprise.
A Practical Approach
A discrete, machine-level approach to IoT is a more realistic starting point for most small-to-medium-sized manufacturers, and even for large ones.
Let’s say a manufacturer has a machine tool, and downtime caused by dull cutting heads has been an expensive problem. The fix is often to swap out a bit on a fixed schedule, regardless of wear. This might mean the manufacturer likely won’t use the bit to the actual end of its operational life.
Although it might be possible to associate tool wear with speeds, feeds, and actual runtime, it would be extremely challenging for a human to reliably track those numbers. One could also argue that it shouldn’t be the manufacturer’s responsibility to know the exact operational life of the bit, given certain speeds, feeds, and runtimes, but rather the bit manufacturer or the machine tool’s OEM.
A programmable automation controller (PAC) can function as both a motion controller and gateway through the use of number protocols. An example of a new, open protocol is OPC- UA/TSN. It gives users time-sensitive access from sensor-to-cloud services.
Now, let’s say the machine tool’s OEM did know how much wear there was on the bit based on certain variables (speeds, feed rate, runtime). An algorithm that tracked a specific bit’s use could operate inside the PLC or tool’s controller, and issue an alarm when it was time to change the bit. Monitoring up-to-the-minute data, not estimated data, means predictions are more accurate.
This is an example of a discrete solution, where the plant engineer starts with a problem at the machine level and works backwards to establish notifications to maintenance personnel and order systems. Contrast this with an enterprise approach, where one would first have to develop the infrastructure around all of the equipment and business processes before realizing any value.
So, how does this value of a discrete IoT application increase exponentially? Well, in the example already laid out, once the engineer establishes an algorithm for one bit, it can probably be applied to bigger and smaller bits by applying slightly different wear characteristics. Once algorithms for a family of bits are worked out for a given machine, a manufacturer can apply them across its entire machine shop. After one shop is established, the manufacturer can implement them in other locations. Then, after the manufacturer collects enough data, managers might be able to create use-based models for more predictable order scheduling of bits.
Of course, knowing when a bit will become too dull or is about to fail can prevent unplanned downtime, saving money and improving productivity, which is exactly the promise of IoT. Discrete IoT applications can deliver real value almost immediately, independent of any enterprise-level system. They let companies get the most from the information they generate today while maintaining the flexibility for future IoT expansion.
Interoperability is key to new IoT applications. Conforming to one specific communication protocol does not need to be a barrier as most modern PACs (such as Parker’s) can be configured to speak to several Ethernet-based network protocols.
Getting Started
The discrete IoT model requires close cooperation between the technology supplier and end user. In the case of a motion-control component, the partners would be the component manufacturer and the plant engineer. The plant engineer understands the problem to be solved, and the manufacturer understands the ratings, behavior, and relevant engineering attributes of its component.
These attributes are often part of the component manufacturer’s intellectual property and wouldn’t be released or given away outright. However, imagine the value created when a component manufacturer collaborates with engineers using the component in an application. Digitizing a component’s attributes (also known as virtualization of a component) goes further than basic CAD drawings of a component. Virtualization defines how a component will perform in a computer simulation or as defined by an algorithm. The virtualization of a component’s attributes will help manufacturers make the leap into Industry 4.0. Tight engineer-to-engineer communication is essential because it helps tie the business or application challenge to an attribute of interest within the component.
Want to get started? Here are the general steps to developing a discrete IoT solution:
1. Pick one application or business challenge that needs improvement. In most cases, the place to start will be obvious to the manufacturing and maintenance managers. Often, it’s something that has caused problems for so long it’s just been accepted as the cost of doing business and ignored. If the application wastes time and money, then it’s a good candidate for a discrete IoT project.
2. Draw in engineering resources that can help to determine the data or information needed. Once the problem is defined and the machine causing it identified, decide what data is needed to solve it. It’s important to talk with experts who understand the machine’s key characteristics. In many cases, the machine’s manufacturer has a lot of data it simply isn’t aware of or not taking advantage of.
For example, in the case of a motor, the essential information may be encoder data coming from the drive or thermal data from thermocouple. The information needed will differ for each application. Component suppliers have a wealth of information about their products, such as wear algorithms and load lifetime ratings. Normally, this information is considered the manufacturer’s intellectual property, but it can be used in an algorithm without revealing its source. Even further, the component supplier might be able to provide algorithms that apply to the application.
3. Determine if the data is already available or if further programming or instrumentation are needed. Motion-control components, by their nature, have performance and diagnostic data, but plant managers don’t always realize the data exists. The challenge with lots of motion-control equipment is that it doesn’t necessarily store data for historical analysis. This is where publishing data to an IoT platform proves useful. In addition, the associations might not be obvious. If presented properly, many of these correlations will jump off the screen.
Let’s reexamine the tool bit as an example. Many motors have thermistors or thermocouples that monitor their temperature to prevent them from overheating. This thermal data is also proportional to how hard the motor works under normal conditions; i.e., the harder the motor works, the higher its temperature. So, if the motor’s thermal data correlated to bit use, a rise in the motor’s temperature might indicate the bit is becoming dull and should be replaced.
4. Fill in any gaps in data or analysis. If information is available but isn’t being reported to the PLC or automation controller, the manufacturer may agree to write and supply a code function block so that the software in the controller will report the needed data. Depending on the application, the engineers may decide to add a sensor to gather more information, like vibrational data.
5. Look at the acquired data and develop a way to use it. After the team has the data needed to understand what’s happening in some equipment, the plant manager, machine builder-integrator, and component manufacturer should discuss possible ways to use it. The answer may be a change to the process, component, or a software function block. In the case of our machine tool example, the answer might be a function block that tracks the speeds, feed rate, and runtime for a given bit to monitor its projected life, but also monitors temperature rise and torque load on the cutting motor to detect any anomalies in performance.
6. Replicate successes with similar applications in the plant and other plants. If the same component is used in several machines, then the ROI from success can be increased with every re-use of an IoT application. If the machines are in the same plant, it’s simply a matter of collecting data over the factory network. At this stage, manufacturers might need to start determining their platform of choice to establish some standards on how information is being presented, tracked, and monitored.
7. Expand on that application to include data from related components. After fixing the problem with the machine tool bit, the engineer might investigate the servo motor attached to that shaft to determine what else could be done to improve performance. For instance, it might be as simple as scaling the motor rpm as a function of the tool’s wear. By simply “knowing” the bit is at only 50% of its usable life, the machine could be programmed to slow the bit’s speed or feed rate to maintain a good surface finish on parts being made. These relatively simple software changes might make big differences in eliminating scrapped material.
Many components in a machine can be discrete starting points for the Industrial Internet of Things, such as a servo motor, actuator, or complete multi-axis system.
Components of Discrete IoT
Although the basic concept underlying IoT, a network of smart devices, has been around for decades, several technologies had to mature and costs had to drop before it could start to be realized.
By networking machines to communicate, users can generate and capture invaluable data that can be shared with other machines and management software. This consolidated information can also yield insights into previously unmonitored components and processes to extract more value from both.
Discrete IoT does not need the same level of upfront infrastructure investment as enterprise-wide implementations. Nevertheless, it does rely on many of the same basic components, such as intelligent motion-control components that can be wired to communicate data. Many components such as drives already have Ethernet ports to hook into the factory network. Other components will need to be wired. Fortunately, serial protocols such as IO Link provide low-cost, easily provisioned means of communication at the edge. Low-cost wireless sensors can also be added where needed.
Data from edge devices is sent via a variety of Ethernet protocols and collected at the automation controller or PLC. As these are requirements for any motion-control application, they entail no additional cost.
From there, the data goes via Ethernet protocol to SCADA system or the factory network. Up to this point, the data is kept within the walls of the facility, and in many applications, that’s as far as it needs to go to improve productivity, so long as the user can exploit any application insights within a given platform.
If the data needs to be accessed remotely, a gateway to the internet may be required; however, many automation controllers include an embedded web server and can present data externally without a separate gateway. This is where security and IP concerns are greatest. In some instances, the concern can be mitigated by processing the data locally and publishing only essential data in an encrypted format when requested. Recently the OPC foundation presented a new open protocol to securely present this information up from the sensor to the cloud to help mitigate the concern of security while maintaining a low barrier to entry for engineers looking to get started.
Suppliers should make it easy for customers by minimizing the technical challenges that prevent their customers from leveraging IoT. These challenges include legacy equipment and components that aren’t equipped to communicate with each other, equipment and machines with incompatible communication protocols, the requirement to provide security for devices and data, and the necessity to decide which data to collect and how to present it to those who need it.
IoT implementations get bogged down too often by the huge scope of enterprise-wide implementations. For individual processes, however, much of the infrastructure is already in place. Starting with one specific application is manageable. What’s more, it forces managers to focus on a specific problem, ensuring a quick payback on the effort. By following the steps outlined above, plant managers and machine builders can work effectively with motion-control suppliers to unlock the information in their components and enjoy productivity and quality improvements without waiting for the rest of the enterprise to get in step.
IO Link is an open-standard communication protocol for cost-effectively connecting edge devices. Many new automation components take advantage of this technology for its faster time to commissioning or diagnostic functions. Pictured is an IO-Link interface on board a Parker pneumatic valve bank.
