US20170122095A1

US20170122095A1 - Automated geo-target and geo-hazard notifications for drilling systems

Info

Publication number: US20170122095A1
Application number: US15/343,007
Authority: US
Inventors: Peter W. Flanagan
Original assignee: Ubiterra Corp
Current assignee: Ubiterra Corp
Priority date: 2015-11-03
Filing date: 2016-11-03
Publication date: 2017-05-04

Abstract

A drilling management system can monitor the traversed path of a drill bit throughout active drilling at a drilling site and notify appropriate team members regarding a current status of the active drilling in real-time. For example, the drilling management system can notify team members when predetermined milestones have been met, when the drill bit is drifting off course from a target wellbore trajectory from a target horizon or target zone, or when the drill bit is in danger of running into a geo-hazard, such as a pre-existing wellbore, unpierced fault plane, lease boundary, etc. The drilling management system can maintain a depth model of the drilling site that identifies the target wellbore trajectory, a target zone based on one or more horizons from the depth model, and coordinates of known geo-hazards at the drilling sites. The drilling management system can also maintain a set of rules for each of the drilling sites that indicates when team members should be notified.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims priority under 35 U.S.C. §119(e) to provisional application No. 62/250,256 titled “Shared Visualization with Automated Depth Model Based Notifications for Drilling Systems Utilizing 3D Seismic Data,” filed on Nov. 3, 2015, and claims priority under 35 U.S.C. §119(e) to provisional application No. 62/376,256 titled “Automated Geo-Target and Geo-Hazard Notifications for Drilling Systems,” filed on Aug. 17, 2016, which are hereby incorporated by reference herein.

TECHNICAL FIELD

The present technology pertains to drilling systems, and more specifically pertains to automated geo-target and geo-hazard notifications for drilling systems.

BACKGROUND

An oil company asset team must work to together to ensure the efficient drilling and completion of an oil and gas well. During the years 2005 through 2016, the drilling of horizontal wells in shale formations became a very important new regime of operations for the oil industry. This new regime requires a “factory floor” mindset whereby activities become repetitive and must be repeatable in order to ensure optimal outcomes from an economic perspective.
In order to drill a successful horizontal well, a cross-functional team (a.k.a. “asset team”) comprised of engineers, geoscientists, regulatory, financial specialists, managers, and third party service providers, such as the drilling contractor and mud-logger, must work together. The asset team must collaborate to plan the well, execute the drilling plan, avoid geo-hazards, and stay on an optimal drilling track and on the drilling plan. This is challenging since the drilling target geologic horizon will typically be 2 miles underground and located in a remote field area.
An increasingly important tool for improving the success of these horizontal shale drilling projects is 3-dimensional seismic data (3D seismic). Many oil and gas companies will acquire a 3D seismic survey that is an image of the subsurface region within which they intend to drill. This seismic survey will be calibrated to existing well control and converted into depth (meaning the z-axis of the seismic volume will readout in depth below the surface). The target horizon (and potentially additional reference horizons) along which the horizontal well will be drilled is identified within the seismic volume, along with potential hazards, which primarily will be geologic faults that intersect the target horizon, but which will also include preexisting wellbores within the vicinity. In addition, mineral lease ownership information could be included in the depth model. Also, the depth model typically includes a planned drilling wellbore trajectory. This information is collectively referred to as the “Depth Model.”
As the drilling of the well proceeds, the location of the drill bit using measurement while drilling (MWD) information can be transmitted on a periodic (15 minute or other interval), real-time basis to the oil company. Not uncommonly, an asset team member (typically a geoscientist) will be assigned to manually update a set of project information on an at least a once daily basis and generate a report—the project contains the seismic volume, the depth model including geo-hazards, and the path of the well being drilled. This report is then distributed manually to the other asset team members to help the asset team work together. Regardless, the process is labor intensive, not typically real-time, the information is difficult to distribute and coordinate particularly from remote locations where team members are remote from the drilling operations, among numerous other challenges and deficiencies.

SUMMARY

Additional features and advantages of the disclosure will be set forth in the description which follows, and in part will be obvious from the description, or can be learned by practice of the herein disclosed principles. The features and advantages of the disclosure can be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the disclosure will become more fully apparent from the following description and appended claims, or can be learned by the practice of the principles set forth herein.
Disclosed are systems, methods, and non-transitory computer-readable storage media for automated geo-target and geo-hazard notifications for drilling systems. A drilling management system can monitor the traversed path of a drill bit throughout active drilling at a drilling site and notify appropriate team members regarding a current status of the active drilling in real-time. For example, the drilling management system can notify team members when predetermined milestones have been met, when the drill bit is drifting off course from a target wellbore trajectory or target horizon, or deviating from a zone when the drill bit is in danger of running into a geo-hazard, such as a pre-existing wellbore, unpierced fault plane, lease boundary, etc. The drilling management system can maintain a depth model of the drilling site that identifies the target wellbore trajectory and coordinates of known geo-hazards at the drilling sites. The drilling management system can also maintain a set of rules for each of the drilling sites that indicates when team members should be notified.
While an active drilling is in progress at a drilling site, the drilling management system can receive a drilling data stream from the drilling site that includes coordinate data describing a traversed path of a drill bit. The drilling management system can determine, based on the coordinate data and the depth model of the drilling site, whether a rule has been triggered indicating that one or more team members should be notified regarding the status of the active drilling. In response to determining that the rule has been triggered, the drilling management system can identify a set of team members that should be notified, and transmit a notification to the team members that the rule has been triggered.

BRIEF DESCRIPTION OF THE DRAWINGS

The above-recited and other advantages and features of the disclosure will become apparent by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only exemplary embodiments of the disclosure and are not therefore to be considered to be limiting of its scope, the principles herein are described and explained with additional specificity and detail through the use of the accompanying drawings in which:

FIG. 1 illustrates an exemplary system for automated geo-target and geo-hazard notifications for drilling systems;

FIG. 2 illustrates an exemplary system embodiment of a drilling management system;

FIG. 3 illustrates an example method of automated geo-target and geo-hazard notifications for drilling systems; and

FIGS. 4A-4D illustrate exemplary visualizations of an active drill; and

FIGS. 5A and 5B illustrate exemplary possible system embodiments.

DESCRIPTION

