Machine learning can help organizations improve manufacturing operations and increase efficiency, productivity, and safety by analyzing data from connected machines and sensors, machine. For example, its algorithms can predict when equipment will likely fail, so manufacturers can schedule maintenance before problems occur, thereby reducing downtime and repair costs.
How machine learning works
Machine learning teaches computers to learn from data – to do things without being specifically told how to do them. It is a type of artificial intelligence that enables computers to automatically learn or improve their performances by learning from their experiences.
Imagine you have a bunch of toy cars and want to teach a computer to sort them into two groups: red and blue cars. You could show the computer many pictures of red and blue cars and say, “this is a red car” or “this is a blue car” for each one.
After seeing enough examples, the computer can start to guess which group a car belongs in, even if it’s a car that it hasn’t seen before. The machine is “learning” from the examples you show to make better and better guesses over time. That’s machine learning!
Steps to translate it to industrial use case
As in the toy car example, we must have pictures of each specimen and describe them to the computer. The image, in this case, is made up of data points and the description is a label. The sensors collecting data can be fed to the machine learning algorithm in different stages of the machine operation – like when it is running optimally, needs inspection, or needs maintenance, etc.
Data taken from vibration, temperature or pressure measures, etc., can be read from different sensors, depending on the type of machine or process to monitor.
In essence, the algorithm finds a pattern for each stage of the machine’s operation. It can notify the operator about what must be done given enough data points when it starts to veer toward a different stage.
What infrastructure is needed? Can my PLC do it?
The infrastructure needed can vary depending on the algorithm’s complexity and the data volume. Small and simple tasks like anomaly detection can be used on edge devices but not on traditional automation controllers like PLCs. Complex algorithms and significant volumes of data require more extensive infrastructure to do it in a reasonable time. The factor is the processing power, and as close to real-time we can detect the machine’s state, the better the usability.
Comparing “IO-Link” and “Safety” to “IO-Link Safety”
There are many I/O blocks that have “IO-Link” and “Safety” in their descriptions, which can cause some confusion about which safety features they include. Here’s an overview of different safety-named blocks and how they compare to IO-Link Safety.
Safety Network Blocks
These blocks have I/O ports that use Pin 4 and Pin 2 as OSSD signals (safety ports). OSSD—output switching signal devices—send 24-volt signals over two wires to confirm that a device is operating in a safe condition. If 0 volts are detected in either signal, besides their safety-checking 0-volt pulses, it’s read as a safety event that signals the machine to go into a safe state. Safety network blocks are only for standard (non-network) safety devices. These blocks communicate directly back to a Safety Controller over safety protocols like CIP Safety, PROFIsafe, etc. These blocks typically can monitor between 8-16 standard safety devices. There is no intelligence built into the safety devices.
Safety Network Blocks with IO-Link
Blocks in this category usually have a mixture of I/O ports on them. The ports can range from standard I/O to standard IO-Link communication, and in addition, include ports that use Pin 4 and Pin 2 as OSSD signals (safety ports). These blocks communicate over the safety protocols with only a few ports to connect standard (non-network) safety devices. There is some versatility with these blocks since you can wire standard sensors, IO-Link devices, and safety devices to it. The drawback is, you will always run short of the port style you need and, in the end, use more blocks to cover either the safety or IO-Link needs of the application. There is no intelligence built into the safety devices.
Safety over IO-Link Blocks
In this system/architecture, there are standard IO-Link Masters communicating to the Safety PLCs/Controllers over standard protocols like EtherNet/IP, PROFINET, etc. Connected to the IO-Link Ports of these Masters are Safety over IO-Link devices, currently limited to only Safety over IO-Link hubs. The Safety PLCs/Controllers communicate via safety protocols like PROFIsafe to the standard IO-Link Master, and then using the IO-Link communication channel, they bridge the gap to the Safety over the IO-Link hub via the “black channel.” These Safety over IO-Link hub’s ports use Pin 4 and Pin 2 as OSSD signals (safety ports), so standard (non-network) safety devices can be connected. This system provided a “gap filler” while IO-Link Safety was being developed. In this system/architecture, the standard IO-Link Masters allowed standard IO-Link devices and Safety over IO-Link hubs to be connected to any ports. This brought even more versatility to an application and the beginnings of the benefits of IO-Link. Still, there is no intelligence built into the safety devices.
IO-Link Safety
IO-Link Safety adds a safety communication layer to IO-Link. The difference between this and Safety over IO-Link is that this safety layer applies to both the IO-Link Master and IO-Link Safety devices. Within a CIP Safety or PROFIsafe network, the safety communication protocol has top priority over standard EtherNet/IP or PRIFONET data if both are existing on the same physical network. The same is true for IO-Link Safety: both standard and safety IO-Link protocols can exist on the same physical cable between the IO-Link Master ports and IO-Link Safety devices, with IO-Link Safety carrying the top priority. For a deep dive into the IO-Link Safety protocol, I suggest visiting the IO-Link Consortium’s website at io-link.com. In this system/architecture, you have IO-Link Safety Masters, which communicate to the Safety PLCs/Controllers over safety protocols like CIP Safety, PROFIsafe, etc. The ports on the Masters can utilize Pin 4 and Pin 2 as OSSD signals (safety ports), so standard (non-network) safety devices can be connected. Pin 4 can also be used to carry standard IO-Link and IO-Link Safety communication to standard IO-Link devices and IO-Link Safety devices, respectively. This allows for the most versatile safety solution in the market–IO-Link Safety Masters that can accept standard (non-network) safety devices, standard IO-Link devices, and IO-Link Safety devices. Intelligence in the IO-Link Safety devices is now available.
Benefits of IO-Link Safety
IO-Link Safety devices are fieldbus neutral: you just need to specify the IO-Link Safety Master to match the Safety PLCs/Controllers protocol.
IO-Link Safety Master port versatility: standard (non-network) safety devices, standard IO-Link devices, and IO-Link Safety devices can be connected.
Parameter storage: standard IO-Link and IO-Link Safety device’s parameters can be stored for ease of device replacement.
Smart IO-Link Safety device data: more data available, like internal temperature, humidity, number of cycles, power consumption, diagnostics, etc.
Simplified wiring: IO-Link Safety devices are still connected to the IO-Link Master port with a standard 3 to 4 conductor cable.
IIoT fit: IO-Link Safety gives more visibility to upper-level systems like SCADA, allowing safety device-level monitoring.
I am looking forward to seeing how quickly IO-Link Safety will be accepted, with how IO-Link numbers have skyrocketed over the last few years. The future looks great for IO-Link with IO-Link Safety, IO-Link Wireless and in the future, Single-Pair Ethernet (SPE). With all these new capabilities, what application can’t IO-Link support?
The Industrial Internet of Things (IIoT) is becoming an indispensable part of the manufacturing industry, leading to real-time monitoring and an increase in overall equipment effectiveness (OEE) and productivity. Since the machines are being connected to the intranet and sometimes to the Internet for remote monitoring, this brings a set of challenges and security concerns for these now-connected devices.
What causes security to be so different between OT and IT?
Operational Technology (OT) manufacturing equipment is meant to run 24/7. So, if a bug is found that requires a machine to be shut down for an update, that stop causes a loss in productivity. So, manufacturers can’t rely on updating operational equipment as frequently as their Information Technology (IT) counterparts.
Additionally, the approach of security for OT machines has largely been “security through obscurity.” If, for example, a machine is not connected to the network, then the only way to access the hardware is to access it physically.
Another reason is that OT equipment can have a working lifetime that spans decades, compared to the typical 2-5-year service life of IT equipment. And when you add new technology, the old OT equipment becomes almost impossible to update to the latest security patches without the effort and expense of upgrading the hardware. Since OT equipment is in operation for such a long time, it makes sense that OT security focuses on keeping equipment working continuously as designed, where IT is more focused on keeping data available and protected.
These different purposes makes it hard to implement the IT standard on OT infrastructure. But that being said, according to Gartner’s 80/20 rule-of-thumb, 80 percent of security issues faced in the OT environment are the same faced by IT, while 20 percent are domain specific on critical assets, people, or environment. With so many security issues in common, and so many practical differences, what is the best approach?
The solution
The difference in operation philosophy and goals between IT and OT systems makes it necessary to consider IIoT security when implementing the systems carefully. Typical blanket IT security systems can’t be applied to OT systems, like PLCs or other control architecture, because these systems do not have built-in security features like firewalls.
We need the benefits of IIoT, but how do we overcome the security concerns?
The best solution practiced by the manufacturing industry is to separate these systems: The control side is left to the existing network infrastructure, and IT-focused work like monitoring is carried out on a newly added infrastructure.
The benefit of this method is that the control side is again secured by the method it was designed for – “security by obscurity” – and the new monitoring infrastructure can take advantage of the faster developments and updates of the IT lifecycle. This way, the operations and information technology operations don’t interfere with each other.
With more and more customers getting onboard with IIoT applications in their plants, a new era of efficiency is lurking around the corner. Automation for maintenance is on the rise thanks to a shortage of qualified maintenance techs coinciding with a desire for more efficient maintenance, reduced downtime, and the inroads IT is making on the plant floor. Predictive Maintenance and Predictive Analytics are part of almost every conversation in manufacturing these days, and often the words are used interchangeably.
This blog is intended to make the clear distinction between these phrases and put into perspective the benefits that maintenance automation brings to the table for plant management and decision-makers, to ensure they can bring to their plants focused innovation and boost efficiencies throughout them.
Before we jump into the meat of the topic, let’s quickly review the earlier stages of the maintenance continuum.
Reactive and Preventative approaches
The Reactive and Preventative approaches are most commonly used in the maintenance continuum. With a Reactive approach, we basically run the machine or line until a failure occurs. This is the most efficient approach with the least downtime while the machine or line runs. Unfortunately, when the machine or line comes to a screeching stop, it presents us with the most costly of downtimes in terms of time wasted and the cost of machine repairs.
The Preventative approach calls for scheduled maintenance on the machine or line to avoid impending machine failures and reduce unplanned downtimes. Unfortunately, the Preventative maintenance strategy does not catch approximately 80% of machine failures. Of course, the Preventative approach is not a complete waste of time and money; regular tune-ups help the operations run smoother compared to the Reactive strategy.
Predictive Maintenance vs. Predictive Analytics
As more companies implement IIoT solutions, data has become exponentially more important to the way we automate machines and processes within a production plant, including maintenance processes. The idea behind Predictive Maintenance (PdM), aka condition-based maintenance, is that by frequently monitoring critical components of the machine, such as motors, pumps, or bearings, we can predict the impending failures of those components over time. Hence, we can prevent the failures by scheduling planned downtime to service machines or components in question. We take action based on predictive conditions or observations. The duration between the monitored condition and the action taken is much shorter here than in the Predictive Analytics approach.
Predictive Analytics, the next higher level on the maintenance continuum, refers to collecting the condition-based data over time, marrying it with expert knowledge of the system, and finally applying machine learning or artificial intelligence to predict the event or failure in the future. This can help avoid the failure altogether. Of course, it depends on the data sets we track, for how long, and how good our expert knowledge systems are.
So, the difference between Predictive Maintenance and Predictive Analytics, among other things, is the time between condition and action. In short, Predictive Maintenance is a stepping-stone to Predictive Analytics. Once in place, the system monitors and learns from the patterns to provide input on improving the system’s longevity and uptime. Predictive Maintenance or Preventative Maintenance does not add value in that respect.
While Preventative Maintenance and Predictive Maintenance promises shorter unplanned downtimes, Predictive Analytics promises avoidance of unplanned downtime and the reduction of planned downtime.
The first step to improving your plant floor OEE is with monitoring the conditions of the critical assets in the factory and collecting data regarding the failures.
If you have ever walked through a stamping department at a metal forming facility, you have heard the rhythmic sound of the press stamping out parts, thump, thump. The stamping department is the heart manufacturing facility, and the noise you hear is the heartbeat of the plant. If it stops, the whole plant comes to a halt. With increasing demands for higher production rates, less downtime, and reduction in bad parts, stamping departments are under ever-increasing pressure to optimize the press department through die protection and error-proofing programs.
The die-protection risk assessment team
The first step in implementing or optimizing a die protection program is to perform a die-protection risk assessment. This is much like risk assessments conducted for safety applications, except they are done for each die set. To do this, build a team of people from various positions in the press department like tool makers, operators, and set-up teams.
Once this team is formed, they can help identify any incidents that could occur during the stamping operations for each die set and determine the likelihood and the severity of possible harm. With this information, they can identify which events have a higher risk/severity and determine what additional measures they should implement to prevent these incidents. An audit is possible even if there are already some die protection sensors in place to determine if there are more that should be added and verify the ones in place are appropriate and effective.
The top 4 die processes to check
The majority of quality and die protection problems occur in one of these three areas: material feed, material progression, and part- and slug-out detections. It’s important to monitor these areas carefully with various sensor technologies.
Material feed
Material feed is perhaps the most critical area to monitor. You need to ensure the material is in the press, in the correct location, and feeding properly before cycling the press. The material could be feeding as a steel blank, or it could come off a roll of steel. Several errors can prevent the material from advancing to the next stage or out of the press: the feed can slip, the stock material feeding in can buckle, or scrap can fail to drop and block the strip from advancing, to name a few. Inductive proximity sensors, which detect iron-based metals at short distances, are commonly used to check material feeds.
Material progression
Material progression is the next area to monitor. When using a progressive die, you will want to monitor the stripper to make sure it is functioning and the material is moving through the die properly. With a transfer die, you want to make sure the sheet of material is nesting correctly before cycling the press. Inductive proximity sensors are the most common sensor used in these applications, as well.
Here is an example of using two inductive proximity sensors to determine if the part is feeding properly or if there is a short or long feed. In this application, both proximity sensors must detect the edge of the metal. If the alignment is off by just a few millimeters, one sensor won’t detect the metal. You can use this information to prevent the press from cycling to the next step.
Short feed, long feed, perfect alignment
Part-out detection
The third critical area that stamping departments typically monitor is part-out detection, which makes sure the finished part has come out of the stamping
area after the cycle is complete. Cycling the press and closing the tooling on a formed part that failed to eject can result in a number of undesirable events, like blowing out an entire die section or sending metal shards flying into the room. Optical sensors are typically used to check for part-out, though the type of photoelectric needed depends on the situation. If the part consistently comes out of the press at the same position every time, a through-beam photo-eye would be a good choice. If the part is falling at different angles and locations, you might choose a non-safety rated light grid.
Slug-ejection detection
The last event to monitor is slug ejection. A slug is a piece of scrap metal punched out of the material. For example, if you needed to punch some holes in metal, the slug would be the center part that is knocked out. You need to verify that the scrap has exited the press before the next cycle. Sometimes the scrap will stick together and fail to exit the die with each stroke. Failure to make sure the scrap material leaves the die could affect product quality or cause significant damage to the press, die, or both. Various sensor types can ensure proper scrap ejection and prevent crashes. The picture below shows a die with inductive ring sensors mounted in it to detect slugs as they fall out of the die.
Just like it is important to get regular checkups at the doctor, performing regular die-protection assessments can help you make continuous improvements that can increase production rates and reduce downtime. Material feed, material progression, part-out and slug-out detection are the first steps to optimize, but you can expand your assessments to include areas like auxiliary equipment. You can also consider smart factory solutions like intelligent sensors, condition monitoring, and diagnostics over networks to give you more data for preventative maintenance or more advanced error-proofing. The key to a successful program is to assemble the right team, start with the critical areas listed above, and learn about new technologies and concepts that are becoming available to help you plan ways to improve your stamping processes.
The rise of many players in manufacturing automation, along with factories’ growing adoption of Industrial Internet of Things (IIoT) and automation solutions, present a suitable environment for open-source software. This software is a value-adding solution for manufacturers, regardless of their operation technology and management requirements, due to the customization, resiliency, scalability, accessibility, cost-effectiveness, and quality it allows.
Customization
Software developers who use open-source code provide software with a core code that establishes specific features and allows users to access it and make changes as necessary. The process is much like being able to complete an author’s writing prompt or change the end of a story. Unlike a closed system that locks users in, open-source allows them to adapt and modify the code to meet a particular need or application.
This add-on coding system provides endless customization. It enables communities (i.e., users) to add or remove features beneficial in an integration phase, such as features for user testing or to find the best solution for a machine.
Customization is also valuable regarding data visualizations; users can develop dashboards and visuals that best describe their operations. Suppose a sensor provides real-time condition monitoring data over a particular machine. In that case, it’s possible to customize the code supporting the software that gathers and processes the data for specific parameters or to calculate specific values.
Resiliency
Additionally, open-source code is resilient to change because it can be modified quickly. The ability to quickly add or remove features and adapt to cyber environments or specific applications also makes it volatile. Like exposure to pathogens can help strengthen an immune response to said pathogens, so can an open-source code be made stronger by its exposure to different environments and applications to be ready to face cybersecurity threats. Implementing an open code isn’t any less risky (cybersecurity-wise) than closed codes due to the testing and enhancements made by so many coders or programmers. However, it is up to the implementer to use the same rules that apply to other closed source software. The implementer must be aware of the code’s source and avoid code from non-reputable sources who could have modified it with negative intentions. Overall, the code is resilient, adaptable, and agile to adapt given a new environment.
Scalability
The add-on and customization aspects of open-source also allow the code to be highly scalable. This scalable implementation happens in two dimensions: adoption timeline and application-based. Both are important to guarantee user acceptance and that it meets the operation and application requirements. Regarding the adoption timeline, scalability allows modification of the software and code to meet users’ expectations. Open-sourced code enables the implementation of features for user testing and feedback. The ultimate solution will include multiple iterations to meet the users’ needs and fulfill operation expectations.
On the other hand, this code is scalable based on the application(s), such as working on different machines, multiples of the same machine with different purposes, or adding/dropping features for specific uses. Say, for example, there are three of the same machine (A, B, and C), but they are in different environments. Machine A is in an environment that is 28°F , B is at room temperature, and C is exposed to constant wash-down. In this case, the condition monitoring software defines the acceptable parameters for each scenario, avoiding false alarms from erroneous triggers. In this example, the base code is adapted to include specific features based on the application.
Accessibility
In general, cost-effective and high-quality open-source code is available online. There are additional resources such as free coding tutorials that don’t require any licenses as well. Moreover, when programmers update an open code, they must make the new version available again, ensuring that the code is accessible and up to date.
Cost-effectiveness and quality
Regarding cost-effectiveness, using community open-source code significantly reduces the cost of developing, integrating, and testing software built in-house. It also reduces the implementation time and makes for better production operations. Essentially, it is high-quality, reliable code created by trusted sources for multiple coders and users.
“The application drives the technology” mantra is at the heart of open-source software development—a model where source code is available for community members to use, modify, and share. IIoT enablers and providers in the manufacturing industry own a particular solution that is then available for manufacturers to adapt to their specific operational requirements. With the increasing adoption of data-collecting technologies, it is in manufacturers’ best interest to seek software providers who grant them the flexibility to adjust software solutions to meet their specific needs. Automation is a catalyst for data-driven operation and maintenance.
In manufacturing and automation control, the programmable logic controller (PLC) is an essential tool. And since the PLC is integrated into the machine already, it’s understandable that you might see the PLC as all that you need to do anything in automation on the manufacturing floor.
Condition monitoring in machine automation
For example, process or condition monitoring is emerging as an important automation feature that can help ensure that machines are running smoothly. This can be done by monitoring motor or mechanical vibration, temperature or pressure. You can also add functionality for a machine or line configuration or setup by adding sensors to verify fixture locations for machine configuration at changeovers.
One way to do this is to wire these sensors to the PLC and modify its code and use it as an all-in-one device. After all, it’s on the machine already. But there’s a definite downside to using a PLC this way. Its processing power is limited, and there are limits to the number of additional processes and functions it can run. Why risk possible complications that could impact the reliability of your control systems? There are alternatives.
External monitoring and support processes
Consider using more flexible platforms, such as an edge gateway, Linux, and IO-Link. These external sources open a whole new world of alternatives that provide better reliability and more options for today and the future. It also makes it easier to access and integrate condition monitoring and configuration data into enterprise IT/OT (information technology/operational technology) systems, which PLCs are not well suited to interface with, if they can be integrated at all.
Here are some practical examples of this type of augmented or add-on/retrofit functionality:
Motor or pump vibration condition monitoring
Support-process related pressure, vibration and temperature monitoring
Monitoring of product or process flow
Portable battery based/cloud condition monitoring
Mold and Die cloud-based cycle/usage monitoring
Product changeover, operator guidance system
Automatic inventory monitoring warehouse system
Using external systems for these additional functions means you can readily take advantage of the ever-widening availability of more powerful computing systems and the simple connectivity and networking of smart sensors and transducers. Augmenting and improving your control systems with external monitoring and support processes is one of the notable benefits of employing Industrial Internet of Things (IIoT) and Industry 4.0 tools.
The ease of with which you can integrate these systems into IT/OT systems, even including cloud-based access, can dramatically change what is now available for process information-gathering and monitoring and augment processes without touching or effecting the rudimentary control system of new or existing machines or lines. In many cases, external systems can even be added at lower price points than PLC modification, which means they can be more easily justified for their ROI and functionality.
The filling of medical vials requires flexible automation equipment that can adapt to different vial sizes, colors and capping types. People are often deployed to make those equipment changes, which is also known as a recipe change. But by nature, people are inconsistent, and that inconsistency will cause errors and delay during change over.
Here’s a simple recipe to deliver consistency through operator-guided/verified recipe change. The following ingredients provide a solid recipe-driven change over:
Incoming Components: Barcode
Fixed mount and hand-held barcode scanners at the point-of-loading ensure correct parts are loaded.
Change Parts: RFID
Any machine part that must be replaced during a changeover can have a simple RFID tag installed. A read head reads the tag in ensure it’s the correct part.
Feed Systems: Position Measurement
Some feed systems require only millimeters of adjustment. Position sensor ensure the feed system is set to the correct recipe and is ready to run.
Conveyors Size Change: Rotary Position Indicator
Guide rails and larger sections are adjusted with the use of hand cranks. Digital position indicators show the intended position based on the recipes. The operators adjust to the desired position and then acknowledgment is sent to the control system.
Vial Detection: Array Sensor
Sensor arrays can capture more information, even with the vial variations. In addition to vial presence detection, the size of the vial and stopper/cap is verified as well. No physical changes are required. The recipe will dictate the sensor values required for the vial type.
Final Inspection: Vision
For label placement and defect detection, vision is the go-to product. The recipe will call up the label parameters to be verified.
Traceability: Vision
Often used in conjunction with final inspection, traceability requires capturing the barcode data from the final vials. There are often multiple 1D and 2D barcodes that must be read. A powerful vision system with a larger field of view is ideal for the changing recipes.
All of these ingredients are best when tied together with IO-Link. This ensures easy implantation with class-leading products. With all these ingredients, it has never been easier to implement operator-guided/verified size change.
In today’s world, we depend on the PLC to be our eyes and ears on the health of our automation machines. We depend on them to know when there has been an equipment failure or when preventative maintenance is needed. To gain this level of diagnostics, the PLC must do more work, i.e. more rungs of code are needed to monitor the diagnostics supplied to the sensors, actuators, motors, drives, etc.
In terms of handling diagnostics on a machine, I see two philosophies. First, put the bare bones minimum in the PLC. With less PLC code, the scan times are faster, and the PLC runs more efficiently. But this version comes with the high probability for longer downtime when something goes wrong due to the lack of granular diagnostics. The second option is to add lots of diagnostic features, which means a lot of code, which can lessen downtime, but may throttle throughput, since the scan time of the PLC increases.
So how can you gain a higher level of diagnostics on the machine and lessen the burden on the PLC?
While we usually can’t have our cake and eat it too, with Industry 4.0 and IIoT concepts, you can have the best of both of these scenarios. There are many viewpoints of what these terms or ideas mean, but let’s just look at what these two ideas have made available to the market to lessen the burden on our PLCs.
Data Generating Devices Using IO-Link
The technology of IO-Link has created an explosion of data generating devices. The level of diversity of devices, from I/O, analog, temperature, pressure, flow, etc., provides more visibility to a machine than anything we have seen so far. Utilizing these devices on a machine can greatly increase visibility of the processes. Many IO-Link masters communicate over an Ethernet-based protocol, so the availability of the IO-Link device data via JSON, OPC UA, MQTT, UDP, TCP/IP, etc., provides the diagnostics on the Ethernet “wire” where more than just the PLC can access it.
Linux-Based Controllers
After using IO-Link to get the diagnostics on the Ethernet “wire,” we need to use some level of controller to collect it and analyze it. It isn’t unusual to hear that a Raspberry Pi is being used in industrial automation, but Linux-based “sandbox” controllers (with higher temperature, vibration, etc., standards than a Pi) are available today. These controllers can be loaded with Codesys, Python, Node-Red, etc., to provide a programming platform to utilize the diagnostics.
Visualization of Data
With IO-Link devices providing higher level diagnostic data and the Linux-based controllers collecting and analyzing the diagnostic data, how do you visualize it? We usually see expensive HMIs on the plant floors to display the diagnostic health of a machine, but by utilizing the Linux-based controllers, we now can show the diagnostic data through a simple display. Most often the price is just the display, because some programming platforms have some level of visualization. For example, Node-Red has a dashboard view, which can be easily displayed on a simple monitor. If data is collected in a server, other visualization software, such as Grafana, can be used.
To conclude, let’s not overburden the PLC with diagnostic; lets utilize IIoT and Industry 4.0 philosophy to gain visibility of our industrial automation machines. IO-Link devices can provide the data, Linux-based controllers can collect and analyze the data, and simple displays can be used to visualize the data. By using this concept, we can greatly increase scan times in the PLC, while gaining a higher level of visibility to our machine’s process to gain more uptime.
It’s never too late to add more visibility to an automation machine.
In the past, when it came to IO-Link opportunities, if the PLC on the machine was a SLC 500, a PLC-5, or worse yet, a controller older than I, there wasn’t much to talk about. In most of these cases, the PLC could not handle another network communication card, or the PLC memory was maxed, or it used a older network like DeviceNet, Profibus or ASi that was maxed. Or it was just so worn out that it was already being held together with hope and prayer. But, today we can utilize IIoT and Industry 4.0 concepts to add more visibility to older machines.
IIOT and Industry 4.0 have created a volume of products that can be utilized locally at a machine, rather than the typical image of Big Data. There are three main features we can utilize to add a level of visibility: Devices to generate data, low cost controllers to collect and analyze the data, and visualization of the data.
Data Generating Devices
In today’s world, we have many devices that can generate data outside of direct communication to the PLC. For example, in an Ethernet/IP environment, we can put intelligent devices directly on the EtherNet/IP network, or we can add devices indirectly by using technologies like IO-Link, which can be more cost effective and provide the same level of data. These devices can add monitoring of temperature, flow, pressure, and positioning data that can reduce downtime and scrap. With these devices connected to an Ethernet-based protocol, data can be extracted from them without the old PLC’s involvement. Utilizing JSON, OPC UA, MQTT, UDP and TCP/IP, the data can be made available to a secondary controller.
Linux-Based Controllers
An inexpensive Raspberry Pi could be used as the secondary controller, but Linux-based open controllers with industrial specifications for temperature, vibration, etc. are available on the market. These lower cost controllers can then be utilized to collect and analyze the data on the Ethernet protocol. With a Linux based “sandbox” system, many programming software packages could be loaded, i.e. Node-Red, Codesys, Python, etc., to create the needed logic.
Visualization of Data
Now that the data is being produced, collected and analyzed, the next step is to view the information to add the extra layer of visibility to the process of an older machine. Some of the programming software that can be loaded into the Linux-based systems, which have a form a visualization, like a dashboard (Node-Red) or an HMI feel (Codesys). This can be displayed on a low-cost monitor on the floor near the machine.
By utilizing the products used in the “big” concepts of IIOT and Industry 4.0, you can add a layer of diagnostic visualization to older machines, that allows for easier maintenance, reduced scrap, and predictive maintenance.
Imagine you have a bunch of toy cars and want to teach a computer to sort them into two groups: red and blue cars. You could show the computer many pictures of red and blue cars and say, “this is a red car” or “this is a blue car” for each one.
