Securely and efficiently connecting remote well sites for data and control

Production companies strive to continually improve by adopting new computing technologies to maximize operational efficiencies. One example underway for decades has been optimization using digital devices, computers and networking. Sensors and processors have also routinely been applied for monitoring and control to increase reliability, production and maintainability.

More recently, digital transformation has garnered much attention in the industrial and automation space. This term means many things and includes not only digitization, but also installing and interconnecting digital devices and systems, so companies can obtain large volumes of data and act on it. The difference now is that available devices are smarter than before, and interconnection options are greatly improved.

NICHE CHALLENGE

Despite these advances, pockets at the edge of traditional information and automation systems remain challenging to bring into the fold. These locations, like well sites and offshore platforms, are often remote and hard to access. This makes connecting them even more important, to save expense/time and improve safety, but it also makes monitoring tasks more difficult. Optimizing control locally at these sites is generally not the problem, but effective monitoring or initiation of control commands from a distance has often been too complex and expensive—and too vulnerable to hackers.

Edge devices are now available to address these and other issues, and they are well suited for this role. Packaged specifically for these difficult environments, edge programmable industrial controllers (EPICs) are ushering in new, efficient and secure methods for unlocking data streams at remote well sites, aided by open, standardized messaging protocols.

The primary benefit for operators is a significant reduction in expensive and unsecure middleware layers, achieved by employing modern methods of exchanging data with a central data broker. Data exchange with the broker can be with a remote site, a central monitoring location or any device capable of supporting modern data exchange protocols.

We will outline best practices when using edge devices for data collection, processing and transmission at the edge, where well sites and similar facilities are located.

DATA STEP CHANGE

The immediate benefit of centrally monitoring and supervising remote production assets, such as well sites, is clear. Users can see operating conditions and adjust parameters from a central location. Technicians travel to remote sites only when trouble is signaled and can’t be addressed by remote actions.

Less obvious but often just as important is the benefit of collecting and deeply analyzing large volumes of data from a fleet of similar assets. Instead of considering each site individually, numerous sites can be compared to reveal operational insights and trends otherwise impossible to discover. For example, previously undetected interactions between apparently unrelated process variables are often found. But this type of analysis can be successful only when data is obtained from multiple edge locations.

There are some legacy methods for gathering edge data, but they include many challenges. To solve these issues, options are now available to achieve digital transformation in a more robust and secure manner. Best practices for implementing these new edge devices include:

• Select a device with appropriate physical packaging and connections.
• Ensure it has the necessary edge-facing communications and processing abilities.
• Confirm it has the latest core-facing protocols and security features.
• Define the essential data to collect and transmit.

EDGE VS CORE

The operational “edge” is where digital systems contact the physical world through sensors and control devices. Classically, this physical connection has used either a distributed control system or a programmable logic controller (PLC). More remote locations have often used proprietary remote telemetry units (RTUs) with some remote communications capabilities.

Collectively, these systems are commonly called operations technology (OT) and are supported by personnel familiar with the processes and the specialized automation hardware and software. The edge can exist on a large user site, at one or more remote locations or at a combination of both.

In comparison to the edge, the “core” is one or more locations where a user’s central computing and networking assets and functions are housed. Generally located at main production facilities or offices, but sometimes in the cloud, the core is where industrial and business applications, data and services operate and interact. While these systems often run specific industrial software, they are usually the domain of an information technology (IT) group.

Relatively good infrastructure, such as power, networking and accessible workspaces are available and controlled by the user at core locations. However, complications arise away from the core site, where the edge is so far away that few or none of the core niceties are present. Not only is the edge a challenging physical environment, but programming and communication efforts must overcome outages and low bandwidth connections. Startup and maintenance efforts are complicated by the remote nature of the systems, often requiring personnel to travel to sites.

INTERCONNECTING EDGE AND CORE

For existing systems, users typically implement edge-to-core connectivity only where it is needed. Vendor-specific hardware and software often require custom configuration, and even standardized interfaces must be carefully organized and planned. Users are often forced to create complex, costly and difficult-to-maintain interfaces, with multiple points of cybersecurity vulnerability. A multi-step communication path from sensor, to RTU, to tag server, to PC, to gateway results, finally connecting to the cloud-based or on-premises application requiring the data, Fig. 1.

Fig. 1. Most existing systems connect edge to core via several complex and costly steps.

These multi-step configurations are difficult to create and usually perform only basic functionality with limited diagnostic or security features. This means they can be notoriously fragile in operation and correspondingly difficult to troubleshoot. The pain of establishing such connections means they are implemented only when absolutely necessary, so many times potentially valuable data remains orphaned in the field.

SHARPENING THE EDGE

Digital transformation is creating a growing need for more and better data, and the old way of making connections has become prohibitively expensive, unscalable and unsupportable. This widespread problem has prompted development of a new class of devices called edge programmable industrial controllers, or EPICs, Fig. 2.

Fig. 2. Edge computing devices and modern communication protocols deliver simpler, less costly and more secure connectivity.

These edge devices are the bridge between OT connectivity at the edge and IT systems at the core. They come in compact, industrial housings for surviving in the edge environment and are packed with powerful software for control, data connectivity and visualization.

By eliminating layers of middleware, these edge devices provide an efficient, simple and secure way to transmit edge data to a central data broker. Selecting and implementing the correct type of device, however, is key to producing useful data.

WHAT MAKES AN EDGE DEVICE?

Any edge device (Fig. 3) considered for well site service must be evaluated to ensure it has the necessary features and capabilities:

Fig. 3. Edge computing devices and modern communication protocols deliver connectivity that is simpler, more secure and manageable.