Various embodiments of the disclosure are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations may be used without parting from the spirit and scope of the disclosure.
The disclosed technology addresses the need in the art for automated geo-target and geo-hazard notifications for drilling systems. A drilling management system can monitor the traversed path of a drill bit throughout active drilling at a drilling site and notify appropriate team members regarding a status of active drilling, and the current status may be configured to be monitored in real-time. As used herein, the term real-time recognizes that there are various steps and operations that occur prior to the system receiving information about the location of the drill bit and progression of the wellbore, and the system may be configured to monitor the system based on the most current drill bit information and may be configured to provide notifications on some schedule. For example, some time may pass between transmission of drill bit information from the well to the system and hence the term real-time recognizes some time may pass between when the drill bit reaches some location and when the system obtains the information as to the current location of the drill bit, and hence the term real-time captures near real-time values (e.g., while drilling and within 10 minutes of the drill bit reaching some point in the drilling operation). With respect to notification, for example, the drilling management system can notify team members when predetermined milestones have been met, when the drill bit is drifting off course from a target wellbore trajectory and/or target horizon, or when the drill bit is in danger of running into a geo-hazard, such as a pre-existing wellbore, unpierced fault plane, lease boundary, etc. The drilling management system can maintain a depth model of the drilling site that identifies the target wellbore trajectory and coordinates of known geo-hazards at the drilling sites. The drilling management system can also maintain a set of rules for each of the drilling sites that indicate when team members should be notified. The information may be processed and notifications transmitted in real-time.
While an active drill is in progress at a drilling site, the drilling management system can receive a drilling data stream (e.g., a stream of data generated from MWD data captured from an MWD tool) from the drilling site that includes coordinate data describing a traversed path of a drill bit. The drilling management system can determine, based on the coordinate data and the depth model of the drilling site, whether a rule has been triggered indicating that one or more team members should be notified regarding the status of the active drill. In response to determining that the rule has been triggered, the drilling management system can identify a set of team members that should be notified, and transmit a notification to the team members that the rule has been triggered.
FIG. 1 illustrates an exemplary system for automated geo-target and geo-hazard notifications for drilling systems. As illustrated, multiple computing devices can be connected to a communication network 104 and be configured to communicate with each other through use of the communication network 104. The communication network 104 can be any type of network, including a local area network (“LAN”), such as an intranet, a wide area network (“WAN”), such as the Internet, or any combination thereof. Further, the communication network 104 can be a public network, a private network, or a combination thereof. The communication network 104 can also be implemented using any number of communication links associated with one or more service providers, including one or more wired communication links, one or more wireless communication links, or any combination thereof, and may support the transmission of data formatted using any number of protocols, as well as different protocols as data traverses the various paths between devices.
A computing device, which may be involved in obtaining and transmitting drilling information, the drilling management system, and the client devices, can be any type of general computing device capable of network communication with other computing devices. For example, a computing device can be a personal computing device such as a desktop or workstation, a business server, or a portable computing device, such as a laptop, smart phone, or a tablet PC. A computing device can include some or all of the features, components, and peripherals of computing device 500 of FIGS. 5A and 5B.
To facilitate communication with other computing devices, a computing device can also include a communication interface configured to receive a communication, such as a request, data, etc., from another computing device in network communication with the computing device and pass the communication along to an appropriate module running on the computing device. The communication interface can also be configured to send a communication to another computing device in network communication with the computing device.
As shown, the overall system 100 includes a drilling management system 102, drilling sites 106 ₁, 106 ₂, . . . , 106 _n(collectively “106”), and more particularly computing devices at the sites, and client devices 108 ₁, 108 ₂, . . . , 108 _n(collectively “108”). The drilling management system 102 can be comprised of one or more computing devices configured to monitor the traversed path of a drill bit throughout active drilling at any drilling sites 106, through receiving drilling information, and communicate with various client devices 108 to notify associated team members regarding the status of active drilling at the drilling sites 106 in real-time.
The drilling sites 106 can be physical drilling sites equipped with drilling machinery, and accompanying sensors and computing devices, such as an MWD component associated with a drill bit, configured to gather drilling data describing the status of an active drilling operation at a drilling site 106. For example, the drilling data, in the form of MWD data, may be delivered in the form of sets of Azimuth (inclination from North), Inclination (dip in degrees), and MD (measured length along wellbore). The data may be converted to X, Y, Z axis values using any industry standard conversion. The conversion may occur prior to the drilling data being transmitted (e.g., the drilling stream) to the drilling management system. Hence, the drilling data can include coordinate data, such as an X axis value, Y axis value and Z axis value, describing the location of a drill bit as the drill traverses through the ground during the active drill. Systems at the drilling sites 106 can gather and transmit this drilling data to drilling management system 102 as part of a drilling data stream. For example, drilling sites 106 can gather and transmit drilling data to drilling management system 102 every 10 seconds, 30 second, 1 minute, 5 minutes, etc. In one specific example, MWD drill bit positional data is collected by an MWD tool associated with the drill string and typically positioned behind the drill bit. As introduced above, the MWD tool measures azimuth, inclination, and length along the well drilling string in real-time. The tool transmits the data to the surface using “mud pulses”—digital pulses sent through drilling fluid, in the wellbore, to the surface where the pulses are encoded with positional data as well as other information. A transducer at the surface converts these pulses back into digital information on a network on the drilling rig. The MWD data may be then be translated to X,Y,Z values at a local computing device and transmitted, such as form a private web server at the drilling site, to the drilling management system using the WITSML protocol.
In addition to coordinate data describing the location of a drill bit, drilling data can also include additional data describing an active drill. For example, the drilling data can include identifying data, such as a unique identifier identifying the originating drilling site 106, identifiers of equipment used for drilling, such as the drill bit, sensors, computing devices, etc. The drilling data can also include time stamp values indicating the time at which coordinate values for an active drill were recorded. Drilling data can also include other sensor readings or data gathered during the active drill, such as sensor readings describing traversed soil densities, drill bit pressures, drill bit performance, etc. The drilling data may also include logging while drilling (LWD) data including gamma ray log information. The log records the intensity of naturally occurring gamma radiation from rock.
The drilling management system 102 can receive drilling data streams from one or more of the drilling sites 106 and analyze the drilling data to determine whether team members associated with the active drill should be notified regarding the status of the active drill. For example, the drilling management system 102 can notify team members when predetermined milestones have been met, when the drill bit is drifting off course from a target wellbore trajectory or when the drill bit is in danger of running into a geo-hazard, such as a pre-existing wellbore, unpierced fault plane, lease boundary, etc.
To accomplish this, the drilling management system 102 can access a depth model for the area being drilled at each drilling site 106. The depth model may identify the target wellbore trajectory for the drilling site 106, coordinates of known geo-hazards, target horizons, and other features. Generally speaking, the depth model is derived from the seismic data for the area to be drilled at the drilling site. Typically, seismic interpretation programs are used to digitize X, Y, Z coordinate data for a set of seismic data. The digitized coordinates may further represent and constitute 3D dimensional surfaces associated with the seismic data. Likewise, features identified within the seismic data may be digitized into unique three dimensional surfaces to form part of the depth model. For example, geologic faults, hazards, target horizons or boundaries and the like may be digitized into three dimensional surfaces representative of the respective features.
Each data type (the seismic data and the derived horizon and fault surfaces) and the well data (the MWD and LWD information) has its own elevation datum). To align the various data sets used for comparison purposes and to trigger notifications, and the like, the elevation datum may be reconciled if necessary. For example, if the seismic data used to generate the seismic cube has a datum elevation of 5200 ft above sea level, and the drilling data has a datum elevation of 5250 feet above sea level, the depths between the two sets of data can be reconciled by adding 50 ft to the seismic data. The depth model may be based on seismic data for the area being drilled, and may be arranged in a cube with x (e.g., inline), y (e.g., crossline) and/or z (e.g., time or depth) aspects of the cube.
The drilling management system 102 can also maintain a set of rules for each drilling site 106 that indicates when team members for the drilling site 106 should be notified regarding the status of the active drill. For example, the rules can identify milestones that, when met, should be reported to specified team members. As another example, the rules can identify threshold distances from the target wellbore trajectory, the target horizons, and/or geo-hazards that, when met or exceeded, are reported to a specified team member or members. The drilling management system 102 can use the drilling data received from a drilling site 106, along with the corresponding depth model and set of rules, to determine when a rule has been triggered and team members should be notified regarding the status of the active drilling operation.
The drilling management system 102 can notify team members via client devices 108. Client devices 108 can be any type of computing devices, such as a smart phones, laptop computers, desktop computers, tablets, etc. Drilling management system 102 can maintain records of client devices 108 associated with team members, including contact information to reach team members via one or more of client devices 108. In response to determining that a team member should be notified, drilling management system 102 can identify the team members contact information and transmit a notification to the user, which can be received by the user at one or more of client devices 108. For example, drilling management system 102 can transmit the notification as an e-mail, text message, phone call, instant message, etc.
Drilling management system 102 can also provide team members with a visualization of an active drill. For example, drilling management system 102 may use techniques such as those described in U.S. Pat. No. 9,182,913 titled “Apparatus, System an Method for the Efficient Storage and Retrieval of 3-Dimesionally Organized Data in Cloud Based Computing Architectures,” which is hereby incorporated by reference, to among other things, store, access, and view 3D seismic data and depth models within a cloud architecture utilizing a web browser or other client side application. The method disclosed in the '913 patent also provides for the efficient access to the depth model over network connections.
Team members can use client devices 108 to communicate with drilling management system 102 to request a visualization of an active drill. In response, drilling management system 102 can transmit visualization data to the team member's client device 108. The visualization data can be rendered by client device 108, for example in a web browser or other client-side application, to present the user with a visualization of an active drill. This can include a 2 or 3 dimensional rendering of the drilling site including a visual representation of the traversed path of the drill bit, the target wellbore trajectory, target horizon, and geo-hazard, such as a pre-existing wellbores, unpierced fault planes, lease boundaries, etc.
FIG. 2 illustrates an exemplary system embodiment of a drilling management system 102. FIG. 2 is described in view of the system and components described in FIG. 1. As shown, the drilling management system 102 includes a data stream receiving module 202, a rule analysis module 204, a notification module 206, a data visualization module 208, a data stream storage 210, a depth model storage 212 and a rules storage 214. The various modules may involve a processor (or processors) and computer executable instructions to receive the data stream, apply one or more rules to the data stream, and provide notifications as needed. The storage may be provided by one or more tangible readable media, provided as a database or databases, where data from the data stream is stored, the depth model is stored, and rules are stored.
The data stream receiving module 202 receives drilling data streams from one or more drilling sites 106. A drilling data stream can include drilling data describing an active drill. In one possible example, the data stream is accessed from a server or other computing device at the respective well and may be formatted according to the Wellsite Information Transfer Standard Markup Language (WITSML) standard. The data stream may be received at the drilling management system and/or the data stream storage over the network 104. The data stream receiving module 202 can receive and store the received drilling data in the data stream storage 210. The data stream storage 210 can include a data stream index for one or more of the drilling sites 106. The drilling index can be a data index, data file, database, data table, etc., that includes a listing of drilling data received from a particular drilling site 106. For example, a drilling index can include a listing of coordinate data describing the location of a drill bit at the drilling site 106, as well as time stamp data, identifying data, etc. As a drilling operation procedure, the data stream will provide updated data as to the progress of the drilling operation and the current location of the drill bit. Accordingly, the drilling index for a drilling site 106 can include data documenting the traversed path of the drill bit at the drilling site 106, as well as other sensor data and metadata describing drilling at the drilling site 106.
Each drilling index can be associated with a unique identifier identifying the corresponding originating drilling site 106. The data stream receiving module 202 can identify the unique identifier included in a received drilling data stream to identify the corresponding drilling index in data stream storage 210 and record the received drilling data in the identified drilling index.
The rule analysis module 204 is configured to analyze received drilling data to determine whether to notify team members regarding the status of an active drill. For example, the rule analysis module 204 can utilize the drilling data along with a depth model and a set of rules corresponding to a drilling site 106 to determine whether a rule has been triggered and team members should be notified.
The depth model storage 212 can store depth models for drilling sites 106 and rule storage 214 can store sets of rules for the drilling sites 106—with rules being unique and/or common to each drilling site. Each depth model and set of rules can be associated with a unique identifier for its corresponding drilling site 106. The rule analysis module 204 utilizes the unique identifier for a drilling site 106 to gather the corresponding drilling index, depth model and set of rules from data stream storage 210, depth model storage 212 and rule storage 214, respectively.
The rule analysis module 204 can then use the gathered data to determine whether a rule has been triggered. Moreover, the rule analysis module 204 can determine whether a rule has been triggered according to a predetermined temporal schedule, such as every 5 seconds, 10 seconds, 1 minute, etc. The rule analysis module 204 can also determine whether a rule has been triggered as updated coordinate data (e.g., relative drill bit location data) is received from a drilling site 106 as part of a drilling data stream.
The set of rules for a drilling site 106 can include any number or type of rules and/or conditions for notifying team members. For example, a set of rules may include a simple temporal milestone rule dictating that team members be notified of the status of an active drill at specified time intervals, such as every 30 seconds, 1 minute, 5 minutes, etc., or according to a specified time schedule. In one example, a user interface may be accessed through a client device 108, where the user interface provides access to a set of preconfigured rules. The user interface may include fields to activate any given rule as well as to set variables for any given rule. The update time, for example, may be a rule variable set through the user interface. The rule analysis module 204 can monitor elapsed time during an active drill for each specified temporal milestone.
As another example, a set of rules can include a distance based milestone rule dictating that team members be notified as the drill bit reaches predetermined distance intervals (a variable settable through the user interface), such as every 10 feet, 20 feet, 100 feet etc., or according to a specified distance schedule. The rule analysis module 204 can utilize the location data stored in the drilling index to determine the current location of a drill bit as well as the distance traversed by the drill bit during the active drill and determine whether the rule has been triggered.
As another example, a set of rules can include a trajectory deviation rule dictating that team members be notified when the current location of the drill bit deviates beyond a predetermined threshold distance from the target wellbore trajectory and/or the target horizon for the drill bit. Rule analysis module 204 can utilize the location data stored in the drilling index to determine the current location of a drill bit and utilize the depth model to determine the target wellbore trajectory and/or the target horizon. Rule analysis module 204 can then determine the distance between the current location of the drill bit and the target wellbore trajectory and/or target horizon and compare the distance to a threshold distance to determine whether the rule has been triggered.
With respect to comparing the actual drill bit location to the drilling plan, a distance is computed between a point in three-dimensional space (the X, Y, Z coordinate for the current location of the drill bit) and the drilling plan, which may be represented by a polyline in three dimensional space (series of points through the 3D space of the depth model). The distance may be resolved into a z-component and an xy-component, which may be defined in the depth model or separate therefrom. In that regard, the system can determine the location of the drill bit relative to plan and provide any suitable notification—e.g., “at 5:30 p.m., the drill bit is 15 feet above the drilling plan, and 10 feet North of the drilling plan”.
As another example, a set of rules can include a trajectory deviation rule dictating that team members be notified when an angle of the drill bit relative to the target horizon exceeds a threshold angle deviation from the target horizon. Rule analysis module 204 can utilize the location data stored in the drilling index to determine a direction (e.g., vector direction) of the drill bit and use the target horizon from the depth model. Rule analysis module 204 can then determine an angle deviation of the drill bit from the target horizon and compare the angle deviation to the threshold angle deviation to determine whether the rule has been triggered.
As another example, a set of rules can include a minimum distance rule to a geo-hazard, such as a pre-existing wellbore, unpierced fault plane or lease boundary. Rule analysis module 204 can utilize the location data stored in the drilling index to determine the current location of a drill bit and utilize the depth model to determine the location of a geo-hazard. Rule analysis module 204 can then determine the distance between the current location of the drill bit and the geo-hazard and compare the distance to a threshold distance to determine whether the rule has been triggered. In this example, the computed X, Y, Z position of the drill bit (current and the previous values, which trace out the actual wellbore path) are compared to the location of a fault surface. The fault surface is stored as a triangulated surface in the same X, Y, Z coordinate system as the coordinates of the path of the drill bit. Computational geometry is used to compute the distance between a point in 3D space (e.g., the most recent position of the drill bit) and a surface in 3D space along a direction vector (the direction that the drill bit is heading). The distance is expressed in standard distance units (meters). So, if a threshold distance has been set for proximity to fault surfaces (such as 50 meters, which may be a variable), when that distance is less than or equal to 50, a notification is generated.
With respect to the intersection of the drill bit with a geohazard of some sort, the planned wellbore (a polyline in 3D space) indicates approximately where the wellbore is going to be, and the actual wellbore indicates the real-time (near real-time position) of the drill bit and where the drill bit has been. The path of the drill bit and the current location of the drill, which collectively represents the wellbore, may be represented as a three-dimensional polyline starting at the surface where drilling commences and extending to a point represented by the current location of the drill bit. In one example, any fault surface that intersects the planned wellbore may be considered a “geohazard”. For any such fault surface, the system can compute the distance to the geohazard by computing the distance from the current drill bit position to the intersection of the planned wellbore with that fault surface. Furthermore, the system can estimate the time of the intersection occurring by dividing the distance by the current rate of penetration of the drilling (expressed by convention as Feet or Meters per Hour), which may be received by the system with the drilling information provided by the MWD system.
Rule analysis module 204 can determined the distance between the current location of the drill bit and another location based on geographic coordinates associated with the two points, such as an X coordinate value, Y coordinate value and Z coordinate value assigned to drill bit and the other point. In instances where an object is associated with multiple geographic coordinates, such as a target wellbore trajectory, lease boundary, pre-existing wellbore, etc., rule analysis module 204 can determine the shortest distance between the current location of the drill bit and the other location.
In another example, the rule analysis module may compare the current drill bit position to a target horizon or target horizons. The rule analysis module may also compare the drill bit to a range of distances from a target horizon, or may generate a virtual horizon and compare the location of the drill bit to the virtual horizon. In one example, the depth model may include at least one target horizon. The target horizon, may be a surface comprised of X, Y and Z coordinate data. The target horizon may be associated with the top surface, bottom surface or some other surface associated with a formation identified in the seismic data cube from which the depth model is based. For example, a shale bearing formation may be identified in a seismic data set, and a target horizon may be generated and stored for a surface representing the top surface of the formation.
Continuing with the example of a shale formation and a horizon defining a surface in the depth model for the top of the formation, during drilling, it may be desired to drill a horizontal well within some distance from the top of the formation. Hence, a rule may be created to compare the current drill bit position with a target horizon, and generate some form of notification when the drill bit deviates some distance, defined in the rule, from the top of the formation (the target horizon).
In another example, it is possible to define a second horizon, such as related to the bottom of the shale formation, and define a rule that provides a notification when the drill bit comes within some target distance of either the top or the bottom of the formation. Hence, assuming the drilling plan is intended to maintain the wellbore within the formation (between the upper and lower surface), the rule will be triggered if the drill comes within some distance of either the top or bottom surface. Hence, the system may generate rules based on some relationship between the drill bit and/or path of drilling, and a zone. The zone may be considered a region within a 3D dimensional volume, based on (computed from) one or more horizons (actual or virtual) in or associated with the depth model. Target zones have areal extent (as horizons do), but also have thickness. When a horizontal well is drilled, the drilling team will attempt to define a wellbore path that having penetrated down to a target zone, which will often be a thickness of a formation, stays within the target zone for the lateral portion of that wellbore path. The system provides a mechanism to define a rule associated with the target zone and provide notifications based on the progress of drilling within the defined zone.
Thus, the system, through the rule module or otherwise, may also be used, such as through the user interface, to generate and base a rule based on the notion of a target zone. The target zone, generally speaking, is a bounded zone within which it is desired to maintain the drill bit. In one example, the target zone may reference a target horizon and some distance or distances from the target horizon, in the way introduced above. One simple example of a target zone would be a target horizon and the target horizon plus or minus some amount. Referring again to the notion of a shale formation, a target horizon may be defined for a top surface of the shale formation, and a drilling plan may be target a zone immediately below the top surface of the horizon and within the shale formation. Hence, the target zone may be bounded by the target horizon and 20 feet below the target horizon, representing a target zone of the upper 20 feet of the shale formation. In another example, a target zone may be both above and below a target horizon. A rule may be established to generate a notification when the drill bit comes within some distance of either the top or bottom of the defined zone. Similarly, a rule may be established when a vector computation of the wellbore progress indicates that the drill bit is deviating upwardly or downwardly within the zone in a way that would cause the wellbore to leave the target zone.
In another example, when there are adjacent formations, it is possible to create a virtual horizon representing some relationship between target horizons associated with each formation. For example, if there is an upper and a lower shale formation, that are stacked and adjacent one another, with each formation defined by a target horizon for the upper surface of the respective horizons, a virtual horizon might reference a relationship between the target horizon of each formation and a range of distances (above and below) the virtual horizon. In this way, a target zone based on the virtual horizon may be defined.
In yet another example, the system (e.g., the rule module) may generate a virtual horizon. In one example, the virtual horizon may be a surface defined as some set distance from another surface, such as a virtual horizon defined relative to a target horizon in the depth model. The rule may both generate the virtual horizon, and be defined to generate a notification based on the distance of the drill bit from the virtual horizon. In this example, the target horizon is a surface within the depth model, where the surface is based on some corresponding feature in the related seismic data, and the virtual surface is a surface that is generated based on some mathematical relationship to the target horizon. A virtual surface may be useful, for example, when the resolution of the seismic data is insufficient to identify sub features within a formation, but it is believed, based on perhaps other information, that it is useful to target or avoid the sub feature and a virtual surface is generated for the sub feature, and the rule then based on the sub feature.
The target zone region may be further refined by analysis of the 3D seismic data sample values that fall within the target zone. An analysis may determine that some sub-regions within the target zone should be high-graded, and some sub-regions should be avoided. For example, one computation of the seismic sample values yields numeric values (a so-called “seismic attribute values”) that are indicative of rock stiffness, which gives an indication of how well the rock in a sub-region will respond the hydraulic fracturing process. Now that seismic attribute values can be portioned into ranges. For example, if all of the values are normalized into a range of 0 to 100, and the range 0-30 is classified as undesirable, and the range 70 to 100 is classified as very desirable, and the pixel values of the seismic attribute values are colored as Red as undesirable, and Green as desirable, and Transparent for anything else, now a seismic cross-section through the target zone will reveal red areas to be avoided and green areas to be high-graded. The boundaries of these sub-regions can be detected and converted into closed surfaces, and rules based on such surfaces, that are in the same X,Y,Z coordinates as our depth model of the target zone or other features, and as such, can be added to and be considered as part of the definition of the target zone or otherwise be defined as a feature from which the drill bit location and trajectory of the well bore may be compared, and rules generated to trigger notifications based on the relationship of the drill or well bore to such features.
The notification module 206 is configured to notify team members when a rule has been triggered. Rule analysis module 204 can provide to the notification module 206, when a rule has been triggered, the data identifying the triggered rule. In one example, the user interface may include a function for team member contact information is entered. The contact information may include a phone number for an SMS message, an email address, or other information for the form of communication. The team members and contact information may be linked to the drilling site, and whenever a rule is triggered for the drilling site, the team receives a message over the form (or forms) of communication entered in the site.
In response to receiving a notification from the rule analysis module 204 that a rule has been triggered, notification module 206 can identify a set of team members that should be notified. In some embodiments, each rule can identify the corresponding team members that should be notified when the rule has been triggered as well as include contact information for the identified team members, preferred contact method for the team members and/or data that should be provided to the team members. Notification module 206 can use the data in the triggered rule to generate and transmit notification messages to the team members. For example, notification module 204 can transmit the notification messages as text messages, instant messages, e-mails, etc.
Data visualization module 208 can be configured to provide team members with a visualization of an active drill. The visualization of the active drill can be a 2 or 3 dimensional rendering of the active drill at a drill site 106, including a visual representation of the traversed path of the drill bit, the target wellbore trajectory, target horizon, and geo-hazard, such as a pre-existing wellbores, unpierced fault planes, lease boundaries, etc.
Data visualization module 208 can receive data visualization requests from client devices 108 for a visualization of an active drill. A data visualization request can include data identifying a drilling site 106, such as the unique identifier for the drilling site 106. Data visualization module 208 can use the unique identifier included in the visualization request to identify and gather the corresponding drilling index in data stream storage 210 and depth module in depth model storage 212. Data visualization module 208 can use the gathered data to generate visualization data that can be rendered by client devices 108 to present the visualization of the active drill. Data visualization module 208 can provide the generated visualization data to the requesting client device 108, where it can be rendered for the team member. Data visualization module 208 can continue to provide updated visualization data to client device 108 to update the visualization of the active drill, thereby allowing the team member to view progress of the active drill in real-time.
FIG. 3 illustrates an example method 300 of automated geo-target and geo-hazard notifications for drilling systems. It should be understood that there can be additional, fewer, or alternative steps performed in similar or alternative orders, or in parallel, within the scope of the various embodiments unless otherwise stated.
At step 302, a drilling management system can receive a first drilling data stream. The first drilling data stream can include coordinate data describing a traversed path of a drill while drilling a well at a first drilling site. For example, the coordinate data can include an X axis value, a Y axis value and a Z axis value of the drill. The Z axis value can indicate a depth of the drill.
At step 304, the drilling management system can determine, based on the coordinate data and a depth model of the first drilling site, that a first rule has been triggered. The depth model of the first drilling site can identify a target wellbore trajectory for the drill at the first drilling site. For example, the drilling management system can determine, based on the coordinate data, a current location of the drill and a distance between the current location of the drill and the target wellbore trajectory. The drilling management system can then determine that the distance between the current location and the target wellbore trajectory meets or exceeds a threshold distance dictated by the first rule.
At step 306, the drilling management system can identify at least a first user that should be identified when the first rule has been triggered. For example, the first rule can include data identifying the at least a first user that should be identified when the first rule has been triggered.
At step 308, the drilling management system can transmit a notification to the first user that the first rule has been triggered.
FIGS. 4A-4D illustrate exemplary visualizations of an active drill along with various possible information used by the rule module to generate a notification. The visualization of the active drilling operation depicted in FIG. 4A presents a 3 dimensional representation of a drill site 400 (e.g., 3D seismic volume) including a target horizon 402 and seismic cross-section 404. The intersection of the target horizon and the seismic cross-section represents a target wellbore trajectory 406 of the drill bit. The current location of the drill bit 408 (as obtained from the drill stream data) as well as the traversed path 410 of the drill bit (e.g., wellbore path) is presented relative to the 3d seismic volume, thereby allowing a team member to visually determine whether the drill bit is remaining on the target wellbore trajectory.
FIG. 4B shows another visualization of an active drill. As show by the drill bit path 410, the drill bit 408 has drifted away from the target wellbore trajectory 406. In this example, a target zone is also shown, which is bounded by the target horizon and defined, within a rule, as a distance d above the target horizon and a distance d′ below the target horizon. In this example, besides deviation from the well bore trajectory, a rule may also be triggered when the drill comes within some distance of the upper or lower surface of the zone or other relationship to the zone is defined. As mentioned above, the system may provide the visualization through a web browser. Within the browser, an alert (a form of notification) may be posted and a visual cue 412 provided in the viewable seismic cube. For example, a deviation alert in the form of a text box may pop up in the browser window, and a color coded portion of the actual drill path relative to the target trajectory highlighted in some form such as a different color relative to the non-deviated portion of the drill path.
FIG. 4C shows another visualization of an active drill. As shown, the location of a pre-existing wellbore 414 is presented in addition to the traversed path 410 of the drill bit 408 and the target wellbore trajectory 406. Additionally, a minimum threshold distance that the drill must maintain from the pre-existing wellbore is represented as a cylinder 416 surrounding the pre-existing wellbore. The cylinder may be represented in the depth model as a three dimensional surface derived from a radius, of whatever distance needed, around the preexisting wellbore. For example, a cylindrical x, y, z surface may be generated around the wellbore based on a 50 foot radius. Hence, an alert will be triggered when the current drill bit position intersects any data point of the cylinder defined by the 50 foot radius (e.g., the drill bit gets within 50 feet of a preexisting wellbore). A team member can view this visualization and easily determine that the drill bit has drifted away from the target wellbore trajectory and is approaching the minimum threshold distance from the pre-existing wellbore.
FIG. 4D shows another visualization of an active drill. As shown, the location of a geologic fault surface 418 is show in relation to the traversed path 410 of the drill bit. A team member can view this visualization and easily determine that the drill bit is nearing the geographical fault surface, and a rule may trigger an alert or other notification where the drill bit 408 reaches some distance from the fault. In this example, the geo-hazard 418 may also be color coded for easy differentiation relative to other features.
FIG. 5A, and FIG. 5B illustrate exemplary possible system embodiments. The more appropriate embodiment will be apparent to those of ordinary skill in the art when practicing the present technology. Persons of ordinary skill in the art will also readily appreciate that other system embodiments are possible.
FIG. 5A illustrates a system bus computing system architecture 500 wherein the components of the system are in electrical communication with each other using a bus 505. Exemplary system 500 includes a processing unit (CPU or processor) 510 and a system bus 505 that couples various system components including the system memory 515, such as read only memory (ROM) 520 and random access memory (RAM) 525, to the processor 510. The system 500 can include a cache of high-speed memory connected directly with, in close proximity to, or integrated as part of the processor 510. The system 500 can copy data from the memory 515 and/or the storage device 530 to the cache 512 for quick access by the processor 510. In this way, the cache can provide a performance boost that avoids processor 510 delays while waiting for data. These and other modules can control or be configured to control the processor 510 to perform various actions. Other system memory 515 may be available for use as well. The memory 515 can include multiple different types of memory with different performance characteristics. The processor 510 can include any general purpose processor and a hardware module or software module, such as module 1 532, module 2 534, and module 3 536 stored in storage device 530, configured to control the processor 510 as well as a special-purpose processor where software instructions are incorporated into the actual processor design. The processor 510 may essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.
To enable user interaction with the computing device 500, an input device 545 can represent any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech and so forth. An output device 535 can also be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems can enable a user to provide multiple types of input to communicate with the computing device 500. The communications interface 540 can generally govern and manage the user input and system output. There is no restriction on operating on any particular hardware arrangement and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.
Storage device 530 is a non-volatile memory and can be a hard disk or other types of computer readable media which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, solid state memory devices, digital versatile disks, cartridges, random access memories (RAMs) 525, read only memory (ROM) 520, and hybrids thereof.
The storage device 530 can include software modules 532, 534, 536 for controlling the processor 510. Other hardware or software modules are contemplated. The storage device 530 can be connected to the system bus 505. In one aspect, a hardware module that performs a particular function can include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as the processor 510, bus 505, display 535, and so forth, to carry out the function.
FIG. 5B illustrates a computer system 550 having a chipset architecture that can be used in executing the described method and generating and displaying a graphical user interface (GUI). Computer system 550 is an example of computer hardware, software, and firmware that can be used to implement the disclosed technology. System 550 can include a processor 555, representative of any number of physically and/or logically distinct resources capable of executing software, firmware, and hardware configured to perform identified computations. Processor 555 can communicate with a chipset 560 that can control input to and output from processor 555. In this example, chipset 560 outputs information to output 565, such as a display, and can read and write information to storage device 570, which can include magnetic media, and solid state media, for example. Chipset 560 can also read data from and write data to RAM 575. A bridge 580 for interfacing with a variety of user interface components 585 can be provided for interfacing with chipset 560. Such user interface components 585 can include a keyboard, a microphone, touch detection and processing circuitry, a pointing device, such as a mouse, and so on. In general, inputs to system 550 can come from any of a variety of sources, machine generated and/or human generated.
Chipset 560 can also interface with one or more communication interfaces 590 that can have different physical interfaces. Such communication interfaces can include interfaces for wired and wireless local area networks, for broadband wireless networks, as well as personal area networks. Some applications of the methods for generating, displaying, and using the GUI disclosed herein can include receiving ordered datasets over the physical interface or be generated by the machine itself by processor 555 analyzing data stored in storage 570 or 575. Further, the machine can receive inputs from a user via user interface components 585 and execute appropriate functions, such as browsing functions by interpreting these inputs using processor 555.
It can be appreciated that exemplary systems 500 and 550 can have more than one processor 510 or be part of a group or cluster of computing devices networked together to provide greater processing capability.
For clarity of explanation, in some instances the present technology may be presented as including individual functional blocks including functional blocks comprising devices, device components, steps or routines in a method embodied in software, or combinations of hardware and software.
In some embodiments the computer-readable storage devices, mediums, and memories can include a cable or wireless signal containing a bit stream and the like. However, when mentioned, non-transitory computer-readable storage media expressly exclude media such as energy, carrier signals, electromagnetic waves, and signals per se.
Methods according to the above-described examples can be implemented using computer-executable instructions that are stored or otherwise available from computer readable media. Such instructions can comprise, for example, instructions and data which cause or otherwise configure a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Portions of computer resources used can be accessible over a network. The computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, firmware, or source code. Examples of computer-readable media that may be used to store instructions, information used, and/or information created during methods according to described examples include magnetic or optical disks, flash memory, USB devices provided with non-volatile memory, networked storage devices, and so on.
Devices implementing methods according to these disclosures can comprise hardware, firmware and/or software, and can take any of a variety of form factors. Typical examples of such form factors include laptops, smart phones, small form factor personal computers, personal digital assistants, and so on. Functionality described herein also can be embodied in peripherals or add-in cards. Such functionality can also be implemented on a circuit board among different chips or different processes executing in a single device, by way of further example.
The instructions, media for conveying such instructions, computing resources for executing them, and other structures for supporting such computing resources are means for providing the functions described in these disclosures.
Although a variety of examples and other information was used to explain aspects within the scope of the appended claims, no limitation of the claims should be implied based on particular features or arrangements in such examples, as one of ordinary skill would be able to use these examples to derive a wide variety of implementations. Further and although some subject matter may have been described in language specific to examples of structural features and/or method steps, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to these described features or acts. For example, such functionality can be distributed differently or performed in components other than those identified herein. Rather, the described features and steps are disclosed as examples of components of systems and methods within the scope of the appended claims.

