IT, standards can help aggregate well data for high-level automation

Existing standards, networking advances may help drive interoperability on drilling operations

By Peter Morrison and John Shields, Baker Hughes

Oil and gas wells are drilled using equipment and services from multiple companies, but there is typically no overall systems integrator responsible for all components to interconnect and exchange information efficiently and unambiguously. Standards for oil industry information exchange have existed for many years, but they are, in many cases, inadequate to convey the detail required for automation of complex processes, such as real-time drilling control. Additional advances in this area could lead to a step-change in capability to automate the drilling process.

Safety

Drilling safety can be enhanced in several ways through automation of wellsite processes. For example, automation of mechanical processes enables fewer people to be involved in hazardous areas. Increased operational efficiency or remote control from an office-based real-time control center can reduce the need for people to travel to the wellsite. Pre-well planning, along with the ability to monitor the plan in real time and respond to deviations, can reduce risks of mechanical or pressure-related hazards.

Efficiency

Efficient drilling can be modeled by taking into account the geological properties of the rock formations to be drilled, the mechanical integrity of the formations, the wellbore and formation pressures to be encountered while drilling, and the dynamic behavior of the drill string. Application of these models in real time while drilling can be used to derive advisory and control information that can be applied to automate and improve the efficiency of the drilling process.

Well productivity

For a well to be productive, it must be drilled to the optimum reservoir location with minimum formation damage. Real-time geosteering requires active collaboration among the drilling, geology and reservoir disciplines. These disciplines may use various software applications that operate on different hardware in various locations, making it a significant challenge to exchange information efficiently during drilling.

The drilling contractor provides most of the mechanical equipment that is used to drill a well, including the drawworks, rotary table or top drive, and the mud circulating system. These devices and other rig equipment systems may be part of rig instrumentation and the control network. Some rigs have sophisticated pipe-handling systems that can be used to make connections and trip drill strings in and out of the wellbore. Some levels of “automation” may be realized entirely within the rig’s instrumentation and control system, responding to anomalous events with preprogrammed responses.

In addition, many subcontractors provide other services associated with drilling a well:

• The directional drilling service plans and steers the well to the desired target locations.

• The logging-while-drilling (LWD) service  provides real-time formation evaluation and mechanical measurements from downhole.

• Surface data logging and geology (mud logging) monitors the well for mud properties, gas and geology and provides services such as kick detection.

• Drilling fluids services maintain the drilling fluid to ensure adequate hole cleaning and formation control.

• Cementing and pumping contractors are responsible for specific activities, such as cementing casing or fracturing.

• Drilling engineers use software applications for well planning and monitoring to evaluate hydraulics, wellbore pressure, integrity and drillstring mechanical performance.

These service providers may not all be present for the duration of drilling a well, and service companies at the wellsite do not share a common location or computing environment. This means that it is often difficult to get the “big picture” of all of the factors that influence the drilling of the well. Ideally, we would like to take into account all of the interrelated factors that are involved with optimizing the drilling process.

There may be conflicts between the requirements of different optimization activities. Optimization of the drill rate, based on bit parameters and rock drillability, may lead to recommendations that would increase the incidence of drill string vibration. Increasing the mud flow rate to improve hole cleaning could have an adverse effect on downhole motor or LWD tool performance. There can be conflicts between the requirements of different services, which can be adequately resolved only when all information is brought into a common context to enable automation of the entire drilling process.

Manual data transfer between applications can lead to errors and delays in performing analyses that could assist the drilling process in real time. The rig contractor has the data that describe the rig equipment and the drill string, but these data normally have to be manually re-entered into applications that analyze BHA performance, hydraulics or torque and drag. There are multiple streams of real-time data generated by rig sensors and other data acquisition services, but there is no easy way to combine and share these data due to differences in data formatting and nomenclature.

There is an opportunity for the creation of a wellsite data aggregation system that can be accessed by all parties to facilitate efficient data sharing. This would require the creation of a common system and data view of the drilling process that could be mapped to the specific details of the data and application providers.

There are always barriers to the introduction of new technology. Companies have invested a large amount of time and money to develop their proprietary solutions and are often reluctant to change unless they can see a clear benefit. Change can be mandated through contracts but can also be achieved through providing new business opportunities.

There is an evolving role for a data aggregator service that provides a software platform that can help to link many of the analysis applications described earlier. The emergence of the WITSML data transfer standard over the past 10 years has provided building blocks to enable software application integration. It has also created opportunities for new companies to provide services centered on data aggregation and sharing. WITSML in itself is not sufficient to enable drilling automation. Work remains to be done on classification and identification of real-time data values and in connectivity to instrumentation and control systems.

The SPE Drilling Systems Automation Technical Section (DSATS) and the IADC Drilling Control Systems Subcommittee are also working in similar areas, focusing on interoperability and automation of drilling control systems that leverage the OPC-UA interoperability standard.

If systems are to work together, they must be able to identify each other and their capabilities. It is possible for many devices to communicate through wireless and Bluetooth technologies. Phones can be connected to cars, and cameras can be connected to tablet computers through services that are discoverable and self-describing. Similar technology could be used at the wellsite to connect new services as they arrive at different points during the drilling process.

