The year was 2013 and I was working for a client in Northeastern British Columbia (NEBC). We had just finished implementing another multi-well pad RTU installation and it had gone well. The client was preparing for the next set of drilling and completions as well as construction of their new plant. It was the perfect storm for some major changes to their SCADA infrastructure.
We (GlobalFlow) had won a project with them to migrate, upgrade and update their SCADA host system. At the time it was a small ClearSCADA setup. It had been in service for a little over 6 years, provided monitoring for about 30 wells and was due for an upgrade that would prepare it for the next 40 wells they planned to drill. As I planned and prepared I interviewed operators on the operation of the system as-is. The feedback we received was great. We combined it with some development on operator interface screens I had been playing with for a little over a year. What we received produced a set of requirements that shaped and guided the system we eventually put in.
Operators had noticed, rightly so, that their existing system appeared taxed and slow. It was mostly a function of the amount of data we were bringing back over their serial radio. The radio was set to 9600 baud (9.6kbps) and we were bringing back over 300 data points. Bench tested poll times were between 15 and 20 seconds per RTU! Obviously this was not scalable. Operators were complaining regularly about how long it took for alarms to come in and indicate on the SCADA system. We set poll times to 20 minutes to keep the radio channel free for demand polls, which operators were using often.
The client’s production engineering team was concerned about accurate data, data they could make decisions on. Our existing packages included five minute resolution data logging for this purpose. Being able to continue or provide even higher resolution data was a major requirement.
I thought long and hard about how to solve these problems. Through some research I found that there were communication protocols native to the equipment we were using that provided the solution we needed. Enter DNP3.
This purpose built protocol was designed from the ground up to be efficient, robust, reliable and scalable. It provides data with time stamps. There is report on exception capability. Using event buffers we could increase efficiency on the network by concentrating data. Best of all our SCADA host and RTU equipment (SCADAPack) natively supported the protocol with no added cost.
Things were not completely solved yet. ClearSCADA would not easily allow the serial radio to share between two protocols and we required two (DNP3 and Modbus) to accomplish our mission. Also, with all this report on exception data floating around, data collisions were bound to be an issue. We needed an updated telemetry solution to reach these new sites. So we settled on a fairly low cost 900MHz unlicensed data radio that included Ethernet capability.
Now the pieces were in place. We had the right RTU equipment, radios, communication protocols and SCADA host. The actual implementation was a long time coming because construction of the client’s new facility took several years. In the fall of 2014 we successfully brought on the first well pad using the new design and equipment. I will never forget commissioning this well pad because I was seeing alarms indicate on the host before the onsite programmer was seeing alarms on the local HMI or his programming software. We accomplished near real time alarming with report on exception.
As the solution aged and grew we had to do some tweaking. DNP3 allows for event logging on point change, meaning it can log events when a point changes by a certain amount. Those settings are all configurable and it can eventually get you into trouble. We found that 10kPa (or 1psi) was too fine a resolution for most everyday pressure monitoring applications. This particular drilling play was very high pressure so it was common to see pressure swings of 500kPa (~70psi) on tubing and casing pressure sensors, even under normal production.
Once they had built out to a few more pads we had to revisit the logging settings and reduce the resolution. This kept our DNP3 event logs from filling to quickly and flooding our Ethernet radio network with extra messages.
We likely could go much deeper with the protocol and the configuration of the system. We just scratched the surface of what DNP3 is capable of and how useful it could be, particularly to oil and gas users. Now if only the regulatory measurement data came back properly through that protocol…