Claims

1. A method comprising:

receiving, by a drilling management device, a first drilling data stream, the first drilling data stream including coordinate data describing a traversed path of a drill bit while drilling a well at a first drilling site;

determining, based on the coordinate data and a depth model of the first drilling site, that a first rule has been triggered, wherein the depth model of the first drilling site identifies a feature associated with the first rule; and

transmitting a notification to a first user that the first rule has been triggered.

2. The method of claim 1, wherein determining that the first rule has been triggered comprises:

determining, based on the coordinate data, a current location of the drill bit;

determining a distance between the current location of the drill bit and the feature; and

determining that the distance between the current location of the drill bit and the feature meets a threshold distance defined by the first rule.

3. The method of claim 1 wherein the feature is a least one of a target wellbore and a target horizon.

4. The method of claim 3, wherein determining that the first rule has been triggered comprises:

determining, based on the coordinate data, a current vector direction of the drill bit;

determining, an angle deviation between the current vector direction of the drill bit and the target wellbore defined by the depth model; and

determining that the angle deviation between the current vector direction of the drill bit and the target wellbore meets a threshold angle deviation dictated by the first rule.

5. The method of claim 1, wherein the feature is a preexisting wellbore, and determining that the first rule has been triggered comprises:

determining, based on the coordinate data, a current location of the drill;

