Challenges of offshore oil and gas production
Working in more extreme environments is driving improvements in networking, and standards development for subsea automation systems. Sophisticated equipment on the sea floor has to communicate topside.
Global demand for hydrocarbon energy continues to drive production, particularly among new assets in offshore reservoirs. Deepwater and ultra-deepwater oil and gas production began in the early 1990s, reaching approximately 1.5 million barrels per day (BPD) in 2000, and now exceeds 7.2 million barrels of oil equivalent per day (BOED).
The increase in deepwater hydrocarbon production has placed significant demands on offshore platforms’ and vessels’ automation systems. These demands most frequently affect how these various automation systems are used to improve and increase deepwater production, particularly how those systems interface with one another.
A deepwater production platform generally operates several different automation systems:
- Topside distributed control system (DCS), which manages the separation and stabilization of production fluids by separating crude oil from water and gas. The water is treated and reinjected, while the gas is used for onboard fuel, transported to shore by pipeline, reinjected, or flared. Depending on vessel type, stabilized crude may be stored onboard for transfer to a tanker or sent by pipeline to another destination. In addition, the DCS provides the main human-machine interface (HMI) functions for the entire vessel.
- Master (or marine) control system (MCS), which operates the subsea wellhead, manifolds, chemical injectors, and other underwater equipment. It is normally divided into two parts: wet controls, which are housed on the subsea equipment, and dry controls, which are located in the production vessel.
- Hull systems, which are a collection of control functions, such as ballast management, storage tank management and cleaning, and the like.
- Hotel systems, which manage everything associated with supporting the crew, such as HVAC, water and waste water, food preparation, communications, and entertainment.
Focusing on the ways the interface between the MCS and DCS is evolving can illustrate what is changing offshore automation systems and how deepwater crews can overcome potential challenges.
Safety concerns are continuing to grow in importance. This is driving the need for increased safety-rated interlocks and additional monitoring of subsea wellheads, manifolds, and other equipment. But as technology and exploration methods have advanced, other issues have also evolved. For example, larger and more complex fields require far more measurements, controllers, and actuators on the sea floor. Also, because subsea processing technology and economics are improving, it is often cost effective to handle unit operations, such as separation, water reinjection, and gas reinjection, at the mud line, rather than transport production fluids topside for processing and then send them back down for reinjection. These changes mean that more sophisticated control strategies are needed at the sea floor.
Another change is that subsea tiebacks—basically, multiphase pipelines on the sea bed—are now frequently being used to extend the life of existing production platforms. Rather than place a new platform over a new asset area, a subsea tieback is used to connect the new field to an existing but underutilized production platform. These solutions require extending control networks for several hundred miles and controlling complex multiphase pumping systems.
Reducing cost and risk is, of course, always a factor. Automation systems and their interfaces are almost always on the critical path to first oil, so reducing risk through standardization and advanced programming techniques like object oriented programming is key. In addition, since the MCS and the DCS are generally supplied by different vendors, minimizing finger-pointing is important.
Finally, using multiple vendors and vendor independence requires a viable open-source support organization for wide-ranging adoption and long-term viability. The days of proprietary industrial networking protocols are largely behind us. Industrial users, like IT and even consumer users, want protocols that have wide support among industrial suppliers and an extensive range of off-the-shelf products available.
With these facts in mind, it is easy to see how the need for continued safety improvements and the growing complexity of offshore deepwater hydrocarbon production facilities has necessitated more robust, faster, more open, and more maintainable communication between topside and seabed automation systems. As this continues to develop, two protocol standards have emerged as likely candidates.
Traditionally, the de facto standard for communication between the MCS and DCS is the Modbus, which was developed in the 1970s as a communication standard between programmable logic controllers. As such, it is essentially a register-to-register mapping facility with a limited number of data types available. It does not have any object management capability, meaning the data type and range synchronization must be handled explicitly by MCS and DCS programmers. It is also a polled architecture, which means that devices cannot report by exception. In addition, it is limited to 247 devices per net. Finally, there are numerous variants, such as Modbus TCP/IP, Modbus over TCP/IP, Modbus Plus, and Enron Modbus, all with different internal structures and requirements.
These limitations have pushed oil companies, subsea equipment vendors, and automation suppliers to seek a better solution for MCS to DCS interfacing. Two main candidates are leading the effort to unseat Modbus: EtherNet/IP and OPC UA. Ethernet Industrial Protocol (EtherNet/IP) was originally developed by Rockwell Automation but is now managed by the Open DeviceNet Vendors Association (ODVA). OPC Unified Architecture (OPC-UA) is managed by the OPC Foundation.
EtherNet/IP was developed in the late 1990s by Rockwell Automation as an implementation of the company’s Common Industrial Protocol (CIP) over a TCP/IP network. In that sense, it is similar to DeviceNet and ControlNet, which implement CIP over vehicle and dedicated networks, respectively. All three of these protocols are now managed by ODVA.
EtherNet/IP uses a datagram structure to transmit basic I/O data and explicit messaging via TCP for transfers of parameters, setpoints, and so on. It supports remote procedure call structures for report-by-exception. While the datagram structure allows some object orientation for standard I/O transfers, other activities require more detailed coding.
A plus is the CIP safety layer, which implements a certified safety integrity level 3 (SIL 3) under the IEC 61508 standard.
EtherNet/IP is widely implemented and supported in the lower levels of the automation hierarchy, typically between the field-to-control and control-to-operations levels. It has also been used for peer-to-peer communications within the field and control layers, but has not been widely accepted for peer-to-peer interfacing at the operations level.
OPC-UA was introduced in 2006 to overcome limitations of previous OPC versions. Among significant changes were multiplatform support (ANSI C, Java, .Net, as well as the original Microsoft Windows); a built-in information model with a node or object-oriented programming capability; dual direction interrupt capability to support report-by-exception and heartbeat monitoring; and large system support capability. Two protocol levels are supported: a high-performance binary protocol suitable for embedded devices and a web service protocol for general use. The information model isolates user applications from the underlying protocol, and an interoperability certification program is available through the OPC Foundation.
On the downside, while OPC-UA supports redundancy, it does not support SIL communications within the protocol. It also has a higher communications overhead requirement when compared to EtherNet/IP.
In recent months, OPC-UA has gotten a lot of attention from major automation suppliers, including ABB, Yokogawa, and even Rockwell, who have announced support and implementation roadmaps for OPC-UA as an enterprise- and operations-level integration protocol. However, Invensys and Siemens have gone further, indicating plans to use embedded OPC-UA technology to extend the protocol to the control and field levels.
In conclusion, the ODVA’s EtherNet/IP protocol is well proven at the lower levels of the control hierarchy, but has not been widely adopted at the operations and enterprise levels. It also does not support robust, easy-to-use object management programming tools, but it does have a SIL 3-rated version.
On the other hand, OPC-UA from the OPC Foundation has been widely accepted in the automation industry at the upper levels of the automation hierarchy and has been recently proposed as a communications protocol spanning the field and enterprise levels. Further, it fully supports object programming techniques and has a robust interoperability certification program.
Which is better? That’s a good question, and you can participate in determining the answer. Standardization efforts are underway, and recommended standards should emerge in 2013. If you want to take part in the conversation, please consider joining the MCS-DCS Interface Standardization network. The group’s website describes its purpose: “To streamline the MCS and DCS communications on topside systems, a standard interface needs to be developed, including a standard communication protocol. The MCS-DCS Interface Standardization (MDIS) network has formed with involvement from key industry players in the subsea controls area, topsides specialists, and oil companies. Standardization of the interface simplifies implementation of data communication links, whilst increasing the data quality. Using the network group as a collaborative resource to the industry, it is able to facilitate information exchange in furthering development of the standard MCS-DCS interface.”
John M. Gilmore, Jr., is director of upstream oil and gas industry solutions for Invensys Operations Management.
- Offshore energy production is growing in volume and complexity.
- With more equipment on the sea floor, communication up and down is also growing in volume and complexity.
- Traditional networking methods are being overtaxed, and an industry organization is formulating a standard for a new approach.
Find out more and even join the MCS-DCS Interface Standardization network: http://www.mdis-network.com
Learn more about Invensys Operations Management: http://iom.invensys.com
Case Study Database
Get more exposure for your case study by uploading it to the Consulting-Specifying Engineer case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.