Companies with large, geographically dispersed networks, such as those in the oil and gas industry, can select one technology, one source, or one vendor to collect, retrieve and report data, and to assess the health of the network. Sometimes, this type of approach makes sense; other times the better solution is to incorporate a variety of technologies to form a single cohesive network.
The days of building large, single technology networks are likely behind us. Data and security demands at various levels of a large network are changing the game. Options now exist that allow us to achieve better manageability, expandability, cost, and speed. Hybrid networks can include landline phone, satellite, licensed radio, spread-spectrum radio, or cell-phone-based technologies. Data security, network speeds, infrastructure costs, and on-going costs are important factors to consider when selecting the right technology combination to meet these objectives.
If you are collecting data from multiple locations and delivering it to offices over a widespread area, no single technology can achieve your objectives. However, by combining technologies, you can create seamless data streams from several locations and share data over a LAN or WAN with multiple users. The end result is more effective and efficient management of the network and increased reliability through reduced downtime—all at a much more affordable price.
With the many new telemetry technologies available today, it is common to have communication capabilities available at all field locations, regardless of their location, and often involving several different technologies that are integrated into one hybrid system.
System Overview
Planning a network is the critical first step. To paraphrase Shakespeare, "an ounce of planning is worth a pound of cure." Start by asking yourself questions like these:
- What are our goals?
- What are our limitations?
- What technology do you have in place today?
- Are you willing to do a wholesale change or do you want to maintain what you have, yet optimize it?
- Who will need access to the data collected?
- Who will be responsible for maintaining the system?
- What system components are available and how do you choose the best fit?
Let's explore some of these questions in more depth.
What are our goals? It is important to start with the end goal in sight. To determine that, ask yourself these questions:
- How often do you need to poll the field?
- Will you have alarms?
- Will there be more than one controller, PLC, or electronic flow measurement (EFM) manufacturer's device I need to talk to?
- What readings do you need to see (how big is each poll)?
- Can one driver support all of the protocols I need to talk to?
Although it may sound complicated, it is not. Some simple rules can help guide our answers.
How often do you need to poll? Again, what are you trying to accomplish? If you need gas measurement, you can poll a few times a day. The EFM device will log hourly data on flow rate, pressure, temperature, etc., and you can poll to interrogate the EFM every four to six hours and bring back all the stored data at one time. If you are working on optimization (e.g., plunger lift) and need more granular data, you can again use the EFM to perform local control as well as to archive the data, or you can speed up the polling cycle in one of several ways, depending on the need.
First, you need to know how much data you are moving. If the stored plunger lift data and the gas custody transfer data come to a total of 2,000 bytes and the EFM talks to the radio at a port speed of 19.2 Kbps, how long will it take to poll a single EFM? Let's assume that your request for data from the host is 200 bytes. It will take the host 0.08 s to load the request for data into the radio. It takes the master radio 0.2 s to send the request to the slave radio over the air (assuming that the over-the-air speed is 115.2 Kbps). It will take 0.08 s to load the data from the slave radio into the EFM. The EFM will need a couple seconds to process the signal (assume that this takes 3 s). It will take 0.83 s for the EFM to load the data into the slave. Again, it will take 0.2 s for the over-the-air portion of the transmission to get back to the master radio. It will take 0.83 s to unload the data from the master radio to the host computer. In total, you have about 5.22 s per EFM to retrieve the data as shown in Figure 1.
Figure 1. Time required to poll an EFM
| Data Request Function | Time in seconds |
| Host makes request | 0.08 |
| Over the air | 0.20 |
| Slave gives request to EFM | 0.08 |
| EFM processes request | 3.00 |
| EFM responds to slave at 19.200 Kbps | 0.83 |
| Over the air | 0.20 |
| Master radio gives data to host | 0.83 |
| Total Time | 5.22 |
Today's newer, license-free digital radios can talk over the air at speeds anywhere from 115 Kbps to 1 Mbps. The great advantage of having a radio that talks so much faster than the port speed of the EFM is that you have a lot of open air time while the data is loaded from the EFM to the radio (Figure 2). This offers you such benefits as the ability to do real-time alarms in the middle of a polling cycle.
 Figure 2. The physical capability of the EFM to load the radio will likely be a limiting factor in how long it takes to poll the field |