determining, a distance between the current location of the drill and the preexisting wellbore defined by the depth model; and

determining that the distance between the current location of the drill and the preexisting wellbore meets a threshold distance dictated by the first rule.

6. The method of claim 1, wherein the feature is an unpierced fault plane, and determining that the first rule has been triggered comprises:

determining, based on the coordinate data, a current location of the drill;

determining, a distance between the current location of the drill to the unpierced fault plane defined by the depth model; and

determining that the distance between the current location of the drill and the unpierced fault plane meets a threshold distance dictated by the first rule.

7. The method of claim 1, wherein the feature is a lease boundary, and determining that the first rule has been triggered comprises:

determining, based on the coordinate data, a current location of the drill;

determining, a distance between the current location of the drill to the lease boundary defined by the depth model; and

determining that the distance between the current location of the drill and the lease boundary meets or is less than a minimum threshold distance dictated by the first rule.

8. The method of claim 1, wherein determining that the first rule has been triggered comprises:

determining, based on the traversed path of the drill, that a drilling milestone has been met.

9. The method of claim 1 wherein the coordinate data includes an X axis value, a Y axis value and a Z axis value of the drill, the Z axis value indicating a depth of the drill.

10. The method of claim 1, wherein the feature is a target zone based on a first horizon and a second horizon in the depth model, and determining that the first rule has been triggered comprises:

