August 25, 2015
Over the past decade or so, we’ve seen more and more production companies shift to full automation or SCADA (Supervisory Control and Data Acquisition) systems and away from stand-alone plunger lift controllers. Typically the decision is made when an engineer looks at what the remote terminal unit (RTU) at site is capable of. With the amount of money that is being invested and the capability of these systems, going away from an application specific controller seems like the logical choice. There is certainly a case for going to a fully connected and automated approach, but you may want to consider these factors before completely abandoning the idea of including a plunger lift controller.
The modern plunger lift controller comes with the ability to be controlled remotely. Whether connecting to a cell modem or the RTU, a plunger lift controller just becomes part of the system. This makes it accessible from the control room so that you can do anything you need without visiting the site. From a remote operator’s perspective, it doesn’t look or act any differently than any other part of the automation system.
A lot of operators are frustrated by the lack of local interface on most RTUs. They are forced to call into a control center or connect remotely with their laptop when visiting the site. It is much simpler to walk up to the controller on site, scroll through the history, make any tweaks, and immediately try them out.
Maybe you have static times in your RTU or maybe you have an optimization routine based on pressure or plunger arrival time. How do you know it is the best? What if you had a controller with a number of different types of optimization that were already developed, tested and refined? Many of the controllers on the market have algorithms that are proven to dramatically increase the production of a plunger lift well. There is a good chance that a smart controller will pay for itself as well as the rest of the automation system.
One more thing to consider is the arrival of the plunger velocity sensor. Undoubtedly, your RTU is not programmed to make use of a well head velocity sensor. Using a controller that can connect to a velocity sensor, use it for alarms and optimize it will increase the safety and production of the well without having to reprogram your RTU.
Have you ever wanted to switch optimization types, connect other devices, or make changes to how the RTU works, only to find out that you don’t have the right build? The feature you want is maybe in another program or missing all together. Controllers that are application specific often have many more configurations available and can readily adapt to the specific well needs. Simply turn on the feature you require without reprogramming.
One often overlooked cost is the development time to add to your RTU plunger program. This can cost hundreds of thousands of dollars. Even once the development is done, you also need to consider the cost to test the program and then roll it out to hundreds or thousands of sites. When you think long-term, the couple thousand dollars for a plunger lift controller doesn’t seem so expensive.
RTU programs are typically very basic. They have to be with the limited amount of room available for the plunger program. At minimum there should be the ability to shut in on a number of consecutive fast trips or a single dangerous trip. Beyond that there should be the ability to react to non-arrivals, low battery conditions and prolonged spikes in line pressure. These are relatively standard features in a good plunger lift controller.
If your RTU is Class I, Div 2 (Zone 2) and the sensors are located in the Class I, Div 1 (Zone 0/1) area you are likely using explosion proof solenoids, pressure transducers and arrival sensors. If you include a plunger lift controller, you are going to be able to use intrinsically safe devices that are much more cost effective. These devices do not need to be as rugged and can use simpler wiring.