Pumps & Systems, September 2007

Why question the PLC? For many, questioning the application of a PLC to the pump station panel is surprising. After all, the pump station panel was once controlled with a range of relays, timers, and other devices - the exact type of application where the PLC has had such success in industrial automation. 

Furthermore, a PLC is easy to program with the intuitive ladder logic interface offered, even for non-programmers. Changing the control logic is so much easier than rewiring a panel.

However, across Australian and U.S. water and wastewater municipalities, a large (and ever-increasing) number of authorities are specifying pump controllers even where a PLC-based remote terminal unit (RTU) already exists in the panel. The reasons for reconsidering the PLC as the control device can be categorized as follows:

  • Software development, commissioning and maintenance costs are too high.
  • Reliability of the "one-off" software in a critical environment.
  • No user interface: still need additional wiring to indicator lights and control switches.
  • Non-standard I/O specific to a pump station application require additional components.

By contrast, a new generation of pump controllers has been developed primarily for municipal pump stations, with the key requirements being identified by users around the world as:

  • "Out of the box" control of a range of pump stations.
  • Intuitive operator interface with level indication, pump status, auto/off/manual control, fault resets, detailed fault data.
  • Simple interface for setpoint adjustment, station optimization, supply protection setup, etc.
  • 3-phase voltage monitoring, supply protection.
  • Detailed on-site datalogging with date/time stamp for every event.
  • Pump efficiency monitoring.
  • Flexible and expandable I/O to handle pump seal/thermal, any type of level devices.
  • High speed communications, including 10Mbit/s Ethernet.
  • Open protocols for remote telemetry: DNP3 and Modbus.

 

 

PLC Software Issues

Software Development

A ladder logic implementation of two pumps alternating in a well with common fault inputs is very straightforward. This often leads to the conclusion that a PLC will be ideal for a municipal pump station.

However, consider some of the functions that authorities typically want to implement:

  • Pump efficiency calculations (combination of power monitoring and flow measurements).
  • Preventative maintenance indicators of insulation resistance to indicate when pump windings require service.
  • Maximum off time for the station to minimize odors (configurable).
  • Maximum pump runtime (to reduce inefficient pumps running continually) - where the next pump to run cuts in after this time.
  • Maximum pumps to run (usually due to hydraulic constraints) - with the standby pump taking over from the duty pump at the standby level.
  • Primary 4-mA to 20-mA level sensing with a backup device.
  • Fault inputs with flexibility to choose whether pumps/station locked out, manual/SCADA reset required, auto-restart periods, etc.
  • Sump clean out once per day (pump down below the normal duty cut-out point to the snore point to clean out the well).
  • Different setpoint profiles for different applications/times of the day, as required.

There are many more functions, of course. The authority usually starts with the simple logic of two pumps alternating in a well with some hydraulic delays, then gradually introduces the required functions on stations that need them. Over a period of time, there will be multiple software variants across the network.