determining, based on the coordinate data, a current location of the drill bit;

determining, a distance between the current location of the drill bit to the first horizon or the second horizon; and

determining that the distance between the current location of the drill and the first horizon or the second horizon meets a threshold distance dictated by the first rule.

11. The method of claim 1, wherein the feature is a target horizon and the method further comprising generating a target zone defining at least one surface a distance from the target horizon, and determining that the first rule has been triggered comprises:

determining, based on the coordinate data, a current location of the drill;

determining, a distance between the current location of the drill to the at least one surface; and

determining that the distance between the current location of the drill and the at least one surface meets at least a first threshold distance dictated by the first rule.

12. A drilling management system comprising:

one or more computer processors; and

memory storing instructions that, when executed by the one or more computer processors, cause the one or more processors to:

determine, based on coordinate data from a first drilling data stream describing a traversed path of a drill bit while drilling a well at a first drilling site and a depth model of the first drilling site, that a first rule has been triggered, wherein the depth model of the first drilling site identifies a feature;

transmit a notification to a device associated with a first user that the first rule has been triggered.

13. The drilling management system of claim 12, wherein the feature is a target wellbore trajectory, and wherein to determine that the first rule has been triggered comprises:

determine, based on the coordinate data, a current location of the drill bit;

determine a distance between the current location of the drill bit and the target wellbore trajectory; and

