Check the Logic: PLC vs. Pump Controller

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