As the software grows more complex, the competent electrician model gives way to the system integrator requirement. Or the authority takes on specialist staff to help develop, test, and maintain the software. Once competent system integrators are involved, the following steps usually take place for new functions or commissioning of new stations:

  • Evaluating tenders/proposals from system integrators and then selecting the integrator.
  • Developing the user requirements and functional specification (the authority is paying the contractor for this).
  • Reviewing and signing off the user requirements and functional specification (internal costs).
  • Development of the application (the authority is paying).
  • Procurement of new hardware required (e.g. I/O modules).
  • Implementation and commissioning of new functions (internal costs of project management plus the contactor's time and travel costs).
  • Possibility of further site visits for issues identified during commissioning.
  • Signing off the site acceptance tests.

There may be additional specialist work required in mapping new information into the SCADA system, usually through a master RTU, that will incur additional costs.

 

 

Software Maintenance

A common response from the system integrator when he arrives onsite for the first time and looks at the existing code in the PLC is, "It's just a mess. I have no idea what they were trying to do. I'll have to rewrite it."

After several integrators play around with the same station over a period of time, the operations manager starts to consider implementing guidelines for software development. These procedures ensure uniform standards and documentation of code so each succeeding contractor does not trash development work. This procedural work takes time and expertise, and therefore imposes a significant cost burden on the authority.

Most importantly, note that software development, software maintenance and software standards are not usually a core competence of a municipal authority. This is not a regular part of their work, so the skills have to be learned. Each time a contractor comes on site, the authority typically pays around $100 per hour, sometimes more, and often additional travel costs are incurred.

Software Reliability

Consider the following example of a water authority in Australia. One local authority had a contractor on site working on and testing the PLC code. He mistakenly added the door contact to the pump starting logic, but tested the station with the door open (very common). After shutting the door, he drove home.

Two hours later, a high level alarm occurred and the contractor went back to the site. The first thing he did was open the door and start checking the control logic. Everything appeared okay, so he closed the door and went home again. Another hour went by and the high level alarm recurred. This time he found the problem and fixed it.

Each authority has a number of similar stories. In some cases, the contractor is footing the bill, but in many cases the authority is paying - especially when there is a spill and an EPA report required. The primary problem is not contractor competence or the inherent reliability of a PLC. The primary problem is how to test the one-off code in a PLC, in all the environments that might occur.

This problem is well understood by manufacturers that develop software for commercial deployment. They have developed well-proven systems and processes to ensure that code is progressively more reliable and bug-free. Some of these include automated test suites which run over 10,000,000 different tests on the software before a new release.

Since a PLC is for a one-off application, or even if the code is to be used in 50 pump stations, there is no guarantee that the latest code will be an improvement on the previous version. The testing is typically limited to the particular function being added. The more complex the code and the less familiar the contractor is with the overall architecture of the code, the more likely that a change will introduce a bug into other functions within the code.

Contrast with Dedicated Pump Controllers

One manufacturer has more than 15,000 pump controllers in the field at municipal pump stations. The experience of their support and sales staff means around 95 percent of problems called in by onsite users can be diagnosed within a few minutes.

Some problems involve other equipment in the panel; others involve a configuration (which can be easily changed), or sometimes a fault develops (usually related to power surges or lightning). In rare cases that usually involve a peculiar set of circumstances, a bug is found and targeted in the next release of software. Most bugs identified have a simple workaround to satisfy the user until the next release.

There is no software development on the part of the local authority, simply a determination of which parameters they want to enable and with what values. Therefore, user software development costs and software maintenance costs are negligible. These costs are limited to upgrades, which are typically supplied as part of a software package for a nominal sum.

User Interface and I/O

The other aspects of the comparison between the PLC and the pump controller relate to the user interface and the I/O.

Application Specific I/O

A pump controller unit contains flexible I/O which can be configured as pump seal, thermistor, FLS, CLS wired directly from the pump, etc. Frequently with a PLC, authorities use a separate control relay to wire in these inputs. For example, with certain pumps a particular relay is used which costs around $400 per pump. This means a two-pump system requires an additional $800 of components over the purchase price of the PLC.

User Interface PLC

A PLC-controlled municipal pump station typically has a set of selector switches (for auto, off, manual [hand]) wired in, along with a set of indicator lights. This allows the operators who visit the site to turn the pumps on and off and see the status of the pump station at a glance.

This can add additional cost, usually around a couple of hundred dollars, and frequently there is no level indicator. This means the operators must physically open the well to see what is happening - an increased hazard which municipal authorities try to avoid.

With a PLC implementation, no changes can be made to the site configuration without a contractor or highly trained staff member visiting the site with a laptop loaded with the appropriate licensed programming software. 

User Interface Pump Controller

A pump controller integrates the entire operator control and status annunciation into the control unit and provides the ability to program the unit, i.e. to change setpoints, delays, and enable/disable/change the configurable parameters that govern the functionality of the unit.

Operators can visit the site and change setpoints, as well as see which specific alarm conditions (if any) have occurred and clear those alarms. Electricians and engineers make changes as required, without needing to go through the extensive documentation and testing regime required of a PLC system.

Conclusions

When analyzing the lifetime cost of the solution, consider all of the above factors. Some of these are easy to quantify, such as the additional components required to bring a PLC to the level of a pump controller. Finding the actual commissioning cost of a new panel with a PLC to be $2,000 higher than one with a pump controller is common.

Software development, maintenance, and stability are much harder to quantify. However, based on our research, the costs associated with developing and maintaining a PLC to anything resembling the level of the pump controller are many times the purchase price of the PLC - and far outweigh the purchase price of the pump controller.