SPE Standards Address the Challenges of Drilling Automation John Shields, SPE, Baker Hughes

Size: px

Start display at page:

Download "SPE Standards Address the Challenges of Drilling Automation John Shields, SPE, Baker Hughes"

August Manning
6 years ago
Views:

SPE 143936 Standards Address the Challenges of Drilling Automation John Shields, SPE, Baker Hughes Copyright 2011, Society of Petroleum Engineers This paper was prepared for presentation at the SPE

1 SPE Standards Address the Challenges of Drilling Automation John Shields, SPE, Baker Hughes Copyright 2011, Society of Petroleum Engineers This paper was prepared for presentation at the SPE Digital Energy Conference and Exhibition held in The Woodlands, Texas, USA, April This paper was selected for presentation by an SPE program committee following review of information contained in an abstract submitted by the author(s). Contents of the paper have not been reviewed by the Society of Petroleum Engineers and are subject to correction by the author(s). The material does not necessarily reflect any position of the Society of Petroleum Engineers, its officers, or members. Electronic reproduction, distribution, or storage of any part of this paper without the written consent of the Society of Petroleum Engineers is prohibited. Permission to reproduce in print is restricted to an abstract of not more than 300 words; illustrations may not be copied. The abstract must contain conspicuous acknowledgment of SPE copyright. Abstract Sophisticated applications are now available to analyze the drilling process and provide advice on the optimum operating parameters to drill safely, efficiently and to maximize wellbore productivity. The use of these applications requires a great deal of cooperation and collaboration between drilling contractors, service companies and operator personnel and systems. Data must be exchanged between rig instrumentation systems, other rig sensors operated by service companies, downhole measurement systems, analysis applications and control systems. This data exchange must occur reliably and efficiently between different hardware systems and operating platforms. Over the last few years a number of standards have emerged in the IT world, in industrial automation and in the oil industry. The use of these standards has the potential to bring in new levels of drilling automation capability. There are however some gaps and overlaps in the functionality and application of these different standards and an effort is required to bring these to the stage that they can be implemented and operated together efficiently. This paper provides an overview of the work performed so far in various areas of standardization and presents some recommendations and guidelines for future development and adoption of standards that will enable reliable interoperation of drilling automation systems components. Introduction Drilling wells in the 21 st century requires expertise from a number of different disciplines. The overall aim is to drill each well safely and efficiently into the optimum reservoir location. Most wells are directionally drilled and may be geo-steered. There may be issues with pore pressure, wellbore integrity, hole cleaning and drill string performance that need to be addressed in real time or within a few seconds of an even ocurring. Wells are often drilled using more dynamic technology than in the past with techniques such as managed pressure drilling. These require an additional level of real-time monitoring and analysis during the drilling process. Many different service providers at the wellsite generate data on different hardware and software systems. The rig instrumentation system may be composed of several different sub-systems for the top drive, fluids handling system, BOP, pipe handling etc. Each service company at the wellsite may have its own real-time analysis system that takes data from the rig instrumentation and generates calculated results or recommendations for modifications to the drilling parameters. Figure 1 shows the complexity of a modern drilling environment. There are a number of services running at the wellsite all generating raw or calculated data. Data may be aggregated at the wellsite then transferred via satellite, wireless or fibre communications links to shore based servers in local, regional or centralised locations and made available to real-time operations center (RTOC) personnel and applications. Real-time or near real-time applications can be run to analyse and advise about the drilling process. They can feed new data back into the system and this may be used in turn by other analysis applications. With modern network infrastructures, all of these activities could take place at the wellsite or they could be distributed between multiple locations. Any data sharing technologies used must be able to operate over local network and wide-area networks including remote access via the Internet.