determine that the distance between the current location of the drill bit and the target wellbore trajectory meets at least a first threshold distance dictated by the first rule.

14. The drilling management system of claim 12, wherein the feature is a target wellbore trajectory, and to determine that the first rule has been triggered comprises:

determine, based on the coordinate data, a current vector direction of the drill bit;

determine, an angle deviation between the current vector direction of the drill bit and the target wellbore trajectory defined by the depth model; and

determine that the angle deviation between the current vector direction of the drill bit and the target wellbore trajectory meets or exceeds a threshold angle deviation dictated by the first rule.

15. The drilling management system of claim 12, wherein the feature is a preexisting wellbore, and to determine that the first rule has been triggered comprises:

determine, based on the coordinate data, a current location of the drill;

determine, a distance between the current location of the drill and the preexisting wellbore defined by the depth model; and

determine that the distance between the current location of the drill and the preexisting wellbore meets or is less than a minimum threshold distance dictated by the first rule.

16. The drilling management system of claim 12 wherein the feature is an unpierced fault plane, and to determine that the first rule has been triggered comprises:

determine, based on the coordinate data, a current location of the drill;

determine, a distance between the current location of the drill to the unpierced fault plane defined by the depth model; and

determine that the distance between the current location of the drill and the unpierced fault plane meets a threshold distance dictated by the first rule.