• Industrial packaging
• Agency approvals like UL hazardous locations and ATEX compliance
• Electrical and protocol connectivity to a wide range of field-side instruments and components
• Relatively simple installation
• On-board configuration capabilities
• Control and processing power
• Built-in security
• Standardized core-side IT-friendly protocols (MQTT and Sparkplug).

Industrial packaging is a must, even if the edge device will be in a relatively protected electrical enclosure. Remote sites are likely to experience extremes of temperature and intermittent power quality, and thus need to be rated to the appropriate standards for the environment.

Field-side connectivity at the edge can take many forms. Some edge devices only offer Ethernet ports, which may be adequate for more modern field devices. However, many legacy and brownfield field devices have only serial RS-232/485 connections, so the edge device needs to support these communications as well. Other digital communication protocols such as Modbus RTU and EtherNet/IP may be needed, so operators must ensure all the protocols used by their field devices are supported.

Some field signals are available only as classic hardwired analog or discrete input/output (I/O) points. An edge device must therefore have I/O modules for these types of interfaces, much as a PLC would. A wide variety of I/O signal options means fewer other interposing devices like relays and signal converters are needed. These I/O points need to be reliable and robust, and ideally the I/O modules would detect faults and be hot swappable for easy installation and servicing, even in tight areas.

Almost any advanced edge device is configurable via either a browser interface or dedicated software. Some devices also offer an on-board interface for performing basic diagnostics, commissioning, troubleshooting and human-machine interface (HMI) functions.

Edge devices differ from basic remote I/O hardware in two ways: control programming and advanced processing. Devices that use a variety of IEC 61131-3 compliant languages and other programming options can meet and exceed traditional PLC control capabilities. In addition, edge devices can perform more advanced processing on the raw incoming data, such as filtering and calculations, to deliver more compact and useful data to the core. This capability moves part of the data processing load out to the edge and reduces the upstream bandwidth consumption, keeping core systems more efficient.

Any edge device, especially if connecting via the internet, needs security built in to protect against intruders. Multiple Ethernet ports and a built-in firewall give users the option of employing a flexible network facing field devices, and a second, separate and secure network facing the internet.

Since edge devices are remotely located and accessible over network connections, they could be attractive targets for cyber attackers. Therefore, edge devices should include contemporary cybersecurity features like password-protected user accounts with assignable privileges, the option to create virtual private network (VPN) tunnels and native security certificate management to ensure system integrity. In particular, the ability to create VPNs without requiring IT involvement gives OT personnel the ability to manage these useful connections for troubleshooting and other remote access needs.

OT-facing communications are typically focused on performance and lack extensive security provisions. On the other hand, certain IT-facing protocols include excellent security. This is another reason to push edge devices out to the field as far as possible, minimizing the footprint of unsecure OT communications in favor of transporting data over more secure IT protocols.

Communications tough enough for the edge. For these reasons, the communications link from an OT-centric edge device to the IT-centric core systems deserves special consideration. Traditional edge-to-core communication approaches suffer many downsides.

One significant issue is the commonly used poll and response (poll-response) methodology, which requires direct physical connections and rigorous data tag mapping. Once in operation, it is inefficient, since all tags are blindly transferred all the time, even if they aren’t changing. Not only is the architecture complex, but it responds poorly with timeouts in the case of intermittent connections. These data links require close coordination with IT personnel, but they are fundamentally designed around always-on connectivity and high-bandwidth availability, which is the exact opposite of conditions available at the edge.

A major advancement in recent years addresses these issues. By using the widely adopted ISO standard MQTT transport protocol, along with the open-source Sparkplug data payload specification, edge devices can efficiently communicate with core-side systems over Ethernet, Wi-Fi, radio or cellular data networks, Fig. 4.

Fig. 4. Edge computing devices and modern communication protocols deliver simple and secure communications.

Combined, MQTT and Sparkplug provide lightweight report-by-exception data transmission, built to work over the type of tenuous networks that often connect the edge to the core. Users select just the data tags of interest for communications. MQTT uses publish-subscribe (pub-sub) methods to transmit these tags to a central broker, but only as each tag changes and updates its heartbeat signal, minimizing network traffic and server loading.

Using MQTT, client devices publish data to the central broker/server, subscribe to obtain data from the broker, or both. The broker can be on-premises at the user’s core or cloud-based. Clients can be edge devices, PCs, or software located anywhere, but each must have the proper security credentials.

A key feature of the pub-sub architecture is that all communications with the broker are device-originated, and once communication is established, data can flow in both directions. Since firewalls typically restrict unsolicited inbound communications, but allow outgoing connections, most firewall issues are avoided, IT involvement is minimized, and security is maintained.

MAKING THE EDGE SCALABLE

The right edge device equipped with MQTT/Sparkplug can be used to easily and efficiently connect one or more remote sites to a central core location, Fig. 5.

Fig. 5. Edge devices using MQTT/Sparkplug provide an efficient and secure way to connect multiple remote sites to a central core location via any type of available network.

Each site might consist of multiple brownfield devices and controllers. All of these can be integrated under one edge controller, which may even act as a local HMI. For new installations, the edge device can be used as the native controller for the area instead of a PLC, removing interface layers and reducing costs.

In turn, each edge controller uses the available network (Ethernet, Wi-Fi, radio, or cellular data) to securely publish configured data to one or more central MQTT brokers. The final link is when control room servers subscribe to the data of interest and use it for display, control, alarming, alerting, historizing and other functions. Users can interact with this data using PCs, mobile devices, mobile apps, web browsers or other dedicated applications.

CONCLUSION

End users will find today’s edge devices are purpose-built for this duty—offering better performance, security and maintainability than traditional approaches—especially in the conditions usually encountered at remote well sites. These edge devices and protocols provide an efficient and cost-effective way to adopt digital transformation concepts for existing installations and new systems. WO