Security is a major concern when accessing sensitive well data or allowing access to the control of hardware, but there are many ways in which security may be implemented through combinations of software and hardware techniques.

For control of drilling systems, the speed of response and reaction to changing events and conditions is important. Web services may be adequate for monitoring some operations, but rapid response to mechanical events may require more direct connection to control hardware using lower-level protocols, such as OPC.

Identification of specific types of data is still a problem in the drilling domain. Using a WITSML data server, it is possible to access real-time drilling data from a wellsite service company, but there is no way to unambiguously identify which data item is the hookload or the weight on bit. This information must be supplied via additional meta-data or documentation that is exchanged between the participating companies. Further work is needed in this area to define ways to classify data measurements so that they can be identified between systems.

Many standards are already defined in the oil industry and the IT domain, and they can be used at various levels to enable interconnectivity and data exchange

IT standards

There is a rich set of well-established standards in the IT industry enabling applications to transfer data via local network connections, wide-area networks or the internet.

• TCP/IP for basic networking connectivity enables low-level data connectivity between applications.

• Web services via HTTP, REST and SOAP enable interconnection between local and remote systems running in different environments, e.g., Windows desktop computers and Android tablets.

• Data formats, such as XML or JSON, allow the transfer of data with a known structure.

• Message bus standards (a combination of common data model, common command set and messaging infrastructure, such as JMS, WCF, AMQP, etc) can be used to provide timely and reliable delivery of data between applications via multiple mechanisms, such as point-to-point or publish-subscribe.

Industry automation and data standards

Many industries need to be able to connect together sensors and controllers from different vendors to manage or automate the use of hardware devices. Several interconnectivity standards have emerged over the years and evolved in line with technology in IT and networking.

• Field bus low-level network connectivity provides the basic level of interconnection between instrumentation components. There are still several competing standards in this domain, including PROFIBUS, CAN and Modbus.

• OPC-UA provides extra layers of security and capability for interoperability between system components, including publish/subscribe, historical data access and alarms/events.

• DDS data bus (object management group or OMG standard): DDS specifies a shared data bus that can be accessed from embedded and desktop computer systems.

Oil industry standards

Numerous standards have been defined within the oil industry over the past 20-plus years. Most of them relate to a specific domain, such as drilling, production or geophysics. Oil industry standards that are most applicable to drilling automation include:

• WITS (RS-232 serial and TCP/IP). Many companies today are exchanging data at the wellsite using the WITS data transfer protocol that has remained unchanged for more than 20 years. WITS is still popular due to the simplicity of programming its low-level ASCII data format.

• WITSML was originally defined by a working group of oil and service companies in 2000 and describes data objects in the drilling domain as XML documents. These may be generated or consumed using almost all modern programming environments. WITSML objects provide sufficient technical information to drive sophisticated drilling engineering analysis applications. The standard also defines an application programming interface (API) that specifies how to make queries that can add, update, load or delete data from a WITSML server. PRODML and RESQML are companion standards that cover the data objects used in the production and reservoir domains.

• LIS, DLIS, LAS. Standards for exchange of depth- and time-based well log data. LIS and DLIS are binary formats; LAS defines an ASCII format; and DLIS is the implementation of API RP66.

• PPDM (public petroleum data model) defines a data storage model for well and reservoir data that can be implemented on relational databases.

• PIDX (petroleum industry data exchange) defines standards for oil industry applications to exchange business data.

• OpenSpirit provides a set of middleware libraries that enable applications to access data from multiple commercial and industry standard data stores. It is mainly focused on the geophysical community and was originally developed by a consortium of oil companies and oil industry software companies.

The use of these IT and oil industry standards enables the aggregation of drilling, engineering and geological data into a common environment for new levels of integrated analysis.

Drilling automation is starting to happen, and many commercial products are available to automate various aspects of the drilling process. Most of these still live within the low-level rig instrumentation and control environment. The next generation of automation applications will take a more complete view of the drilling process and factor in higher levels of analysis that can account for many more environmental and mechanical factors that affect drilling efficiency and safety. This will require greater levels of interoperability between applications and processes using newer technology from the IT and oil industry standard organizations.

Recent developments in the industry are driving things in the right direction. In 2012, the Standards Leadership Council was formed and brought together representatives from several oil industry standards bodies to identify opportunities for their standards to work together more efficiently. DSATS is engaged in a detailed study of the drilling process that should yield a more formalized view of the activities that make up the drilling process. This approach will help to identify the specific areas where more work is needed to define standards for interoperability and data exchange.

Figure 2 illustrates how these concepts might come together to provide platforms for deployment of different levels of automation and analysis services. The use of an OPC-UA server for aggregation of raw data sources provides an initial location where applications could be run to perform real-time analysis or automation tasks. This location is most suited to real-time applications that can run with raw data inputs and do not need access to additional context data from other databases and applications.

Integration of more sophisticated cross-domain applications requires an environment where there is access to more complex data structures and to information that may be derived from multiple applications running on desktop operating systems. In this case, a higher-level data aggregation system may be more appropriate. In Figure 2, this is shown as WITSML but other data/message bus and data transfer technologies as described above could also be used in this area.