2 2 SPE To enable increased automation in drilling, software will progressively take over from human decision making and from manual control of the hardware. In the automobile industry today, software routinely controls anti-lock braking, fuel injection and cruise control but we are still a long way from fully automated driving. Similarly modern drilling control systems incorporate microprocessor controlled soft-torque and similar systems to improve safety or drilling performance but these are typically implemented within the environment of the drilling control system and do not have to interface with external thirdparty systems. In order to enable interconnection of systems from different vendors, it will be necessary to have a robust, reliable data exchange mechanism between the various systems. This is where industry standards will help to define the content of and interfaces to the data that will be exchanged. The rest of this paper details some of the work that has been done to date and proposes some guidelines for future development of these standards. Oilfield Standards Oilfield standards have progressed along with advances in the IT industry. Early standards, from the 1970s and 1980s, were based around tape, disk and file formats and RS-232 serial data transmission. Later standards have embraced the changes in the industry and are now compatible with current network and Internet technologies. LIS (Log Interface Standard) LIS was originally created by Schlumberger in the 1970s as a standard format for the representation of well log data on digital tapes. It encodes data in binary format divided into logical and physical data blocks. It was widely adopted in the industry and is still able to be consumed by many current software systems DLIS (Digital Log Interchange Standard) DLIS extended the capabilities of LIS adding the capability for more complex data sets with additional parameter data and higher density data such as that generated from resistivity imaging or acoustic logging tools. It was originally published by the API as Recommended Practice 66 (RP66) in 1991 and subsequently passed on to POSC (now Energistics) for ongoing stewardship and maintenance. LAS (Log ASCII Standard) LAS was created by the Canadian WellLogging Society in 1990 as a simpler alternative to LIS and DLIS, recognizing the need for a format that could easily be transferred on floppy disks and manipulated on desktop personal computers. The simplicity of LAS has led to its wide adoption and it is probably the best supported standard today for the transfer of depth and time based well log data. WITS (Wellsite Information Transfer Specification) WITS was developed to address the transfer of real-time data from rigs to some of the early oil company data centres (Superior/Mobil, Amoco, Tenneco) in the 1980s. WITS defines 25 standard data records covering real-time rig sensor data, surface and downhole measurements, directional survey data, well and rig equipment and daily operational data. There are also spare data fields that can be used for limited local customization and custom data records may also be defined for specific uses. WITS has been a very successful standard and is still in widespread active use today. WITS defines multiple levels of data transfer, with increasing complexity, from simple uni-directional ASCII data transfer (level 0) up to bi-directional transfer of DLIS encoded data (level 4). The vast majority of cases where WITS has been implemented have used the simplest level 0 format. WITSML (Wellsite Information Transfer Standard Markup Language) In October 2000 Statoil, BP and major service companies launched the WITSML initiative as a web-friendly update and enhancement of the WITS technology. The main innovations of WITSML were: enhanced detail in the data objects to support more sophisticated applications all data objects contain units of measure information platform independence using XML to define the data objects an application programming interface (API) to access the datavia web services WITSML has encouraged the development of new service products such as aggregation servers that can collect data from multiple vendors at the wellsite and make it available through a common interface to analysis software from different vendors. WITSML is the core technology in many real-time operating centers that gather and analyze data from multiple service companies SPE Drilling Systems Automation Technical Section (DSATS) DSATS is a group within the SPE that is actively involved in identifying and recommending technology that will assist with

3 SPE drilling automation. This initiative has been active since 2008 and has held a number of working meetings at locations around the world. Work is continuing in DSATS via regular teleconference and web communication sessions. The OPC UA and WITSML standards described above have already been identified as potential components of the recommended solutions. Other Industry Standards Instrumentation and Control Standards Standards in the mainstream industries have evolved over the last 20 years in a similar way to those in the oil industry described above. Earlier serial interfaces for data collection and device control have now been replaced by a family of network standards that are collectively known as Fieldbus and are described in the 1999 international standard IEC These are applicable to lower level device interconnection and include a number of other compliant standards such as CAN, Modbus and PROFIBUS. Even though these low level standards are technically compliant with Fieldbus, they still do not typically interconnect due to differences in their data encodings and physical interconnections. In 1994, the OPC Foundation was formed to define a higher level specification that could bridge between the various technologies. OPC was originally defined as OLE for Process Control, using Microsoft Object Linking and Embedding (OLE) as the software interface to manufacturer-supplied drivers for specific instrumentation and control systems. OPC provides a number of separate interfaces to acces real-time data, access historical data, monitor alarms and events and to control devices. OPC has been very successful for the last 15 years. In 2006, the OPC Foundation released the OPC Unified Architecture (OPC UA) specification to provide a path from the Microsoft specific OLE specifications to a platform independent, webenabled, service-oriented architecture and also combine the various separate OPC specifications into a single entity. Information Technology Standards Over the last 20 years we have seen a huge change in the systems available to run technical software systems. We have progressed from hard-wired device connections to wide area networks and now to a variety of wireless communication technologies. Computer processing power has increased by orders of magnitude. We have gone from UNIX workstations to desktop and laptop personal computers and we are now at the start of a new wave of portable computing devices that run a variety of operating systems. The message from this is not to be dependent on any single operating system or software environment. We can however benefit from the wider standards that are in use within the IT industry, in particular those that are used for networking and Internet information transfer. The Internet Protocol Suite is the standard used by practically every system today and contains multiple layers that provide communication and data transport to different levels of hardware and software. The best known of these are TCP/IP which is the most common network transport layer (TCP) on top of the Internet Layer (IP). At the topmost level are the application layers: FTP for file transfer, SMTP for mail transfer and HTTP for web based data movement. Combining the Standards Figure 2 shows how the different standards can be used individually or together depending on the functionality and scope of the applications. True real-time control applications need sub-second response times to respond to changes in sensor values and to control safety equipment. These will probably be local applications that are run at the wellsite and will communicate using Fieldbus or OPC. Visualization systems can use OPC or OPC UA to pull together data from the rig floor, the pump room and third-party systems. Other applications may be implemented further up the stack using web technology, accepting that there is some inherent latency in the system due to the number of steps and geographical distance that the data has to traverse. A geosteering or drilling optimization application may only need to retrieve data at 5 or 10 second intervals to make its calculations. The existing established data file formats (LAS, LIS, DLIS, etc.) can be used to output data to any external applications or systems that are not tightly coupled with the automation process. Lessons Learned A number of lessons can be learned from observing the progress of various standards initiatives over the last 20 years. Keep It Simple The successful standards are the simple ones. WITS level 0 has been in constant use for over 20 years, despite its limitations, because it is easy to understand easy to implement. WITSML has been a success in the industry mainly because the WITSML objects are easy to process in any software environment. The least successful part of WITSML has been the query interface which offers a huge amount of flexibility. The downside to this flexibility is that it makes it very difficult to build a server that can respond in a predictable way to every conceivable implementation of the query templates. The end result of this is that WITSML servers tend to behave in slightly different ways and it is difficult to guarantee consistent behavior of client software