17. The drilling management system of claim 12, wherein the feature is a lease boundary, and to determine that the first rule has been triggered comprises:

determine, based on the coordinate data, a current location of the drill;

determine, a distance between the current location of the drill to the lease boundary defined by the depth model; and

determine that the distance between the current location of the drill and the lease boundary meets or is less than a minimum threshold distance dictated by the first rule.

18. The drilling management system of claim 12, wherein to determine that the first rule has been triggered comprises:

determine, based on the traversed path of the drill, that a drilling milestone has been met.

19. The drilling management system of claim 12, wherein the coordinate data includes an X axis value, a Y axis value and a Z axis value of the drill, the Z axis value indicating a depth of the drill.

20. The drilling management system of claim 12, wherein the feature is a target zone with a first horizon and a second horizon, and to determine that the first rule has been triggered comprises:

determine, based on the coordinate data, a current location of the drill;

determine, a distance between the current location of the drill to the first horizon or the second horizon; and

determine that the distance between the current location of the drill and the first horizon or the second horizon meets a threshold distance dictated by the first rule.

21. The drilling management system of claim 12, wherein the feature is a target horizon and the one or more processors further generate a target zone defining at least one surface a distance from the target horizon, and to determine that the first rule has been triggered comprises:

determine, based on the coordinate data, a current location of the drill;

