Automated Data Collection for Production Monitoring
- Home >
- articles >
- automation >
- production monitoring
By Rob Anderson
5 steps in automating data collection for analytics in manufacturing.
Whitepaper on automated data collection for production monitoring and analysis. A 5-step guide to manufacturing data collection critical to Industry 4.0. Presumably, you are reading this because you are at least thinking about the benefits of installing an automated data collection system at your facility. This paper addresses the five essential steps to perform analytics in manufacturing data reliably.
Each step is building on the strength of the previous. As you will read, I elaborate on the first stage, Data Collection, because I feel this is the most important part of the system. Do a good job here and in automating data collection; the other four steps will be greatly simplified. Do a poor job here; the manufacturing data collection system may be a never-ending project.
Explorer below the 5 steps to perform analytics in manufacturing data reliably:
Automated Data Collection
A solid data collection method is as important to a production monitoring system as a good foundation is for a house. With a house, if the foundation isn't "square," you would forever compensate by adjusting floors, walls, ceilings, windows, and doors for the original mistake. With a manufacturing data collection system, you may lose counts if the data collection method isn't sound. Or worse, miscount. If the foundation isn't constructed from good materials, i.e., good quality concrete, rebar, block, and mortar, the house can sag and cause problems until the day you sell the house, or it falls down, whichever comes first. Suppose when you are automating data collection, you do not use good materials, good quality industrial components, or sound engineering practices. As with the building-house scenario, you could have problems with the system for its lifetime.
Method. By method, I refer to the general architecture of the production monitoring system. The best method I found is to use a centralized computer system for storage and computation and a field device like a PLC or dedicated Counter that is physically linked to the real world, as shown in the illustration below. Don't try to bring the counts directly from the field to the computer system. A computer system typically isn't designed to receive the type of real-world signals and respond to them how you would want it to. For instance, if someone writes a big file over a network, that may cause a delay in processing some counts, so any reports you print may "look" wrong to the end user because counts that should have been recorded were recorded late due to the file transfer. Another problem with using the computer system as the data collection device is that you won't get any production monitoring information for downtime when it fails and is down. Using the PLC or counter method, the counts remain and can be collected when the computer is back up and running.
Production monitoring should always be taken from limit switches, photo eyes, proximity switches, or other field devices necessary for the production line to operate. Production data should rarely be taken (if ever) from field devices installed for the sole purpose of production monitoring. The reason is maintenance. A field device necessary for the production line to operate must be maintained. A field device only there for production monitoring purposes will get very low priority from the maintenance department, and it may be difficult to prove to them that it isn't functioning properly.
Another good way to get a count is from the output of an already installed PLC or material-handling device, like a robot. If the PLC sends a signal to a conveyor telling it to start running after it has placed a part onto it and sends that same start signal every time it places the part, that might be a good way to get a count for parts out of that machine. Similarly, other machines have signals that they send to other devices that cause some action to be performed on the part of the device. In many cases, these signal types are a much better way of production monitoring than a sensor at that location.
When programming the production monitoring PLC or counter, what must be considered is the time the signal is sent to it and how to condition that signal within the PLC or counter.
⇒ The first thing you must watch for is the signal being too fast. If the signal is being taken directly from a switch, you must ensure it is in the "ON" state long enough for the PLC to "see" it and react. PLC response time can vary depending on the type of controller and the size of the program it contains. By PLC response, I mean the rise time of the signal within the PLC and the scan time of the program. Minimum sensor on time = Rise time of the PLC + 2 scan times + the ON Delay. We'll cover ON Delay in a minute. So, the rise time for a given PLC (the time it takes an input to go from 0 to 1 because of internal capacitance) might be 50ms. The scan time might have been about 5ms. So, assuming that you have no ON Delay at all, the sensor must be on a minimum of 60ms. If it doesn't stay on long enough (see Figure 3 and Figure 5), you might miss a count, so your finished counts would be less than actual.
⇒ The second thing you must be concerned about is how much time your signal is in the "OFF" state between counts. Minimum sensor off time = Fall time of the PLC + 2 scan times + the OFF Delay. Using this equation, you can be positive that the PLC has "seen" the transition from "ON" to "OFF". If your signal doesn't remain "OFF" long enough, then your PLC might not see that it was ever "OFF" and fail to count the next part (see Figure 2 above). This would result in a count that was lower than actual.
⇒ Another problem you can encounter is if your signal is sent to the PLC more than once for the same part. I.E. switch bounce. This can happen if you have a limit switch that "swings". When the part first contacts the limit switch, the signal is sent to the production monitoring PLC and remains "ON" for some time while the part travels under the switch. At that exact moment, the limit switch is free from the part, and the wand on the switch physically swings back to and through its normal position, swinging up and "making" again. If your PLC happens to read its I/O at this point, then you can get more counts than actual. You fix this problem by having a de-bounce time or ON Delay programmed into your PLC or Counter to allow it to ignore active signals for only a short time. You may also need an OFF Delay, which will act like the ON Delay to filter out erroneous signals. The ON Delay and OFF Delay time for each sensor usually arrive by trial and error, but it can be no longer than the amount of time your sensor is "ON" and must be greater than one scan time of the PLC. Try one-fourth of the sensor "ON" time as a good starting place. Look at Figure 1 for an example of how an OFF Delay can filter out a bad signal.
Look at Figure 4 for an example of the perfect production monitoring signal and response. In the preceding sections, I have shown you a few things that you shouldn't do, and I've also given you some formulas for calculating the minimum amount of time your sensor should be on and off. But remember, the longer your sensor is off between counts and the longer your sensor is on while the part is there, the better; you don't have to use the minimums.
From a software perspective, counts should always be retrieved as delta values and stored. So, for example, you program the computer system to scan the PLCs once a minute; the computer would poll the PLC for any counts that had occurred since the last polling and then zero out the register(s) in the PLC. Something you don't want to do is to allow the PLC to count continuously without zeroing. The computer system can poll the PLC periodically and retrieve the new count, then calculate the difference between the old and the new. Although it doesn't seem much harder on the surface, this approach has hidden pitfalls. The simplest method is the best. Just zero out the PLC count after reading it. Store the delta value in a database.
Materials and Installation. I don't have much to say about the materials you use. I have never used anything besides industrial-grade equipment and haven't had many problems there. I know of a system that uses barcode readers for data collection on the factory floor. They used the type of barcode wands you find in retail stores. The system was plagued with problems, and the equipment was not good enough. Not only did they have their share of normal hardware breakdowns, but the inspection people entering the information would purposefully damage the equipment to get out of work.
As far as installation is concerned, if you have been involved with factory floor installations before, do what you normally do. If you are from the IT world, ensure your dedicated manufacturing data collection equipment is housed in the appropriate NEMA enclosure for your job. Some sites may require a water-tight enclosure, others may suffer from dust, and others may need stainless steel. Do some research on your conditions and take the time and spend the money to use the right equipment for the job. Protect your wiring. You will want to run a conduit or armored cable from the PLC enclosure to the machine. You will also need to protect your networking cable. This, too, should probably be done via conduit. If there is a cable tray leading back to the computer system, then by all means, use it. Don't drape your cables from the rafters or expose them for people to swing on.
Production Data Storage
All I can say here is to use a commercial database. Do not try to write your own code to store data in a user file. You will suffer from this later. Many commercial databases available today should do the job quite nicely. MS Access and MySQL come to mind for smaller systems. If you need something larger, MS SQL Server, Oracle, or Sybase are leaders in the field.
When storing the information, store it as deltas. So, if you are retrieving information once per minute, you should have an entry for every count each minute. Then, when it comes time to print out a report, all you must do is give the report a time span to look at and summarize. You may also want to be able to create summary data files. For example, a daily file that has hourly entries for every count. This can be useful later on for displaying, reporting, and data analytics for manufacturing more efficiently.
Real-time Feedback Displays (HMI)
This topic is interesting because it can be very minimalistic or all-encompassing. For starters, the basic thing you need will be some operator feedback. What's the use of keeping manufacturing data if you can't tell people what it indicates? Whether you write your own program or buy someone else's, it should have a few displays to see " standard " counts, so you can at least look at some counts without needing a custom display. You should also be able to build displays that don't require programming. You may use the built-in display capability of the database you pick for the job. This would allow you or someone else within your organization to create and modify a display without the need to hire a programmer to do so. Many people are familiar with MS Access and MySQL.
Operator feedback can come in many forms. You may wish to have an overhead display that continuously displays a single count for several of your production personnel. This may be the number of packed boxes from the end of an assembly line. You may wish to have a single light turned on or off to indicate a quota has been met.
No matter what type of feedback you choose, I refer to counts as a summary of deltas that must be configurable over time. The first system I put in was unique for that customer; they wanted hourly, shift, and daily counts. The shift begins at a pre-defined time: 8 am, 4 pm, and 12 am. This inflexibility later caused problems in the form of added work. I advise that any system you write or buy should be flexible enough to allow your time period to begin at any time of the day and be any duration because many manufacturers have some places in their process that don't quite conform to their norm. For instance, the company I mentioned above had over 99% of their counts based on the hour... but for a couple of unique machines, they needed 30-minute counts, and I remember being asked about a 20-minute count. So, keep your production monitoring time periods flexible.
Manufacturing Data Management Reporting
Maybe the most important thing your production monitoring system will yield is a management production report. To what extent you report your counts depends on what you try to accomplish. There are two types of reports. Those used for problem analysis and those used for production monitoring.
The production monitoring report is simple. You're concerned with how much raw material went into your production line and how many parts came out. This type of report is mainly concerned with line efficiency and material usage.
The problem analysis type of report is usually more detailed. In this type of report, you are concerned with the efficiency of a machine or area. Generally, you use this report to tell you how many parts went into a machine and how many good parts came out. So, you can tell how many rejects your machine produces for a given time period. On some machines, it's impossible to tell if it's making bad parts because the same number that went in comes out, regardless. For this type of situation, you would usually include this machine in a larger area, maybe two or three machines. Or maybe you can add a sensor that will detect only good pieces and not bad. You may have to tie it into the machine control system to make the machine dependent upon the switch functioning properly. Otherwise, you violate the rule of not adding switches for production monitoring. In any case, this type of report will usually start at the beginning of a production line or production area and work its way through the area so that the output of one machine or area is the input of the next, and so on.
Data Analytics for Manufacturing
I could have covered this topic in either the Display section or the Report section. Still, I have waited until last because I feel analytics in manufacturing is a separate way of thinking about counts.
The single most useful tool you can have data analytics for manufacturing is a screen that will trend your production monitoring information over some historical time period. You can use the trend to see patterns you would miss by looking at a tabular report or display.
SPC tools like Pareto Charts, X-Bar (x̄), and R charts are simple trends. These tools can be useful for operations personnel to spot their own problems.
Sophisticated users may want to use Stat Graphics or another numerical analysis tool. This brings us to export data. How you export data is up to you. Still, as a minimum, you should be able to export raw data from your database for a variable time period to a comma-delimited file. If you can, exporting to an Excel spreadsheet would be a little nicer, as Excel can also graph your manufacturing data.
I hope this paper has helped educate and is not too tedious to read. If I am successful, you will not make the same mistakes that I have. --Rob Anderson
Related Article:
True Downtime Cost (TDC) article - This is a great way to share an overview of the True Cost of Downtime methodology with others who do not have a copy of "True Downtime Costs Analysis - 2nd Edition".
Overall Equipment Effectiveness OEE - Overall Equipment Effectiveness is a benchmarking tool as well as an analysis tool.
Information Systems in Fault Diagnosis (a PDF file) - This paper describes research undertaken to investigate the effectiveness of maintenance information systems in supporting activities during machine breakdown.
M2M Device Networking - The ability to extract raw data from a device, machine, or appliance and convert that data into useful information transforms decision-making from an art to a science.
