Data Model for Drilling Information and its Application
Authors: Pratt C. A. , Barazzutti Michael 
Published: December 2007

As computing technology has evolved, so have the user-community's demands on the functions the technology provides. Expectations of drilling-operations software are changing from convenience in producing the daily drilling report, to the actual acquisition of drilling data for use in engineering analysis programs. Users expect these data to provide insight into an increasing array of complicated engineering operations questions.

The industry uses a number of commercial, morning-reporting systems. After collecting many years worth of drilling data, however, engineers are finding that their morning-reporting systems cannot easily provide the answers to some very basic questions.

Many providers of drilling information systems build applications founded on daily wellsite operations and using the latest graphical user interfaces to ensure ease of use. The data model is usually an afterthought and is generally time- rather than activity-based. In some cases, the data model is used as a tool to further the system's "user-friendliness." This robs the application of its versatility in performing even some of the most fundamental analysis of the data.

To date, neither Petrotechnical Open Systems Corp. (POSC) nor the Public Petroleum Data Model (PPDM) have initiated studies to develop a drilling data model. We present a data model that was used as a basis for Shell Canada's (SCan) drilling information system.

Providing a sound data model that accurately reflects the fundamental data used by drilling (or other operations) is paramount to the success of any information system. Without it, the use of engineering operations analysis tools for optimization would be extremely difficult.

Problem: Drilling Reporting System

Historically, drilling reporting systems have been built to address the need to store electronically the information gathered during drilling operations. Some systems have been built to mirror the existing paper reports. These projects depended heavily on precise modeling of the manual data compilation processes and output generated by these processes.1-4 At least one system has been designed to gather technical and operational data from the drilling contractor's perspective.5 Other systems, designed for drilling information analysis, provide morning reports for management, end-of-well reports containing highlights and problems, and the final cost and performance data.6 Little attention was paid to the future usefulness of this data. These reports typically took a snapshot of the wellsite status at a fixed, arbitrary point in time (usually 12 a.m. or 7 a.m.).

At the other end of the spectrum are systems geared completely to capture voluminous numerical information. These electronic drilling recorders result in reams of data often difficult to navigate and maintain in a coherent model. The systems support on-going operations, but tend to fall down as analysis and planning tools.7,8 It must be possible to marry the needs of reporting the wellsite status with the desired empirical data to enable the assimilation of coherent drilling analysis.

Unfortunately, many of these systems fail to meet the data requirements that enable detailed engineering analysis necessary to optimize drilling operations. Shell is not the only company to realize that the numerous available software packages (in-house and purchased) cannot be interfaced easily to the corporate databases. Their database structures were designed primarily for reporting or management information systems, and the integration process was too complex and costly.9 As noted by Sawaryn & Grayson,9 the duplication of effort developing data models, structures, and systems interfaces has led to joint industry projects like POSC10,11 and PPDM.12,13

Although others have "concluded that (a drilling) database structure was not strategic,"9 industry groups like POSC, PPDM, Shell, and other operators14 might disagree. Shell Intl. Petroleum Mij.'s (SIPM) attempts at integrating various databases before the joint industry POSC project led to a formal effort to develop an E&P data model. This effort included a drilling systems model. This paper presents SCan's slightly modified version of the SIPM model so that others can use this work, critique the model, and either develop an industry standard or a commercial system that can be used by operators. With a common data model, the interfacing of various software tools and reporting between partners can be accomplished in a more efficient manner (electronically) as opposed to the current haphazard attempts.

The data model continues to be the fundamental flaw in the commercial systems that SCan has reviewed in the last 7 years. These systems have been report-based, as outlined earlier. They fulfill the requirements of the existing paper systems, but they do not allow new and creative data analysis. This is not because of poor programming or planning. What is required is a new approach to the way in which the data can be reviewed. Accurate analysis of multiwell trending, or even comparisons of bits through more than one formation, often with different drilling characteristics, cannot be captured using electronic means with these existing models.

Generally, computing systems fail to capture valuable operating information in a retrievable format. Experience and knowledge about how best to drill a well in a given area remains only in the minds of the current drilling team members. In our world of constant change, these individuals may not be present during the next season of drilling operations, resulting in the loss of continuity of information. Our experience has been that when the drilling engineer becomes aware of the analytical potential of the system, new and creative ideas are developed and tested against the available data. On the other hand, when attempts to query the database results in unusable data (because of its design), the engineer tends to blame failure on the existing suite of software, and creativity is stifled.

Solution: Drilling Information System

As stated earlier, SIPM developed a drilling systems data model. The SCan version of this drilling systems model is detailed in the appendices of the original paper.15 The major difference between this model and those used by other reporting systems that we investigated is the application of logical data-modeling techniques to design the framework for a relational database model. Consequently, this process highlighted the need to use a "drilling activity" rather than a reporting day as its basis. From the drilling engineers’ point of view, the concept of a drilling activity may not be a new one. However, this model introduces the concept that drilling activities center around a drill string run (DSR). The DSR provides the basic framework upon which operations of the drilling rig are centered. The date, time, and report number are only minor attributes of this DSR. A complete DSR is normally comprised of the following elements.

Tripping in, reaming, and drilling, with their associated depth-related parameters (weight on bit, rpm pump information, etc.). Events such as getting stuck or twisting off. Trip out with the handling of the bottomhole assembly (BHA) (changing the bottomhole assembly or just the bit).

Each DSR is sequential and unique. Although this seems simple and straightforward, some amount of drilling engineer education is required. On the rig floor, for example, when the string is pulled for an event such as a plugged nozzle in the bit and the identical BHA is run back in the hole, there is a tendency to reference the bit using the same bit number of the previous run, even if the nozzle sizes are changed! The drilling engineer has to understand that bit numbers in this example are numbers of convenience at the rig, and they are just additional attributes of this model's DSR. In the same way, a drill stem test (DST) has a significant amount of additional data attributed to it. Therefore, a DSR that includes a DST will have significant amounts of data associated with the DST. Other instances include casing runs, normally a special type of DSR, because the casing usually is not retrieved (tripped out). Wireline activities are also a special type of DSR because there is no pipe, but just like a trip with drillpipe, the wireline with its specific tools are run and data is recorded.

The original paper contains entity relationship diagrams and a vast majority of the data model table structures required to implement this DIS.15