The physical capability of the EFM to load the radio will likely be a limiting factor in how long it takes to poll the field. There are ways to speed up the system polling times.
Imagine the same scenario as above with 500 wells. The requirement is to poll each well every 30 min. The simple math says it can't be done: 5.22 s to poll each well multiplied by 500 wells is 45 min. to get a "Round Robin Poll" (once around the field). By using today's higher-speed Ethernet technology in conjunction with serial radios you can create a hybrid solution. This allows us to sub-divide the field and do multiple polls simultaneously. Since the Ethernet protocol allows you to have multiple conversations at the same time, you can send multiple data requests to the field. Each Ethernet radio has an IP address and therefore will only answer when that IP address is called. Many of the newer Ethernet radios have built-in terminal servers so even if your EFMs are not Ethernet-compatible, the radio acts as a protocol translator and bridges the communication barrier between serial and Ethernet.
Where legacy systems exist, a common way to accomplish this higher polling speed is to replace the existing repeater infrastructure with Ethernet radios. Plug your serial radio masters into the ports on the Ethernet repeater infrastructure radios (most of the commonly used Ethernet radios have two serial ports) and poll the serial EFMs in the field (Figure 3). By replacing the serial master and two serial repeaters you have reduced polling time by a factor of four. If you redo the math, you see that you now can poll all 500 wells in 11 minutes.
 Figure 3. By replacing serial repeaters with Ethernet repeaters, you can achieve higher polling speeds (Click image for larger version) |
It is possible to achieve even greater time savings by using more Ethernet repeaters and more serial masters. For instance, it used to take a user with 800 wells over an hour to poll the field. Now, after installing the Ethernet backbone with multiple serial masters, the user can poll that same field in five minutes.
The Ethernet backbone in this case has a baud rate of 867 Kbps, and the spread-spectrum radios talk over the air at 115.2 Kbps. Therefore, it is theoretically possible to have eight conversations at once (Figure 4).
 Figure 4. An Ethernet backbone used in conjunction with Ethernet repeaters and serial masters allows you to poll up to eight EFMs simultaneously (Click image for larger version) |
That scenario works if all of the EFMs are of the same type, but what happens when half the field EFMs are from one manufacturer and the other half is from a different manufacturer?
The beauty of Ethernet is that it is protocol-transparent as long as your SCADA software (polling host) supports multiple protocols. Most of the newer software packages use specialized drivers to support multiple protocols. The radios do not care what language the host uses, allowing the various EFM protocols to participate seamlessly in the same radio network. The radio acts like the Pony Express delivering the mail (i.e., data) regardless of the language in which it was written (i.e., protocol). The messages all go into the same pouch and are delivered to the right destinations. Similarly, the IP addresses and port addresses sort the messages back at the host and ensure that the right data gets to the right recipient.
For example, as Figure 3 illustrates, if all of the brand A EFMs are connected to port #1 on the Ethernet radio, they will have the correct address. And if all of the brand B EFMs are connected to port #2, they also will be routed to the proper destination.
Who Needs Access to the Data? If the answer is only one office, the system can be fairly simple. Any Ethernet or serial solution can retrieve the data and deliver it back to the host. In today's complex data-intensive world, more often than not, the data need to be distributed to multiple offices and multiple individuals within each of those offices. The only effective way to do this is by using a WAN. If the offices are connected by a WAN or VPN connection then everyone with network privileges can access the master radio through the WAN or VPN and therefore have access to the EFM network. Again, Ethernet gives us the ability to have multiple conversations at the same time, expanding our possible solutions.
Just as you can have multiple end devices (EFMs) that respond at the same time by using an IP address, you can have multiple masters polling at the same time using their IP addresses. Today's Ethernet radios and most of the newer spread-spectrum radios use digitally packetized protocols. In wireless Ethernet, each packet is surrounded with an IP addressing layer or IP wrapper, containing the address of the recipient. Thus, conversations are guaranteed to reach the proper destination and responses are routed back to the originator.
Summary
Combining technologies is becoming more common. Many users today are using Ethernet backbones (repeater networks) to leverage a combination of different technologies. Some users may use the dual-port Ethernet radios to bring both gas flow, and pump-off control back to a single host by means of a single radio system. Other users with older serial radio technologies are slowly migrating to the new, faster, more secure digital technologies or installing Ethernet to the wellhead. In either case, by combining these technologies with an Ethernet backbone, they can prolong the use of their existing system while creating a migration path for the future.
There are other hybrid solutions that we have not discussed in this article though many users consider them to be viable, depending on the system requirements and objectives. Some networks, for example, may use a combination of radio and satellite communications. Many oil and gas companies in remote and rugged terrain will install radio communication to a group of wells and then use satellite as the backhaul (instead of using an Ethernet backhaul of the type discussed in this article). This hybrid solution allows them to reduce their monthly operating cost by polling multiple wells through one satellite that has an "all you can eat" monthly bill rather than having multiple bills, one for each type of technology. Satellite charges of $100/month might be too high for a one-well solution, but if that charge can be spread over 10 wells it becomes insignificant.
ABOUT THE AUTHOR
Jim Gardner is a seasoned industry veteran in SCADA and data collection technologies and the oil and gas team leader for FreeWave Technologies Inc., Boulder, CO. Prior to joining FreeWave, Gardner was vice president at Remote Operating Systems. He currently is a member of ENTELEC, ASGMT and ISHM and can be reached at [email protected], 866-923-6168.