determine, a distance between the current location of the drill to the at least one surface; and

determine that the distance between the current location of the drill and the at least one surface meets at least a first threshold distance dictated by the first rule.

22. The drilling management system of claim 12, wherein the feature is at least of a target horizon or a target wellbore, and determining that the first rule has been triggered comprises:

determining, based on the coordinate data, a current location of the drill;

determining, a distance between the current location of the drill to the target wellbore or the target horizon; and

determining that the distance between the current location of the drill and the target wellbore or the target horizon meets a threshold distance dictated by the first rule.

23. A non-transitory computer-readable medium storing instructions that, when executed by a computing device, cause the computing device to:

receive a first drilling data stream, the first drilling data stream including coordinate data describing a traversed path of a drill bit while drilling a well at a first drilling site;

determine, based on the coordinate data and a depth model of the first drilling site, that a first rule has been triggered, wherein the depth model of the first drilling site identifies a feature;

identify at least a first user that should be identified when the first rule has been triggered; and

transmit a notification to the first user that the first rule has been triggered.

24. The non-transitory computer-readable medium of claim 23, wherein the feature is a target wellbore and, determining that the first rule has been triggered comprises:

determine, based on the coordinate data, a current location of the drill bit;

determine a distance between the current location of the drill bit and the target wellbore; and

determine that the distance between the current location of the drill bit and the target wellbore meets a threshold distance dictated by the first rule.

25. The non-transitory computer-readable medium of claim 23, wherein the feature is a target wellbore trajectory, and to determine that the first rule has been triggered comprises:

26. The non-transitory computer-readable medium of claim 23, where the feature is a preexisting wellbore, and wherein determining that the first rule has been triggered comprises:

determine, based on the coordinate data, a current location of the drill;

27. The non-transitory computer-readable medium of claim 23, wherein the feature is an unpierced fault plane, and determining that the first rule has been triggered comprises:

determine, based on the coordinate data, a current location of the drill;

determine that the distance between the current location of the drill and the unpierced fault plane meets or is a threshold distance dictated by the first rule.

28. The non-transitory computer-readable medium of claim 23, wherein the feature is a lease boundary, and determining that the first rule has been triggered comprises:

determine, based on the coordinate data, a current location of the drill;

determine that the distance between the current location of the drill and the lease boundary meets a threshold distance dictated by the first rule.

29. The non-transitory computer-readable medium of claim 23, wherein determining that the first rule has been triggered comprises:

30. The non-transitory computer-readable medium of claim 23, wherein the coordinate data includes an X axis value, a Y axis value and a Z axis value of the drill, the Z axis value indicating a depth of the drill.