SCADA and Data Collection

April 6, 2008
Many of Us Are Caught Up in Corrective Maintenance of Our SCADA Systems and Have Little Time to Work on Developing Data-Collection Systems

By Joe Roegner, SCADA technician Orange County, Orlando, Fla.

All day, every day, data is generated by your SCADA system. Some of you collect some of that data, and others even store the data. But putting that data to use gets a little tricky.

Remember the reams of paper we stored data on? Every now and then management would get excited and you’d end up going through mountains of paper searching for tidbits of information. You’d jot it down, put it into some kind of report, and hope the information is what they needed, so you wouldn’t have to do that again.

Today, we have better computers and better methods to store data. Unfortunately, it hasn’t lived up to the promise of what the Information Age shows us is possible. Many of us are caught up in corrective maintenance of our SCADA systems and have little time to work on developing data-collection systems. But time spent on developing better data collection and methods to use that data will pay off for you and your organization.

What if you took all of the alarm data for a day, sorted it and added up all the different alarms by site or device? Orange County, Florida Utilities did that every week with a daily alarm log from all of its lift stations. Roughly 5% of the sites had 90% of the alarms, with more than 5,000 alarms systemwide per day. Distributing the compiled data with pie graphs via email led to a dramatic reduction in alarms in a few months and a great increase in reliable operation of the lift stations. We still are trying to figure out how to automate the reporting so end users can get the report on demand.

The collection of alarm logs, runtimes, start counters and data from analog devices have great value in evaluating system performance. Collecting that data and putting it into graphs and reports can greatly help to spot performance problems early, before they result in downtime.

But numbers alone are not very meaningful and are hard to interpret. At one site a compressor ran constantly for a month due to an air leak. Once we built a graph showing the daily runtimes, the problem became obvious. Based on an idea from a coworker, I put together an HMI screen that showed the lift-station pump starts and runtimes for the previous day. Every morning he would check the screen and then visit the stations that weren’t alternating their pumps or had excessive runtimes, which indicated a clogged pump. For my own use, I put together a graph plotting a chemical feed system so that I could fine-tune the PLC to control the process. I reduced chemical costs by 50% and developed a more reliable and precise control for the operators.

In a meeting at a different company, I pointed out that managers were the only ones that could access the SCADA system, and they had other concerns besides monitoring alarms. I gave the example of the fellow who checked his lift stations daily. Since he knew more about what was going on with his equipment, it would be beneficial to allow others access to the SCADA system and relieve management from monitoring alarms so closely.

Later, all operators were given laptops with aircards so that they could access the SCADA system from wherever they were working. Many of those on call told me they would check alarms after-hours, remotely from home, and that helped them respond to after-hours problem calls.

We got more useful input from the operators on how to improve the system and what the shortcomings were. The end result was that we were able to make numerous improvements to our SCADA system. Problems were solved more quickly and a more reliable system resulted, allowing more time for preventive maintenance instead of running around doing emergency and corrective maintenance.