4 4 SPE when used with different servers. DLIS is a very comprehensive specification that allows data to be encoded in many different ways at different levels of complexity. This has led to a lot of problems with applications that can not support all of the different possibilities within the standard. Define Interfaces and Transfer Protocols, Not Data Stores Interfaces to store and load data should be defined using industry standards rather than platform specific standards. The interfaces to access data must be explicitly defined and not allow for unnecessary flexibility or differing interpretations. This ensures consistency of behavious and assists with testing and certification. An application using the interface should not need to know about the underlying data storage mechanism, just the data that are being transferred. Utilize Appropriate Domain Expertise To define a software standard takes a lot of work from knowledgeable people both in the IT domain and the application domain. Sometimes the quest for a powerful, flexible IT system can lead to a solution that is over-complex for a specific application domain. The WITSML API is an example of this in that it allows for complete flexibility for object queries but it is very difficult to implement in a real-life data server. Provide a Testing and Certification Environment A standard is only useful if it can be tested and certified. To support applications such as drilling automation we must have the confidence that information can pass efficiently and without loss of content or fidelity between applications. There must be easily available testing and certification resources that vendors can use to ensure that their products will work in compliance with the standard. OPC defines a multi-tier level of certification: self-tested compliance testing against a tool provided by OPC self-tested interoperability testing against products from other vendors at an organized interoperability event certification of client or server products at an independent test laboratory Provide Catalogs of Metadata There is a need for up to date catalog information that enables client software to be able to relate similar data from different vendors. An example is the naming of log curves from different vendors. A gamma ray curve may be called GR by one company and GRAX by another. An application needs to have additional metadata associated with the curve to know that it is a gamma ray measurement. POSC set up the Practical Well Log Standards (PWLS) in 2003 but it is in need of updating for many of the measurements that are now made by instrumentation systems and logging tools. In other data exchange formats there are elements which are text fields that are used to describe tool types. There is no guarantee that these will be consistent across different vendors. Any elements in data objects that define the type of a data object should refer to a catalog table that is associated with the standard. This mechanism is used within WITSML to give the ability to add new values to these elements without having to change the version of the underlying data schema. There are also more formal methodologies that have been defined by other industry standards bodies in this area. Other Related Issues Data exchange standards can enable technical applications to interoperate but there are other factors associated with the total system infrastructure that must also be addressed. Network Integrity If remote applications are being used in an RTOC or other remote office environment as part of real-time drilling operations, contingencies must be in place for loss of network connectivity. Security Security is an increasing issue and must also be addressed in the configuration of the network architecture for the drilling system. Appropriate security standards and policies must be applied in parallel to the technical standards for data exchange. Data Management When there are multiple parties involved in analyzing the drilling process, there must be clear roles and responsibilities for data management within the system. Applications that modify data must comply with procedures and policies Conclusions Technical standards for data definitions and transfer are available today and can be applied to enabling more automation in the drilling process. Initially this will involve better exchange of data between technical systems and applications and this can lead to increased accuracy and productivity. More work is needed on refining these standards for oilfield use to ensure guaranteed interoperability leading to higher levels of automation. This will involve the definition of more comprehensive metadata to refine the current standards models and the development of rigorous procedures to test and certify software systems for

5 SPE compliance to the standards. The ongoing development of these standards will require the dedication of time and skilled resources to initiatives such as SPE DSATS or WITSML to make it happen Fig. 1 Data Providers and Consumers Fig.2 Layered standards address Different time frames and levels of complexity

The changing role of WITSML and now ETP in managing drilling data.

The changing role of WITSML and now ETP in managing drilling data. Nigel Deeks SLB Australasia Real Time Manager / Woodside SDM With thanks to Jana Schey & Jay Hollingsworth Energistics A little about