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
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.
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."