US20150317184A1 - Systems and Methods For Processing Drilling Data - Google Patents
Systems and Methods For Processing Drilling Data Download PDFInfo
- Publication number
- US20150317184A1 US20150317184A1 US14/677,756 US201514677756A US2015317184A1 US 20150317184 A1 US20150317184 A1 US 20150317184A1 US 201514677756 A US201514677756 A US 201514677756A US 2015317184 A1 US2015317184 A1 US 2015317184A1
- Authority
- US
- United States
- Prior art keywords
- user
- designed
- modules
- drilling
- module
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000005553 drilling Methods 0.000 title claims abstract description 353
- 238000012545 processing Methods 0.000 title claims abstract description 304
- 238000000034 method Methods 0.000 title abstract description 113
- 238000004891 communication Methods 0.000 claims description 13
- 238000012986 modification Methods 0.000 claims description 9
- 230000004048 modification Effects 0.000 claims description 9
- 238000012544 monitoring process Methods 0.000 abstract description 5
- 230000008569 process Effects 0.000 description 50
- 230000008859 change Effects 0.000 description 16
- 230000000694 effects Effects 0.000 description 14
- 230000006870 function Effects 0.000 description 14
- 230000000737 periodic effect Effects 0.000 description 14
- 238000013461 design Methods 0.000 description 12
- 230000007246 mechanism Effects 0.000 description 12
- 238000005259 measurement Methods 0.000 description 10
- 230000004044 response Effects 0.000 description 10
- 230000005251 gamma ray Effects 0.000 description 9
- 230000001419 dependent effect Effects 0.000 description 7
- 238000001514 detection method Methods 0.000 description 7
- 238000004519 manufacturing process Methods 0.000 description 6
- 230000003068 static effect Effects 0.000 description 6
- 238000010200 validation analysis Methods 0.000 description 6
- 238000013459 approach Methods 0.000 description 4
- 239000003795 chemical substances by application Substances 0.000 description 4
- 238000012546 transfer Methods 0.000 description 4
- 244000035744 Hura crepitans Species 0.000 description 3
- 230000015572 biosynthetic process Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 238000005755 formation reaction Methods 0.000 description 3
- 239000000463 material Substances 0.000 description 3
- 230000002085 persistent effect Effects 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 2
- 230000006399 behavior Effects 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 239000012530 fluid Substances 0.000 description 2
- VNWKTOKETHGBQD-UHFFFAOYSA-N methane Chemical compound C VNWKTOKETHGBQD-UHFFFAOYSA-N 0.000 description 2
- 239000000203 mixture Substances 0.000 description 2
- 239000003921 oil Substances 0.000 description 2
- 238000013515 script Methods 0.000 description 2
- 239000004215 Carbon black (E152) Substances 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000005352 clarification Methods 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 239000010779 crude oil Substances 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000006073 displacement reaction Methods 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 238000010304 firing Methods 0.000 description 1
- 239000008241 heterogeneous mixture Substances 0.000 description 1
- 229930195733 hydrocarbon Natural products 0.000 description 1
- 150000002430 hydrocarbons Chemical class 0.000 description 1
- 230000003116 impacting effect Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 229910052500 inorganic mineral Inorganic materials 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 239000011707 mineral Substances 0.000 description 1
- 239000003345 natural gas Substances 0.000 description 1
- 230000004224 protection Effects 0.000 description 1
- 230000005855 radiation Effects 0.000 description 1
- 230000000246 remedial effect Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 238000012800 visualization Methods 0.000 description 1
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 1
Images
Classifications
-
- E—FIXED CONSTRUCTIONS
- E21—EARTH DRILLING; MINING
- E21B—EARTH DRILLING, e.g. DEEP DRILLING; OBTAINING OIL, GAS, WATER, SOLUBLE OR MELTABLE MATERIALS OR A SLURRY OF MINERALS FROM WELLS
- E21B44/00—Automatic control systems specially adapted for drilling operations, i.e. self-operating systems which function to carry out or modify a drilling operation without intervention of a human operator, e.g. computer-controlled drilling systems; Systems specially adapted for monitoring a plurality of drilling variables or conditions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
-
- G—PHYSICS
- G08—SIGNALLING
- G08C—TRANSMISSION SYSTEMS FOR MEASURED VALUES, CONTROL OR SIMILAR SIGNALS
- G08C19/00—Electric signal transmission systems
Abstract
Systems and methods for processing drilling data. One embodiment provides a method comprising building user-designed contexts (which can be designated as built-in contexts) for drilling structures. The method also comprises orchestrating module execution within the user-designed contexts. The method further comprises providing data from the user-designed contexts to such modules via an interface. Some methods include monitoring drilling data to detect events (for instance departure from a pseudolog) and orchestrating module execution responsive thereto. The method can include exposing the orchestration of the execution of the module instances as a service. Moreover, some embodiments provide extra-contextual application program interfaces. In addition, or in the alternative, some embodiments schedule the orchestration of the modules based on declarations related to the inputs and/or outputs of the modules.
Description
- Drilling rigs (for instance, those involved in hydrocarbon exploration and production) are acquiring increasing amounts of drilling data. Users of these drilling rigs and the companies interested in their operation typically use a combination of computer programs or processes and human intelligence to analyze the drilling data and combine it with previously recorded or stored historical data (and/or data from external databases) to control the drilling rigs; make decisions about current drilling activity; and/or to plan future exploration and production programs (that is, drilling programs).
- The gathered drilling data includes, but is not limited to, surface-based measurements about the rigs' equipment (such as hook load, block height, rotary RPM etc.); measurement while drilling (MWD) operational data (including measurements such as down-hole torque, gamma ray, resistivity, etc.); borehole trajectory survey information; vessel positioning and cable tensioning data; mud logs; lithology reports; operational reports; and any other data having a bearing on the condition of the drilling rigs, wells, their operations, etc.
- Lately, the advent of “wired pipe” is increasing the amount of data transmitted from down-hole locations. Moreover, because of the increasing availability of WANs (Wide Area Networks) such as the Internet, over which such data can be shared, users of such drilling data are finding ways to exploit the data with an expanding number of computer programs and each other. However, as disclosed herein, certain issues peculiar to drilling data (for instance data homogeneity and data heterogeneity) threaten to derail sharing of such data even as its availability soars. And, of course, the drilling data produced in these systems possesses some value and typically users want to preserve it and safeguard it from unauthorized tampering, spying, etc.
- Traditional well-planning, drilling and geo-steering decision programs, wellbore stability analysis and prediction programs, and other programs related to exploration and production efforts also typically suffer from problems associated with single purpose programs. For instance, a user might realize a need or desire for a new program, write the code, deploy it to a processing platform, and begin its execution. In writing these programs, the user typically includes express designations in the code for the locations of their inputs, outputs, and other resources. Even when a similar new program is desired for deployment elsewhere, the writing of the new program includes again identifying, locating, and expressly designating the locations of the new inputs, the new outputs, and other resources which the new program is to use in its new environment.
- Of course, sometimes desired functionality might suggest that the new program needs an input from another program. In such cases, the user must identify that other program and arrange some mechanism to ensure that this particular data is updated and available when needed. Sometimes, though, the user fails to provide that mechanism or the mechanism fails anyway. As a result, unpredictable operation of the new program occurs. These programs therefore often fail, “hang up,” crash, etc. thereby frustrating their very purpose and, of course, interested users. In addition, because the users expressly coded the resource addresses needed for these programs, they cannot readily be re-used and are therefore effectively single-purpose programs. A need or desire for multiple versions of these single-purpose programs (e.g., a copy for each drilling rig in a company) aggravates the situation since each copy must be manually re-written despite similarities between the underlying subject matter (e.g., the drilling rigs).
- Moreover, the needed data often originates at one point and is shared at some other point (or points). Typically, in such point-to-point data sharing schemes, the user must manually locate the logical, and sometimes even the physical, location of the source data and must manually identify the desired location for the processed results. Any mistake along the way can lead to unpredictable behavior of the programs depending on such resources. Moreover, deliberate attempts might be made to access or alter data for which the subject user has no access rights.
- Discussing a more specific situation will illustrate other shortcomings of previously available single-purpose, point-to-point programming approaches. Take for instance, a previously available wellbore-stability system that connects over a network to a particular drilling rig's porosity measurements; computes the wellbore's condition; stores the results; displays real-time visualizations thereof; and issues an indication if the results indicate that an off-nominal condition might exist. To write such a program, each source of data involved in the stability calculation must be manually identified and each storage location, display location, etc. must also be manually identified. Furthermore, if any of that input data originates with other single-purpose programs, all of those single-purpose programs must be identified. Plus, mechanisms must be created to ensure that they execute before the new dependent program.
- Similarly, a single-purpose geo-steering system can connect in a point-to-point manner with a source of a wellbore's current measured depth, azimuth, and inclination; calculate the wellbore's trajectory; store and display the results thereof; and issue an indication of the wellbore trajectory (whether nominal or off-nominal). Again, a user must manually and correctly identify the physical and logical source of the input data and of the targets for the various outputs. Moreover, the user must do so even when that data might not be stored (or otherwise available) where the user expects it to be and/or where the targets might have moved. In addition, the user must ensure the proper order of execution of all programs involved.
- Many applications in the drilling domain follow a similar pattern. A user manually connects a hard-coded program which resides at one point to a point source of drilling data; manually confirms the data source(s); the routing of the outputs and the functioning of the program; and then leaves the new program running, hopefully with the right input data and right output locations updated and available at the correct times. In other words, the user configures the program in a point-to-point fashion and often incidentally constrains the program to a single purpose. While single-purpose and/or point-to-point configurations might be useful for a limited number of such situations, they become wasteful of the user's time after the setup of even a few such programs. In light of the hundreds (thousands, etc.) of possible programs to be performed on drilling data, point-to-point and/or single-purpose programs are too cumbersome and error-prone for practical or efficient use.
- The following presents a simplified summary in order to provide a basic understanding of some aspects of the disclosed subject matter. This summary is not an extensive overview of the disclosed subject matter, and is not intended to identify key/critical elements or to delineate the scope of such subject matter. A purpose of the summary is to present some concepts in a simplified form as a prelude to the more detailed disclosure that is presented herein. The current disclosure provides systems, apparatus, methods, etc. for processing drilling related data. More particularly, systems of some embodiments enable users to avoid necessitating single-purpose and/or point-to-point configuration of data processing systems.
- In some embodiments, the drilling data relates to drilling structures including mobile and stationary drilling rigs, mobile and stationary production platforms, fields, wells, wellbores, and/or various other structures often related to one or more companies. Thus, in some embodiments, a module operating within a built-in context can operate on one piece (or set) of drilling data to produce a second piece of drilling data. In some embodiments, a processing system is configured to monitor such drilling data for an event and to orchestrate the execution of the module(s) responsive to that event. In other situations, a module could compare a log to a pseudolog for departures from expected conditions in a wellbore. In yet other situations, the module could produce a rig-related (or other) condition responsive to the drilling data which it receives. In addition, or in the alternative, the processing system could expose, to a network, services such as orchestrating the execution of the modules. Some embodiments also provide extra-contextual application program interfaces (APIs) to allow access to drilling data outside of a module's current context. In addition, or in the alternative, some embodiments schedule the orchestration of the modules based on declarations related to the inputs and/or outputs of the modules. Moreover, the modules can be user designed as can the built-in contexts.
- Another embodiment provides a method which comprises providing built-in contexts. The method also comprises orchestrating the execution of various user-designed modules residing within the built-in contexts. The built-in contexts, it is noted, can be user designed and can be enforced by a processing system. The method further comprises providing drilling data associated with one (or more) of the built-in contexts to the various user-designed modules and accepting drilling data from these user-designed modules via, for instance, a network or web-based interface. Methods of some embodiments also comprise monitoring the drilling data to detect events (for instance a rig condition change or a departure from a pseudolog) and orchestrating the execution of a user-designed module (s) responsive thereto. Furthermore, methods of some embodiments provide for exposing the orchestration of the execution of various modules within the built-in contexts as a service.
- Another embodiment provides a system for processing drilling data. The system of the current embodiment includes a network interface and a processor in communication therewith which is configured to provide built-in contexts. Furthermore, processors of the current embodiment are configured to orchestrate the execution of modules within the built-in contexts. The processor can also be configured to provide drilling data associated with one of the built-in contexts to one of the modules and to accept a response from the module via the network interface.
- Some embodiments create a context for each wellbore in a given well, field, etc. When a user-designed (or other) module executes in these contexts the processing system hands the module a reference to its context. In the current embodiment, the context is responsible for handling all queries and the contexts correspond to exactly one wellbore. Thus, when the context receives a query for some drilling data (perhaps a log) it responds with drilling data (the logs) associated with that wellbore and no others. In some embodiments, the context corresponds to other drilling structures such as fields. Accordingly, those contexts would respond to a query with drilling data related to all wellbores within the field. In some situations, metadata associated with the field(s) and wellbore(s) therein allow the processing system to identify all pertinent instances of a type of drilling data. Moreover, users can view graphic representations of such contexts on a user interface and the processing system will infer that user activities on the user interface should be associated with the currently displayed context and respond accordingly. This user interface could allow a user to build, modify, etc. contexts by dragging and dropping objects, modules, resources, etc. into the context. These contexts can then be built into various processing devices within the system as might be desired.
- To the accomplishment of the foregoing and related ends, certain illustrative aspects are described herein in connection with the annexed figures. These aspects are indicative of various non-limiting ways in which the disclosed subject matter may be practiced, all of which are intended to be within the scope of the disclosed subject matter. Other advantages and novel features will become apparent from the following detailed disclosure when considered in conjunction with the figures and are also within the scope of the disclosure.
- The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number usually identifies the figure in which the reference number first appears. The use of the same reference numbers in different figures indicates similar or identical items.
-
FIG. 1 illustrates a system for processing drilling data. -
FIG. 2 illustrates a drilling rig. -
FIG. 3 illustrates an organizational framework for processing drilling data. -
FIG. 4 illustrates aspects of two drilling data processing modules. -
FIG. 5 also illustrates aspects of two drilling data processing modules. -
FIG. 6 illustrates a method of processing drilling data. -
FIG. 7 illustrates aspects of a module for processing drilling data. -
FIG. 8 illustrates a method of setting up a drilling data processing job. -
FIG. 9 illustrates a method of executing a drilling data processing job in a context. -
FIG. 10 illustrates a method of executing a drilling data processing module in a context. -
FIG. 11 illustrates aspects of a user-designed context. -
FIG. 12 illustrates aspects of several user-designed contexts. - This document discloses systems, apparatus, methods, etc. for processing drilling data and, more particularly, for processing drilling data using user-designed contexts and drilling data processing modules.
- Processing systems of some embodiments provide mechanisms which orchestrate the execution of user-designed (and other types of) modules. Consequently, designers of new modules can develop the modules independently of one another. Processing systems of the current embodiment can also connect these user-designed modules to their in-context (and extra-contextual) inputs and outputs even in the presence of certain peculiarities associated with drilling data.
- In orchestrating the execution of the modules, processing systems of embodiments plan and coordinate the execution of the modules according to declarations of the modules which (as is further disclosed herein) relate to their associated contexts (whether built-in, user-designed, or both). For instance, should one module declare as an input the output of another module, processing systems of the current embodiment infer an in-context dependency between the modules. Accordingly, these processing systems schedule the execution of the modules in an order that provides that input after the data producing module updates the input. In other embodiments, all modules execute periodically and use corresponding input/output files to access various pieces of drilling data which might or might not be used by other modules. Upon awakening, each module checks to see of its input/output file has changed. If so, the module executes: if not, the module returns to a dormant state.
- Thus, there is no need for a user to plan the execution of the modules; identify their dependencies; or otherwise ensure that they execute in some desired order. The user of a new or modified process can therefore configure it as a plug-in module with only its inputs and outputs, and other desired resources specified in its declarations or provided for in its input/output file. Processing systems of the current embodiment can therefore provide resources to these modules according to their declarations and/or the input/output files. As a result, instead of configuring a new wellbore stability process (for instance) in a single purpose and/or point-to-point fashion, the user merely configures the desired functionality and specifies the sought after resources while allowing the processing system to account for the context in which those resources will be found and the scheduling of the modules.
- With reference now to the drawings,
FIG. 1 illustrates a system for processing drilling data. More particularly,FIG. 1 illustratessystem 100,companies 102,affiliates 104,fields 106,drilling rigs 108,wells 110,wellbores 112,numeric drilling data 114,descriptive drilling data 116, reams of data 118,event 120,user 122,data repository 126,indicator 128, user-designedcontext 130, and built-in context 132 among other aspects ofsystem 100. As is disclosed herein,system 100 generates and processes drilling data (for instancenumeric drilling data 114 and/ordescriptive drilling data 116 as well as other types of drilling data) to provide information (perhaps including raw or processeddrilling data 114 and 116) touser 122. It is noted here that thecompanies 102,affiliates 104,fields 106,drilling rigs 108,wells 110, andwellbores 112 comprise non-limiting drilling related hardware and/or structures of various sorts. Hereinafter, though, the term “drilling structure” and similar terms will be used to refer to such hardware and/or structures. - With continuing reference to
FIG. 1 ,companies 102 and/or theiraffiliates 104 navigatevarious drilling rigs 108 to thefields 106 which are at least suspected of containing water, oil, natural gas, crude oil, or other fluid materials capable of being extracted by the drilling rigs 108. Thus,companies 102 can operatedrilling rigs 108 infields 106 which in turn may be spread throughout diverse locations. Moreover, while eachdrilling rig 108 can drillmany wells 110 at various geographic locations, drilling technology allows somedrilling rigs 108 to createmultiple wellbores 112 inparticular wells 110. Thesemultiple wellbores 112 branch from themain well 110 and can often be drilled “horizontally.” - Accordingly, organizational hierarchies exist which reflect various relationships between the companies 102 (hereinafter including the affiliates 104), the
fields 106, thedrilling rigs 108, thewells 110, and thewellbores 112. While the hierarchies do not limit the scope of the disclosure, they do illustrate some reasons why user-designedcontexts 130 of embodiments allowusers 122 who are authorized to build contexts desirable flexibility inprocessing drilling data drilling data 114 and/or 116 outside of their range of privileges. Indeed, as is disclosed further herein, user-designedcontexts 130 can exist insystem 100 as peers rather than in some hierarchical relationship. Some of these user-designedcontexts 130 can be built intosystem 100 as built-in contexts 132 by context-buildingusers 122. - Still with reference to
FIG. 1 , acompany 102 often operates only some of thedrilling rigs 108 invarious fields 106. At another level, each of thesedrilling rigs 108 has one ormore wells 110 which they have drilled or which are otherwise associated with those drillingrigs 108. As is apparent fromFIG. 1 , some wells have more than onewellbore 112. Moreover, it is even possible that one company 102 (a state, nation, etc.) might own mineral rights to drill in aparticular field 106 and might licenseother companies 102 to drill therein. Thus, aparticular field 106 might be subject to exploration and/or production (i.e., drilling) byvarious companies 102 and have various drilling structures located therein. - Moreover, as those skilled in the art will appreciate,
drilling data users 122 and processing systems at various locations (physical, logical, or otherwise) in, or relative to, thesystem 100. While global information system (GIS) technologies provide some functionality that helpsusers 122 keep track of various drilling structures insystem 100, such GIS technology falls short of helpingusers 122 deal with data quality issues, ensuring thatdrilling data user 122 at the headquarters of acompany 102 might be interested in an (physical, logical, etc.)event 120 that is occurring (or that has occurred) on a givendrilling rig 108. However, given the mobility (and changeable ownership) of certain drilling structures, it might not be clear to thatuser 122 where in the system 100 (physically or logically) to finddrilling data event 120. Indeed, even when the ownership and location of the underlying drilling structure remains constant, locating and/or identifying thepertinent drilling data drilling data event 120 of interest. Furthermore, while the foregoing discussion focused onevents 120, it can be the case that auser 122 is interested in some piece(s) ofdrilling data event 120 per se. - Further still,
drilling data drilling data numeric drilling data 114 often includes voluminous time-indexed and/or depth-indexed data. Suchnumeric drilling data 114, while enabling real-time (and/or hindsight) insight toevents 120, can be difficult to access or appreciate since thesystem 100 sometimes produces much of it at rapid rates (with updates occurring within minutes, seconds, milliseconds, etc.). That is, somenumeric drilling data 114 might be real-time, dense data while other drilling data can be merely descriptive. The latter are often enumerated or user entered. For instance, the name and configuration of adrilling rig 108 insystem 100 might be user entered or might be enumerated from a known list of possibilities. Moreover,descriptive drilling data 116 could be entered in a textual format for yet another non-limiting example. - On that note,
descriptive drilling data 116 might be relatively static in that it will not normally change much over time and/or can be accessed at a pace desired by theuser 122 orsystem 100. This aspect is usually true of recorded or storeddescriptive drilling data 116. Moreover, somedescriptive drilling data 116 might not necessarily be “dense.” For instance, the overall condition of a drilling rig 108 (a “rig condition”) usually remains the same over relatively long periods of time and therefore comparatively few data points (along with perhaps time stamping) might be sufficient to indicate a drilling rig's top-level condition for minutes, hours, days, or longer. Furthermore, these two non-limiting types ofdrilling data events 120 and other information useful to theuser 122. To aid in processing such heterogeneous data,systems 100 of some embodiments can associate metadata (indicators 128 or otherwise) with each set (or even point) ofdrilling data drilling data drilling data system 100 can use the indicator to associate thecorresponding drilling data contexts 130 and 132 respectively. - In addition, inconsistencies in (and errors associated with)
drilling data 114 and 116 (for instance, the use of differing measurement units, data drop outs, storage formats, etc.) complicate deriving meaningful information for theusers 122 and the various automated or semi-automated processes in or associated withsystem 100. Thus, the indicator(s) 128 can be associated with various pieces ofdrilling data system 100 can accommodate various types ofdrilling data users 122 arranged for all of thisdrilling data data repository 126, many of the effects of the foregoing (and other) problems would persist within thedrilling data drilling data users 122 limited by systems heretofore available. Indeed, the available reams of data 118 and/or the difficulties in identifying, locating, processing, etc.drilling data events 120 as viewed byuser 122. - According to embodiments, a
user 122 can account for these data quality issues (among many others too numerous for enumeration herein) and issues related to orchestrating the execution of various processes by employing built-in contexts 132 and/or user-designed processing modules (and contexts). Regarding the orchestration of process execution, some embodiments differ from “sandbox” architectures in that the context builders create their own sandboxes. Moreover, they do so free of system imposed a priori sandbox-related restrictions if they so desire. Having discussed aspects ofsystem 100, it might now be useful to consider a particular drilling structure, such as adrilling rig 108, in greater detail. More particularly, it might be useful to discuss some aspects of the use of built-in contexts 132 inprocessing drilling data - Thus,
FIG. 2 illustrates a drilling rig. As shown, thedrilling rig 108 includes mast orderrick 200,drill string 202,hook 204, rotary table 206,connection 208,drill bit 212, andmud motor 214 among many other potential components. In addition,FIG. 2 illustrates that thedrilling rig 108 can include a computer ordata system 216 networked with aweb server 218 which further comprisesnetwork interface 220,processor 222,memory 224, anduser interface 226.FIG. 2 illustrates that either, or both of, thedata system 216 of thedrilling rig 108 and theweb server 218 can be in communication with a Wellsite Information Transfer Specification Markup Language (WITSML) or other type ofdata repository 227. Thisparticular drilling rig 108 also includes (or uses) aninstrument package 228, alog 230, and apseudolog 232. - Typically,
users 122 on thedrilling rig 108 use thederrick 200 and hook 204 to suspend thedrill string 202 while drillingvarious wellbores 112. They do so by repeatedly makingconnections 208 between pieces of drill pipe (and/or other down-hole components) to form thedrill string 202 and drilling further to hopefully discover and/or extract fluid materials from a reservoir. In addition,users 122 operate the rotary table 206 to drive thedrill bit 212. In the alternative, or in addition,users 122 sometimes drill horizontally using themud motor 214 to drive thedrill bit 212. Colloquially, the former operation is known as “drilling” while the latter operation is known as “sliding.” Of course, at other times, theusers 122 can “trip” (that is, hoist) thedrill string 202 from thewellbore 112 as might be desired to install different components on thedrill string 202. Thus, various drilling operations create loads on thehook 204, rotary table 206, etc. While, the foregoing discussion only touches on a few of the types of operations occurring on thedrilling rig 108, it will be appreciated by those skilled in the art that many types of operations occur on thedrilling rig 108. - It will also be appreciated by those skilled in the art that the
drilling rig 108 can typically create one ormore wellbores 112 in any given well 110. Doing so entails creating aninitial wellbore 112 and perhaps even completing thatfirst wellbore 112. Often thefirst wellbore 112 happens to be a mostlyvertical wellbore 112 which proceeds from the initial drilling point approximately straight down through various formations sometimes until the reservoir is contacted. In such cases, the length of thedrill string 202 happens to correspond to the actual depth of the well 110 (i.e., the “true measured depth”). However,wellbores 112 with horizontal or sloped sections typically branch out from theinitial wellbore 112 in various directions to reach other portions of the reservoir or even other reservoirs. - As drilling proceeds, the
drill bit 212 cuts through various geologic formations to form thewellbores 112. Note that, in the case of ahorizontal wellbore 112, the length of thedrill string 202 can depart drastically from the actual vertical depth of thewellbore 112 because of the horizontal displacement of thedrill bit 212 from theinitial wellbore 112. The length of thedrill string 202 in these cases is sometimes equated with the “bit depth” or “measured depth.” It might also be worth noting that while the foregoing discussion involves a particular order for creating thewellbores 112, no particular order limits the disclosure. - Moreover,
users 122 often include aninstrument package 228 on the drill string 202 (on the wireline, placed down-hole, etc.) to measure aspects of the geologic formations through which thedrill bit 212 passes and/or other conditions. Instrument packages 228 typically measure the gamma radiation, resistivity, density, porosity, etc. in the vicinity of the drill bits 212 (or the down-hole portions of the drill string 202). In addition, surface portions ofdrilling rig 108 also producenumeric drilling data 114 including, but not limited to, the hook load and the torque being experienced by thehook 204 and rotary table 206 (or the drill string 202). All of the foregoing types of drilling data can be real-time, dense, time-series and/ornumeric drilling data 114. Of course, thedrilling rig 108 also typically generates or has associated therewithdescriptive drilling data 116 that often happens to be relatively static. Another example, would be a mudlog which once recorded for a wellbore, or portion thereof, does not change and therefore is static absent some unusual circumstance where it changes after having been stored (for instance, an error therein is corrected or a misfiled mudlog is re-filed correctly). Furthermore, some types ofdrilling data system 100 and are thus “static” or historical. - With continuing reference to
FIG. 2 , theinstrument package 228 communicates with thedata system 216 of thedrilling rig 108 via “wired pipe” or some other communication protocol. In addition, thedata system 216 communicates with theweb server 218 via thenetwork 233. Thenetwork 233 can be any type of network including a WAN (wide area network), LAN (local area network), hard wired (e.g., Ethernet), wireless, infrared, satellite-based, etc. type of network. Thus,drilling data drilling rig 108 can be shared with theweb server 218, other computers, thedata repository 227, etc. and even systems other thansystem 100. Moreover,drilling data users 122, etc. on thedrilling rig 108, elsewhere in thesystem 100, or anywhere in communication with the system 100 (seeFIG. 1 ). Becausedrilling data certain users 122 might only be allowed access (read, write, or read/write) to subsets ofdrilling data system 100 of some embodiments provides built-in contexts to, in part, provide data security in some situations. - Still with reference to
FIG. 2 , aprocessing system 236 can reside on theweb server 218 while one or more user-designedmodules 238 can reside in thedata system 216 on the drilling rig 108 (along with their input/output files 240 of some embodiments) of the current embodiment. Of course, theweb server 218 can be located at a headquarters of acompany 102, or elsewhere in the system 100 (seeFIG. 1 ). For instance, the web server 218 (with the processing system 236) could reside on thedrilling rig 108 indata system 216. Likewise, the user-designedmodules 238 can reside in various locations within the system 100 (for instance, inweb server 218, atcompany 102 headquarters, or in thedata systems 216 on the drilling rigs 108). However, typically, the user-designedmodules 238 reside on, or near, various drilling structures while theweb server 218 andprocessing system 236 typically reside at some convenient, centralized (at least organizationally) location. As those skilled in the art will appreciate, theweb server 218 includes certain functionality supporting theprocessing system 236. For instance, thenetwork interface 220 of theweb server 218 allows communications with thedata system 216 of thedrilling rig 108, while theprocessor 222 executes theprocessing system 236.Data system 216 includes similar supporting functionality for user-designedmodules 238 and other types of processes. -
Drilling data memory 224 of theweb server 218 although it can be stored elsewhere. For instance, thedrilling data data repository 227 or in the input/output files 240 indata system 216 among other locations. Moreover, because the various components of theweb server 218 communicate with each other and theuser interface 226,users 122 can accessraw drilling data modules 238, thedata system 216, and/or theprocessing system 236. - Furthermore, in some embodiments, the
processing system 236 exposes for use certain services which it provides to the user-designedmodules 238 and other processes (within or external to system 100) via thenetwork 233. As may be appropriate, such communications can be by way of any transmission protocol such as the Wellsite Information Transfer Specification (WITS), Open Connectivity (OPC), OPC Unified Architecture (OPC-UA), etc. and other applicable protocols, associated application program interfaces (APIs), etc. - Some of the
drilling data drilling rig 108 reflects profiles of thewellbores 112.Users 122 sometimes refer to these profiles aslogs 230 and theunderlying drilling data users 122 can predict with some accuracy what the profile of thewellbore 112 ought to be. These predictions can take the form of apseudolog 232 which details depth-correlated predictions of what measured conditions in thewellbore 112 ought to be. Since both thelog 230 and thepseudolog 232 correlate wellbore properties and depth, a comparison of thelog 230 and thepseudolog 232 for awellbore 112 can reveal unexpected conditions. For instance, if one of the properties on thelog 230 departs from its corresponding predicted value in thepseudolog 232, theusers 122 can take remedial action assuming, of course, that the data issues discussed herein do not obscure the deviation. Moreover, certain user-designedmodules 238 can maintain thelogs 230, compare them to thepseudologs 232, and issue indications should they detect deviations from thepseudologs 232. - No matter the type of operation occurring on the drilling rig 108 (or other drilling structure for that matter), these operations produce drilling data which might arise as
numeric drilling data 114 and/ordescriptive drilling data 116. Again, thedrilling data drilling data drilling data users 122 be given limited access rights to somedrilling data system 100, thedrilling rigs 108, thewells 110 thewellbores 112, anddrilling data FIG. 3 ) some aspects of anorganizational framework 300 sometimes associated with thesystem 100. -
FIG. 3 illustrates an organizational framework for processing drilling data. While systems heretofore available might usesuch frameworks 300 to organize the processing ofdrilling data context building users 122 from restrictions associated withsuch frameworks 300 by allowing theseusers 122 to build their own contexts independently offramework 300 provided that they have context-building permissions or access rights tosystem 100. Nonetheless, it might be informative (by way of comparison between such framework-based approaches and various embodiments) to discuss some aspects offramework 300. Thus,FIG. 3 illustratesframework 300, rig objects 306 and/or (production platform objects or the like), well objects 308, wellbore objects 310,rig context 316, andwell context 318, and built-incontexts 320.Framework 300 could also include contexts, objects, etc. associated with (oil) fields and companies which encompass some or all of thedrilling rigs 108, wells, 110,wellbores 112, etc. In addition, wellbore-based context, objects, etc. could be included inframework 300. As will be disclosed further herein,FIG. 3 also illustrates an event 340 (which might be either physical or logical),several modules event 350. - The various contexts (and objects) in
framework 300 can serve as logical constructs for associating information with the corresponding drilling structures of system 100 (seeFIG. 1 ). For instance, the wellbore objects 310 correspond toparticular wellbores 112 and allow the processing system 236 (seeFIG. 2 ) toassociate drilling data particular wellbores 112 with particular wellbore objects 310. Moreover, the various objects can be either sources of, or destinations for,drilling data processing system 236 toassociate events 340 and user-designed modules 238 (for instance, module 342) with the correspondingwellbore 112 as desired by context-building user 122. Other built-in contexts 320 (or objects) serve similar functions for drilling structures insystems 100 of differing types. Thus, built-incontexts 320 can freeusers 122 with context-building permission from restrictions implied by suchorganizational frameworks 300 while imposing onusers 122 without context building permissions data security policies associated withsystem 100. - With continuing reference to
FIG. 3 , inreal world systems 100, relationships between drilling structures are not simple or even static. Indeed, while one-to-one relationships exist, many-to-one, one-to-many, etc. relationships might exist and might also merge, disassociate, and otherwise change. Additionally, due to data-related issues such as data heterogeneity and/or data homogeneity, particular pieces ofdrilling data drilling data 114 and 116) that are not practicable to predict before the fact. Embodiments which allowusers 122 to build contexts allow theseusers 122 to avoid the restrictions of sandbox-like programming environments while being able to rely on sandbox-like enforcement and/or data security mechanisms provided byprocessing system 236 to restrict access todrilling data users 122 without such permission. - That being said, objects 306, 308, and 310 and their associated resources can be thought of as residing within the corresponding user-designed
contexts 320. As is disclosed further herein, context-buildingusers 122 can designate which objects, user-designed modules 238 (seeFIG. 2 ), and other resources reside in or are associated with a context the context-building user 122 desires to build. Instances of user-designedmodules context 320 roughly corresponding to someparticular wellbore 112. Indeed, that wellbore context could have been defined by a context-building user 122 by selecting the objects, user-designedmodules 238,drilling data FIG. 3 illustrates built-incontext 320 incorporating one and only one wellbore object 308 (which in many embodiments might be the typical or default built-incontext 320 provided by system 100), however, no such restriction exists on the manner in which asystem 100 could provide a context. For instance, some built-incontexts 320 can incorporate more than one object, overlap other contexts, and only partially incorporate some objects. Thus processingsystem 236 allows context-buildingusers 122 to violate some typical programming guidelines (for instance, treating objects as whole entities) if so desired. In the case illustrated byFIG. 3 , context-building user 122 has associated awellbore object 310,event 340, and user-designedmodules context 320. It is noted here that since these user-designedmodules modules - Moreover,
event 350 and user-designedmodule 348 are illustrated as having been associated with user-designed context (here a user-designedwell context 318A) roughly corresponding to the well 110 of which theparticular wellbore 112 is a part although only one of the wellbore objects 310 is shown within thatwell context 318A. But as noted, the relationships between the objects, user-designed contexts, etc. arising from user selections might or might not reflect hierarchical, organizational, etc. relationships inframework 300 and/orsystem 100 between various drilling structures (potentially including structures outside of system 100). - Thus, as will be appreciated by those skilled in the art, and depending on the nature of the
event 340, it might be the case that thatevent 340 affects not only the wellbore 112 (or other particular structure) with which it happens to be most closely associated but also withother wellbores 112 in thewell 110. Furthermore, because thesewellbores 112 are in thesame well 110, it is possible that either or both of theevents wellbores 112. Furthermore, the association of theevents 340 and/or 350 could flow to all of theother wellbores 112 of that well 110 and all (or part) of the way to a particular company(s) 102 depending on circumstances. Thus, theevents contexts 320. - For instance,
event 340 might be a single physical event that occurred in onewellbore 112 and that might affect more than one context such as a gamma ray measurement exceeding 300 API. A gamma ray monitoring module in that context might fire a “gamma ray out of bounds event” to all listeners in that context. In addition, a module in another wellbore context might have been set up to monitor all gamma ray readings in the corresponding well or even field. A different instance of the gamma ray monitoring module in the second context would similarly fire a logical “gamma ray out of bounds” event. Thus, the singlephysical event 340 might cause twological events 350 to fire in response thereto. - Moreover, because of circumstances not practicable to foresee, associations such as the foregoing might only occur to a
user 122 after consideration or even through happenstance. Thus, embodiments allowusers 122 to define their own built-incontexts 320 to reflect associations which they select. - Furthermore, each built-in context 320 (whether user-designed, hierarchical, or otherwise) of some embodiments has associated therewith certain other types of information. Context-
building users 122 can define these associations as desired with, or without, regard toframeworks 300 or other relationships between drilling structures. - Moreover,
users 122 sometimes want to perform certain processes on thedrilling data system 100 might come.System 100 of various embodiments therefore allows context-buildingusers 122 to design contexts tailored to enable, handle, and/or otherwise facilitate the functioning of user-designedmodules 238 encapsulating such processes. It is noted here that since a module does not (ordinarily) access drilling data outside of the context in which it operates, user-designedmodules 238 can be authored byusers 122 with or without context building authority. - In various embodiments,
system 100 allows these processes to be encoded, encapsulated, or otherwise contained within user-designedmodules 238 such as user-designedmodules modules 238 and/or built-incontexts 320 allow non context-buildingusers 122 to set their own rules for processingdrilling data processing system 236 to enforce those rules via context-based security mechanisms.Processing system 236 also operatively connects user-designedmodules 238 with thedrilling data modules 238. - Likewise,
processing system 236 of various embodiments accepts, handles, or otherwise receives the responses of the user-designedmodules 238 as desired by theuser 122. To do so, theprocessing system 236 of some embodiments associates a user declared context (for instance, built-in context 320) with each user-designedmodule 238 and even other modules, programs, processes, etc. - The actual context associated with each user-designed
module 238 depends on circumstances but is usually selected by its author. But, if desiredprocessing system 236 can derive a default context from the logical location in which a user-designed module 238 (or rather an instance thereof) or other type of process resides or appears to originate. Thus, should a user-designedmodule 238 arise from thedata system 216 of a given drilling rig 108 (seeFIG. 2 ),processing system 236 associates adefault rig context 316 corresponding to thatdrilling rig 108 with that user-designedmodule 238 unless otherwise designed byuser 122. Thereafter,processing system 236 connectsdrilling data same rig context 316 to that user-designedmodule 238 unless otherwise indicated. In this manner, should a user-designedmodule 238 in a particular context request a resource, it receives a resource or an instance of a resource (for instance, drilling data 114) associated with the drilling structure corresponding to its default context. Context-building user 122, though, can override the default context by designating another context or creating a built-incontext 320 as they desire. User-designedmodule 238 and/or user-designedcontext 320 authors therefore can be free to define their own rules via the manner in which they design their built-incontexts 320 and user-designedmodules 238 within the constraints of their access privileges. - It is noted that various processes might not have been designed to operate with built-in
contexts 320 or other aspects ofprocessing system 236. Thus,processing system 236 of the current embodiment can attempt to associate a context with each process which tries to accesssystem 100 whether it executes withinsystem 100 or elsewhere. Each time such a legacy (or other) process seeks to access a resource withinsystem 100,processing system 236 can determine with which drilling structure the legacy process appears to be associated and assigns that process the corresponding context. If no particular context appears to be appropriate,processing system 236 can return a query to the process requesting more specificity in its access request and can issue a prompt to define a context if the process (or user) so desires and has the appropriate privileges. Thus,system 100 allows legacy processes to interact with the drilling structures, associated objects, contexts, anddrilling data system 100. For instance, if some event causes a legacy process to execute, the identity of theevent 120, metadata associated therewith, or the logical point of origin of theevent 120 withinframework 300 orsystem 100 can be used to determine a probable context of that invoked legacy process if the legacy process identifies the event 120 (orother system 100 related trigger) in its access request. - User-designed
modules 238 whether or not designed to useframework 300, though, can be designed to declare what their context should be (at least for the desired purposes of that user-designed module 238). Thus,processing system 236 associates a context with most if not all instances of the user-designedmodules 238 and/or legacy processes. When a user-designedmodule 238 needsdrilling data 114 or 116 (or provides such resources),processing system 236 connects the user-designedmodule 238 to the appropriate source or destination within the context in which the requesting user-designedmodule 238 resides. Furthermore, should a user-designedmodule 238 attempt to modify a resource outside of its context,processing system 236 can regulate such conduct (thereby enforcing the context for the user-designedmodule 238 and preventing data access outside of the scope of that context). - In some embodiments, though, user-designed
modules 238 can expressly declare that some desired sources or destinations ofdrilling data processing system 236. And, indeed,processing system 236 of some embodiments provides extra-contextual application program interfaces (APIs) to handle such situations. Note thatprocessing system 236 can also handle in-context drilling data processing system 236 generally follows the declared specifications to the specified in-context source/destination while allowing module authors further flexibility inprocessing drilling data frameworks 300, built-incontexts 320, and user-designedmodules 238 together, it might now be useful to further discuss aspects of user-designedmodules 238 themselves in greater detail. - Thus,
FIG. 3 provides an illustrative set of user-designedmodules events module 342,FIG. 3 shows thatmodule 342 was associated with a particular built-incontext 320,wellbore object 310, and wellbore 112 by context-building user 122. Thus, ordinarily,processing system 236 will provide instances of user-designedmodule 342 with resources from within thatwellbore context 320. In some situations it might be the case thatprocessing system 236 provides resources to user-designedmodule 342 from another related context such as arelated rig context 316, orwell context 318 or even other sources via an appropriate extra-contextual API. For instance, certain pieces ofdrilling data user 122 designed user-designedmodule 320 to deal with) might be found in the selected well, rig, field, or company context respectively. In such situations, as declared byuser 122 in the user designedmodules 238,processing system 236 employs the built-incontext 320 that user-designedmodule 238 to align in-context resources with that user-designedmodule 238. Moreover, user-designedmodule 238 could even declare data external to its user designed context and/orframework 300 via an appropriate extra-contextual API call. - In the case shown in
FIG. 3 ,module 342 happens to monitordrilling data 114 and/or 116 from built-incontext 320 to determine whetherevent 340 might have occurred or is occurring. Events, in such situations, could be a periodic scheduled firing, a threshold detected event emitted by some other module, or some other programmatic event generated by the processing system or by another module in the same context. It might be worth noting thatevent 340 could be difficult to discern by auser 122 located far (either physically or logically) from the corresponding wellbore 112 (seeFIG. 1 ). As illustrated, though, user-designedmodule 342 can detect and/or begin handlingevent 340 as designed byuser 122. Furthermore, depending on its functionality, user-designedmodule 342 might or might not be sufficient to fully handle theevent 340. Indeed, user-designedmodule 342 could be designed to merely detect theevent 340 and output an indication that theevent 340 occurred (that indication, perhaps, being an event itself that user-designedmodule 342 fired). In which case,processing system 236 would receive that indication from user-designedmodule 342 and forward it to user-designedmodules 344 and 346 (if their declarations specify that output of user-designedmodule 342 as an input). Thus, the arrows between theevents modules processing system 236 handles the transfer ofdrilling data 114 and/or 116 there between. - Accordingly,
processing system 236 could watch for changes in the output of user-designedmodule 342 so that, whenevent 340 occurs,processing system 236 becomes aware of the same.Processing system 236 could then orchestrate the execution of user-designedmodules event 340. Note that some of these user-designedmodules modules Processing system 236 examines those input declarations; locates the corresponding outputs (as provided by corresponding modules); and arranges for the execution of the input-producing user-designedmodules 238 before execution of the input-requiring user-designedmodules 238. - Of course,
processing system 236 could perform such analyses in reverse. That is,processing system 236 could examine the output declarations; determine which inputs correspond thereto; and schedule execution of the corresponding user-designedmodules 238 accordingly.Processing system 236 can therefore schedule and orchestrate execution of the various user-designedmodules processing system 236 arrives at a particular schedule, processing system 236 (in orchestrating execution of various user-designed modules 238) can send corresponding data systems 216 (on the drilling structures or elsewhere) notifications of when that schedule indicates that various user-designed modules 238 (and other processes) can begin. -
FIG. 3 also illustrates that user-designedmodule 348 can cause anotherevent 350 to occur. For instance, suppose thatevent 340 is the completion of anew wellbore 112. In this case, completion of thenew wellbore 112 could return the associated well 110 to service or at least remove some operational restrictions associated therewith. In that case,many users 122 could be interested in that information. In addition, as soon as well 110 returns to service the extraction of materials there from, and from theother wellbores 112 therein, could resume. As such, the occurrence ofevent 350 could serve to notifymany users 122 of such a change. Other user-designedmodules 238 could begin executing, or resume executing upon the occurrence ofevent 350 if they are registered to listen for events of the type associated withevent 350. It might be worth noting thatmodule authoring users 122 can register modules withprocessing system 236 to listen for event types. When such an event occurs, processing system calls the module's event handler for events of that type and in so doing passes an instance of that event to the module. Moreover, user-designedmodule 348 could be associated with some context other than the built-incontext 320 which theinitial event 340 occurred as specified by theuser 122.FIG. 3 therefore illustrates user-designedmodule 348 andevent 350 as having been so associated with user-designedcontext 318A which, in the embodiments ofFIG. 3 , happens to be superior (in the optional framework 300) to a default wellbore context. Note that the term “superior” here connotes that one context contains another context and does not otherwise limit built-incontexts 320 built-incontexts framework 300 is therefore not required for the practice of many embodiments but can be used if desired. -
FIG. 4 further illustrates aspects of two drilling data processing modules. More particularly,FIG. 4 illustrates two particular user-designedmodules periodic events connectors modules modules FIG. 2 ) of aparticular drilling rig 108, user-designedmodules processing system 236 in web server 218 (which can be remote there from) for at least some input/output activity associated withdrilling data modules drilling rig 108 and for determining the torque and drag being experienced by thedrilling string 202 of anydrilling rig 108. Thus, since processingsystem 236 can connect the user-designed modules to appropriate inputs (no matter their origin ondifferent drilling rigs 108 or other drilling structures)processing system 236 supports portability and interoperability ofmodules 238. - In the current embodiment, torque and drag user-designed
module 404 depends on rig state user-designedmodule 402 for an operations report (or, rather,certain drilling data user 122 to 1) identify all of the point-to-point configurations necessary to create and forward the operations report and 2) order the execution of processes corresponding to user-designedmodules 238,processing system 236 relievesusers 122 of these burdens at least in part. - At run time, the rig state user-designed module 402 (with the aid of the processing system 236) thus first creates the operations report via its
connectors output connector 418.Processing system 236 then forwards the operations report to torque and drag user-designedmodule 404 in accordance with itsinput connector 414. Thus, as long as an in-context operations report is available from somewhere, for instance an instantiation of torque and drag user-designedmodule 404, rig state user-designedmodule 402 can be modified or disappear without impacting torque and drag user-designedmodule 404.Processing system 236 can therefore support independent development and maintenance of user-designedmodules 238. - Moreover, both user-designed
modules periodic events processing system 236 examining and acting on corresponding dependencies) and therefore accept as inputs indications thatevents processing system 236 happens to useperiodic events modules modules periodic events user 122 could have designed user-designedmodules processing system 236 uses some asynchronous mechanism to schedule execution of user-designedmodules modules module 402 change,processing system 236 would cause rig state user-designedmodule 402 to execute and, should the operations report output thereby change, cause torque and drag user-designedmodule 404 to execute thereafter. Thus, in accordance with various embodiments, all or part of these dependencies were inferred byprocessing system 236 from declarations associated with the inputs and outputs of in user-designedmodules user 122 of the current embodiment does is (for the first use of an input, output, or other resource) identify that resource and its logical (and/or physical) location insystem 100.Processing system 236 can there after maintain information about that resource in a database, table, or other information repository. For instance, for each resource,processing system 236 could maintain its location, origin, destination(s), etc. and perhaps the dependencies required to create it and those dependencies (partly) satisfied by it in that information repository. - As a result, when processing
system 236 instantiates user-designedmodules processing system 236 examines the declarations of each of the user-designedmodules modules module 404 indirectly indicates that it depends onrig state module 402 executing beforehand because of its reliance on the output thereof (the operations report). Using the corresponding declaration of torque and drag user-designedmodule 404, theprocessing system 236 would schedule torque and drag user-designedmodule 404 after the execution of rig state user-designedmodule 402. - Moreover, each of the user-designed
modules FIG. 4 ,connectors module 402 to the affect that rig state user-designedmodule 402 requires hook load, drill speed, bit depth, and holedepth drilling data Processing system 236 defaults the context of an instance of rig state user-designedmodule 402 to that context whichuser 122 has selected for that instance of rig state user-designedmodule 402. Thus, in the absence of a declaration to the contrary, rig state user-designedmodule 402 receives in-context instances of hook load, drill speed, bit depth, and whole depth data. - In the current embodiment, another declaration of rig state user-designed
module 402 could specify that rig state user-designedmodule 402 will output a resource, here the operations report, viaconnector 418. As it happens,input connectors periodic event 406 has occurred) enable instances of rig state user-designedmodule 402 to execute as authored.Output connector 418 allows instances of rig state user-designedmodule 402 to output the operations report to a location accessible by theprocessing system 236 and which is associated with the current instance of rig state user-designed module 402 (and therefore thecorresponding drilling rig 108, other drilling structures, or combinations thereof as envisioned by user 122). - The declarations of torque and drag user-designed
module 404 specify as its inputs the hook load, torque, and operations report of somedrilling rig 108 to be determined by context at instantiation time.Processing system 236 will usually assume that these inputs will be found in the context whichuser 122 has selected for the current instance of torque anddrag module 404. The declarations of torque and drag user-designedmodule 404 also specify that its instances will depend on the in-context occurrence ofperiodic event 408. If, however, a connector calls to an extra-contextual API, the associated inputs and/or output(s) can cross context boundaries as illustrated by the arrows between user-designedmodules FIG. 3 ). - Furthermore, if desired, user-designed
modules 238 can output HTML files (or active objects) which can include scripts, code, etc. for performing tasks dependent upon the processing and context of the torque and drag user-designedmodules 238 as desired by theauthoring users 122. For instance, some active files or modules can generate alert emails forvarious users 122. Here the active file will be received from the torque and drag user-designedmodule 404 by theprocessing system 236 via theoutput connector 426 and, perhaps will be executed by processingsystem 236. Furthermore, theprocessing system 236 will associate the active file with the context associated with torque and drag user-designedmodule 404 unless otherwise declared. Thus,processing system 236 could modify the context-generic output (here, the active file) with information related to thedrilling rig 108 corresponding to the current instance of torque and drag user-designedmodule 404. In the alternative, or in addition, a module could output an HTML file with an indication of the module's output, alert, etc.Processing system 236 could store the HTML and provideusers 122 an URL to the HTML file which they could use to retrieve the information therein.Processing system 236 therefore allows module authors to provide context specific messages, indications, alerts, and other outputs. Moreover,processing system 236 allowsusers 122 to define what that user-designed context might be and therefore the constraints on input/output activity by user-designedmodules 238 and other processes which can be enforced by processingsystem 236. -
Processing system 236 also provides several other illustrative services to user-designedmodules 402 and 404 (and/or other processes). For instance,processing system 236 orchestrates the occurrence ofperiodic events modules processing system 236 orchestrates the execution of instances of user-designedmodules processing system 236 examines the declarations of the various user-designedmodules modules Processing system 236 also causes their execution at in-context appropriate times (by, if necessary other processing platforms) while enforcing the appropriate contexts and/or handling extra-contextual API calls. - Furthermore,
processing system 236 accesses in-context drilling data framework 300 via the extra-contextual APIs) and provides that information to user-designedmodules input connectors processing system 236 obtains from the user-designedmodules output connectors processing system 236 associates these outputs with the drilling structure corresponding to the context of user-designedmodules modules - Interestingly, module authors need not declare or otherwise specify that the operations report to be output via
connector 418 is the same operations report to be input viaconnector 424 by, respectively, user-designedmodules modules cause processing system 236 to associate the operations report with, and retrieve it from, the appropriate context for instances of user-designedmodules processing system 236, using these declarations, routes the information from its source to its destination(s) with no point-to-point configuration being required of module authors orother users 122 once the corresponding resources are initially entered into the resource database, table, information repository, etc. - Thus, processing system, 236 automatically wires up graphs of modules when the declarations make the selections of inputs and outputs clear. If ambiguities exist with respect to the identity of an input or output,
processing system 236 can flag the ambiguity for resolution by auser 122. For instance, if two operations reports exist, a module declaring an input of type opsReport might create an ambiguity needing clarification to identify the particular operations report of interest. In which case, input from the user 122 (or a more elaborate declaration) would allowprocessing system 236 to resolve the ambiguity. -
FIG. 5 also illustrates aspects of two drilling data processing modules. More particularly,FIG. 5 again illustrates user-designedmodule 402 andperiodic event 406. However,FIG. 5 also illustrates alerting user-designedmodule 504 andasynchronous event 508. Here,event 508 indicates that thecondition 322 of adrilling rig 108 corresponding to an instance ofevent 508 has changed. Moreover, the declarations of alerting user-designedmodule 504 indicate that instances of alerting user-designedmodule 504 should execute after an in-context instance ofevent 508. Furthermore, the declarations of alerting user-designedmodule 504 indicate that its instances will produce alerts (as indicated at connector 526) of condition changes of corresponding drilling rigs 108. Here, for instance, an email could be sent to auser 122 noting the condition change of thedrilling rig 108 at issue. Note that a condition change associated with some other drilling rig 108 (or rig context 316) would cause a different instance ofevent 508 to trigger a different instance of alerting user-designedmodule 504 but would leave the current instance (and other out-of-context instances) of alerting user-designedmodule 504 unaffected. That is, in the current embodiment, theprocessing system 236 associates thedrilling data events 120,modules 238, etc. of one drilling structure with that drilling structure and that drilling structure alone. The context enforcement mechanism of the current embodiment, therefore prevents cross-talk or bleed-over ofdrilling data 114 and 116 (and other resources) between different contexts and between different drilling structures (if the user-designedmodules 238 were designed accordingly). Exceptions to this enforcement mechanism can be made via extra-contextual APIs as disclosed further herein. - Thus,
processing system 236 orchestrates the execution of instances of various user-designedmodules 238 in different contexts independently of one another with exceptions as called for. For instance,processing system 236 can monitordrilling data condition 322 of somedrilling rig 108 to change. Note that when a rig condition change occurs,processing system 236 examines the context of that condition change and notifies the corresponding instance of alerting user-designed module 504 (residing within the same context) of the occurrence of that change. No other instances of alerting user-designedmodule 504 will ordinarily be notified since thatcondition 322 change does not (in the current scenario) correspond to them. Moreover, because processingsystem 236 knows that the particular instance of that particular alerting user-designedmodule 504 depends on the occurrence of aparticular event 508 in a particular and corresponding context,processing system 236 schedules the corresponding instance of alerting user-designedmodule 504 to execute without executing other instances of alerting user-designedmodule 504. Once that instance of alerting user-designedmodule 504 executes and delivers its output, theprocessing system 236 receives the output as indicated byconnector 526 and associates the alert with the current context. - As in other situations, the authors of the alerting user-designed
module 504 need not bother with point-to-point configurations of theinput drilling data output drilling data modules 238. Nor do the authors need to bother with determining on whichdrilling rig 108 theevent 508 occurred.Processing system 236 obviates the need for such inefficient, cumbersome, and error-prone activities. Moreover, becauseusers 122 need not worry about such scheduling issues,processing system 236 supports re-use of user-designedmodules 238 in contrast to previously available single-purpose approaches which necessitateuser 122 involvement in scheduling such single-purpose processes. Having discussed aspects of user-designedmodules 238 it might be useful to discuss methods for processing data. - Thus,
FIG. 6 illustrates a method of processing data. More particularly,FIG. 6 illustratesmethod 600 which can be executed by processingsystems 236 of various embodiments.Method 600 can begin with aprocessing system 236 exposing context-based services associated with various drilling structures via a network 233 (for instance, the Internet). These services can include building, modifying, and deleting contexts (inframeworks 300 if used) as corresponding drilling structures appear and disappear fromsystem 100 and/or asusers 122 desire. Furthermore,method 600 can include building, modifying, or deleting objects corresponding to these drilling structures although doing so is not required for the practice of many embodiments. Moreover, the exposed services can include orchestrating the execution of various user-designedmodules 238. For instance, theprocessing system 236 of some embodiments examines the declarations of user-designedmodules 238 to determine upon which other modules or processes they might depend by examining the input data types which the modules declare and inferring which other modules supply those data types. Note that modules of embodiments also declare the output data types further enabling the identification of inter-module dependencies. Seereference 602. - Thus,
processing system 236 can examine the declarations of user-designedmodules 238 to determine which pieces ofdrilling data modules 238 might depend upon. If a piece ofdrilling data module 238 executes,processing system 236 can include such a drilling-data-producing user-designedmodule 238 in the dependencies of the user-designedmodule 238 which it is scheduling. In addition,processing system 236 can expose services related to monitoring the dependencies of user-designedmodules 238 and, services related to causing the instantiation and/or execution of user-designedmodules 238. -
Reference 604 illustrates thatmethod 600 can include determining whether it is desired to add a new context(s) to framework 300 (seeFIG. 3 ) or to a table, database, or some other information repository accessible byprocessing system 236. These new contexts might be called for when a new drilling structure appears in thesystem 100 or when auser 122 desires a new context. Thus, asnew drilling rigs 108,wells 110, and/orwellbores 112 appear insystem 100 and/orusers 122 so desire,method 600 includes adding corresponding contexts (whether user-designed or otherwise) toframework 300. Moreover, sincesystem 100 might change due to actions other than the addition of new drilling structures,method 600 can include modifying and deleting existingcontexts users 122 can initiate the modification, deletion, etc. of these contexts if so desired and at times and for reasons which they decide upon. -
Processing system 236 can become aware of such modifications tosystem 100 in a variety of manners. For instance,processing system 236 can be configured to poll network services applications residing insystem 100 for modifications to thenetworks 233 anddata systems 216 residing therein. In the alternative, the network services applications could be configured to informprocessing system 236 of such changes. In addition, or in the alternative,processing system 236 could be a portion of those network services applications ofsystem 100. They could, thus, be aware of such changes due to their internal information. In other cases,processing system 236 could examine inbound communications from user-designedmodules 238 and/or other processes for new IP (Internet Protocol) addresses or other logical or physical addresses (which can be included in such communications if desired). Of course,users 122 could informprocessing system 236 of such modifications or otherwise configureprocessing system 236 to account for changes insystem 100 or their desires by, for instance, modifying the available set of contexts. Seereference 604. - In some situations, processing system will be able to automatically add, delete, and modify contexts accordingly. But, it might be the case that some situations will occur in which
user 122 intervention can aid in resolving ambiguities in the process. Thus,processing system 236 of embodiments automatically adds, deletes, and modifies contexts when it can and otherwise flagsusers 122 where user intervention might be appropriate. Similarly, processing system of embodiments assistsusers 122 with identifyingdrilling data 114 and 116 (or types thereof) of interest and connectingsuch drilling data - Furthermore, building the built-in
contexts 320 can include associating appropriate objects with new contexts and associatingdrilling data method 600 includes building, modifying, and deleting contexts asusers 122 desire. Seereference 606. If, on the other hand, no new context appears to be appropriate or called for) at a given time,method 600 can continue as indicated by the branch fromdecision 604 toreference 608. - At some point, a new user-designed
module 238 might be introduced intosystem 100. Seereference 608. Usually, as is disclosed further with reference toFIGS. 7-10 ,processing system 236 learns of the existence or creation of a new (or modified) user-designed module 238 (or instance thereof) through registration and/or instantiation as desired byusers 122. Instantiation (or for that matter registration, a technique similar to initiation but occurring before run time) of a new user-designedmodule 238 includes validating the connectors of the new user-designedmodule 238. - To validate the connectors,
processing system 236 of the current embodiment confirms that the metadata of the connectors refer to actual pieces ofdrilling data 114 and/or 116 in some context in the system 100 (or, perhaps, generated by other user-designedmodules 238 therein). More particularly, since various context-generic pieces ofdrilling data processing system 236 need not search theentire system 100 for the particular pieces ofdrilling data processing system 236 can limit its search to one of each type of context that it has knowledge of or can otherwise locate (and any external data that might likely be called for by a connector). For instance,systems 100 which use aframework 300 might have many instantiations of similar (or perhaps even nearly identical) contexts for similar drilling structures and/or corresponding objects, functions, etc. Once a context-particular piece ofdrilling data processing system 236 merely needs to alter the context to another similar context to locate other context-particular pieces ofsimilar drilling data 114 and 116 (see reference 612). - For instance, almost all
drilling rigs 108 will generate adrilling string 202 torque measurement. Onceprocessing system 236 finds one torque measurement in onerig context 316, it can assume that similar torque measurements will be found inother rig contexts 316.Processing system 236, of course, can verify such assumptions by querying thedata systems 216 orusers 122 of corresponding drilling rigs 108 (or other drilling structures).Processing system 236 can also confirm the measurement units used and otherwise eliminate the effects of various data homogeneity and heterogeneity issues by similar techniques. At module execution time, which might be some time other than module instantiation time,processing system 236 of the current embodiment uses the context associated with the current instance of user-designed module 238 (the instance being spawned in this scenario) to locate the in-context piece ofdrilling data module 238. Thus, not only do the connectors allowprocessing system 236 to find in-context drilling data module 238, they also allowusers 122 and module authors to avoid much or all of the inefficient, cumbersome, and error-prone single-purpose and/or point-to-point configuration efforts. If, for some reason, the validation activities ofreference 610 fails,processing system 236 can alert the author of themodule 238 or someother user 122. - With continuing reference to
FIG. 6 ,reference 616 illustratesmethod 600 scheduling the execution of one or more user-designedmodules 238. As disclosed further elsewhere herein, the declarations and connectors of each user-designedmodule 238 allowprocessing system 236 to determine dependencies between modules or other processes. Using these dependencies,processing system 236 determines the order of execution of the various user-designedmodules 238 and whether they can execute in parallel, serially, etc. Note that, in many cases, all user-designedmodules 238 involved will be associated with a particular context. However, by examining the connectors (and/or associated declarations, APIs, etc.),processing system 236 can determine whether any extra-contextual interactions between modules or other processes might occur at module instance execution time. In such cases,processing system 236 can examine the schedule of execution in the other contexts at issue to ensure that each dependency will be satisfied despite the potential for such a schedule to cross context-related boundaries. It might be worth noting here that when a module does declare an extra-contextual input/output,processing system 236 will in many cases do what it can to identify the corresponding entities. But, extra-contextual connectors carry with them a possibility that they will create an ambiguity thatuser 122 intervention could resolve. In such cases,processing system 236 can flaguser 122 if such an ambiguity arises. Nonetheless,processing system 236 will connect in-context drilling data modules 238 involved according to connector metadata (including extra-contextual data declarations and/or APIs). With instances of user-designedmodules 238 scheduled for execution,method 600 can wait for their dependencies to be satisfied before executing these instances of user-designedmodules 238 if appropriate. Seereference 618. - When some dependency becomes satisfied,
FIG. 6 illustratesprocessing system 236 executing those instances of user-designedmodules 238 for which all dependencies (for instance, dependencies based on instances of other user-designedmodules 238,events 120,drilling data modules 238 that previously had all dependencies except the current one satisfied can be executed and usually will be. Seereference 620. Moreover, as might often be the case, as an instance of a user-designedmodule 238 executes it might generate one or more responses. These responses can include the output ofnew drilling data Processing system 236 can accept the response(s) and route these new or updated resources to the destinations (user-designedmodule 238 instances, for instance) indicated by the connectors of user-designedmodules 238. - If desired,
method 600 can repeat as indicated byreference 622. In the current embodiment, ifnew contexts 320 or user-designed modules 238 (or instances thereof) appear insystem 100,processing system 236 can loop through portions ofmethod 600 until some input (or a user 122) indicates that no further processing is desired. Having discussed activities generally associated withprocessing system 236, it might now be useful to discuss activities generally associated with a particular instance of a user-designedmodule 238. - Thus,
FIG. 7 illustrates some aspects of a drilling data processing module. More particularly,FIG. 7 illustrates aspects ofprocessing system 236 and user-designedmodules 238 as the life of a particular instantiation of user-designedmodule 238 progresses. Generally,processing system 236 includes functions such asweb interface 706 andscheduler 708 functions.Processing system 236 also includeslife cycle manager 712,executor 714, andservice manager 716 functions.Executor 714 is associated withscheduler 708 of the current embodiment whilelife cycle manager 712 andservice manager 716 are associated withweb interface 706. Over the life of an instance of user-designedmodule 238, the instance passes through phases such asinstantiation 718, gettingresources 720,validation 722, ready 723,execution 724, andoutput 726 as illustrated byFIG. 7 . Each row ofFIG. 7 therefore generally represents a phase of a module's existence in whichprocessing system 236 calls a corresponding method on the instance of the module such as “initialize (or instantiate) yourself,” “get parameters from the user,” “execute,” etc. The ready 723 reference being an exception to this rule of the current embodiment. Of course, onceprocessing system 236 performs some tasks for a particular user-designedmodule 238 those tasks (and the associated instance phases) need not be revisited. For instance, validation of a particular user-designedmodule 238 usually occurs only once no matter how many instances of a particular user-designedmodule 238 whichprocessing system 236 spawns. - That being said,
instantiation phase 718 of a user-designedmodule 238 typically begins whenuser 122 determines that they wish to have an instance of user-designedmodule 238 instantiated. As a result,processing system 236 gets the parameters from the user-designedmodule 238 by asking it to present an HTML form on which theusers 122 can enter or select the parameters for the module. Seereference 720.Life cycle manager 712 might also validate the resources it located (includingdrilling data 114 and 116) as declared by the connectors of user designed module 238 (see reference 722). In addition,processing system 236 might conduct a preliminary location of these resources at this time by, for instance, searching each type of context present inframework 300 and/or in a table, database, or other information repository for context-particular instances of thatdrilling data user 122 does not request scheduling or execution of the instance of user-designedmodule 238,processing system 236 can pause (with respect to that instance of that module) after preliminarily locating those resources. Additionally,processing system 236 schedules the execution of the current instance of the instantiated user-designedmodule 238 in accordance with the declarations and/or connectors of the user-designedmodule 238. - Thus, at some point the current instance of user-designed
module 238 becomes ready to execute which may/may not be considered a phase. But it is shown inFIG. 7 to indicate that at some point,processing system 236 has readied user-designedmodule 238 for instantiation and execution. Seereference 723. For instance, all of its in-context dependencies might become satisfied. If that instance of that user-designedmodule 238 is ready for execution,executor 714 ofprocessing system 236 communicates to the current instance of user-designed module 238 (or thecorresponding drilling rig 108 data system 216) that that instance may execute and can also pass along current in-context drilling data 114 and 116 (and other resources be they in-context or not) as specified by the connectors of user-designedmodule 238. Responsive to that communication fromprocessing system 236, the current instance of user-designedmodule 238 begins executing perhaps by processing thedrilling data processing system 236. Seereference 724. At some point, the current instance of user-designedmodule 238 executes sufficiently so as to produce an output or other response in accordance with its connectors. For processing real-time data from adrilling rig 108, for instance,system 216 communicates the response toservice manager 716 via network 233 (seeFIG. 2 ) andweb interface 706.Service manager 716 routes the response to its intended destinations (whether in-context or not) in accordance with the connectors of user-designedmodules 238. The current instance of user-designedmodule 238 can continue executing or it can terminate depending on how it is designed. However,processing system 236 is not limited to processing real-time drilling data drilling rig 108.Processing system 236 can process many types of data including historic or pre-recorded data. For instance, auser 122 might want to examine some down-hole data with a different filter than the one(s) initially used to study aparticular wellbore 112.Processing system 236 can support such activities as well as processing real-time drilling data - For instance, in some embodiments,
processing system 236 allows amodule authoring user 122 to design user-designedmodules 238 to create (or cause the creation of) hypertext documents or HTML (Hyper Text Markup Language) files conveying in-context information tousers 122 who might want to view the results of some processing task. Since any job might execute repeatedly, someusers 122 might find it convenient to have the output generate by each execution in a separate file. Moreover, becauseinterested users 122 might be distributed throughout system 100 (geographically and logically) using hyperlinks to access the results can be beneficial. Thus, in the current embodiment, each time an instance of some user-designedmodules 238 executes it generates a hypertext output file.Processing system 236 then exposes that HTML file tovarious users 122 via a hyperlink. - Recall that on the web, we use URIs (Uniform Resource Identifiers) a.k.a. URLs (Uniform Resource Locators) to identify resources that web browsers or similar programs can retrieve.
Processing system 236 makes the HTML files generated by some user-designedmodules 236 accessible via corresponding URIs. Moreover, some of these HTML files produced by instances of various user-designedmodules 236 can contain hyperlinks designed by these user-designedmodules 238. When auser 122 clicks one of those links or otherwise causes the user agent (or web browser or other program) to retrieve a resource (forinstance drilling data 114 or 116), that request goes toprocessing system 236 which routes it down to that instance of that user-designedmodule 238.Processing system 236 of the current embodiment calls the resource phase method of the user-designedmodule 238, and passes the resource phase method the URI requested by the agent. To do this,processing system 236 informed the user-designedmodule 238, in some earlier phase (perhaps execution phase 724), of some base URI that the instance can add to, to construct URLs thatprocessing system 236 can route down to the instance of user-designedmodule 238 at some desired time. - In some embodiments during the execute
phase 724,processing system 236 passes the instance a parameter such as “appbaseURI” that might be http://myserver/rigStateApp/, and another parameter “appInstanceURI” that might be http://myServer/rigStateApp/32544/id/. The module can use these parameters to construct URLs to place information, during executephase 724, into some output HTML file. - More specifically, a user-designed
module 238 titled “RigCondition Estimator” and designed to estimate the condition of adrilling rig 108 might write out the hyperlink <a href=“http://myServer/rigStateApp/32544/currentState”>Show Current States/a> into the HTML file. Here, the module appended some suffix meaningful to itself, to the base URI. A user can retrieve the HTML page output by one execution of this user-designedmodule 238 by clicking a link to it on a page in a user interface ofprocessing system 236 or of some processing device. -
Users 122 viewing that HTML page will see a (blue) highlighted link saying “Show Current Depth”.Users 122 can click that link to cause their agents to request fromweb interface 706 ofprocessing system 236 that resource.Processing system 236 of the current embodiment is designed to inspect the first part of the URL and see that it follows a pattern that indicates thatprocessing system 236 should route the call down to the “rigStateApp” an instance (here, instance id 32544) of user-designedmodule 238 for processing.Processing system 236 can do so by looking in its memory or other storage location (for instance data repository 126) for that instance and invoking its “resource” method, passing as a parameter, the requested URI: http://myServer/rigStateApp/id/32544/currentState. In addition,processing system 236 can also pass other information about the request to the module, including the HTTP (Hyper Text Transfer Protocol) method, the HTTP headers, etc. - The resource method of that user-designed
module 238 can return a string value that can be HTML forprocessing system 236 to return to the user's agent. In the current embodiment the Rig State Estimator user-designedmodule 238 might return “<html Drilling</html>”. In this way,processing system 236 can start running processing jobs that interact withusers 122 as the jobs run. The user-designedmodule 238 can construct rich HTML web applications that can use AJAX (Asynchronous JavaScript and XM) calls to interact with the running module instance, allowingusers 122 to query, or update its state. - It's also possible for a user-designed
module 238 to define “application-wide” resources. Remember above, theprocessing system 236 of the current embodiment passed two base URLs to the user-designed module 238: one was a prefix for instance-specific resources (appInstanceURI) and the other is for “application-wide” or “instance-agnostic” resources. These latter resources would be resources shared by all running instances of a particular user-designedmodule 238. More specifically, all Rig State user-designedmodules 238 of the current embodiment might display a common graphical icon that is the same for all instances.Processing system 236 can invoke the resource method on an instance of that user-designedmodule 238, or, for application-wide URIs, on the user-designedmodule 238 itself. So in the current embodiment,processing system 236 can route the request down to the proper running instance, but if the URI matches the prefix for application-wide resources, then processingsystem 236 can route the request to the user-definedmodules 238 in general, and not any particular instance. - With continuing reference to
reference 726, once the built-in (or user-designed) processing is performed,processing system 236 can wait for the next call for an instantiation of user-designedmodule 238 and/or the satisfaction of some dependency. - Of course, more than one instance of user-designed
module 238 could be executing at any given time along with instances of other user-designedmodules 238. Indeed, becausesystem 100 might have manydifferent data systems 216 operating on (or in conjunction with) various drilling structures, instances of other user-designedmodules 238 could be executing concurrently in many places insystem 100. For instance, in an embodiment ofsystem 100 withmultiple drilling rigs 108, multiple instances of user-designedmodules FIGS. 4 and 5 ) could be in various phases of their life cycles throughoutsystem 100 withprocessing system 236 maintaining framework(s) 300 (or a table, database, or other information repository); instantiating and executing user-designedmodules 238, enforcing contexts, and providing and/or receivingdrilling data modules 238. -
FIG. 8 illustrates a method of setting up a drilling data processing job. More particularly,FIG. 8 illustrates a method of setting up a drilling data processing job for execution. In methods of the current embodiment, a job is an instance of a user-designedmodule 238 which will execute in a particular context and often in response to some event. Thus, where the event occurs repeatedly in a particular context, the job will execute repeatedly responsive thereto to repeatedly deliver some desired functionality. Furthermore, should the user-designedmodule 238 be dependent on other modules or processes for its inputs or other resources, instances of those user-designedmodules 238 and processes will execute in an order which provides that desired functionality in a reliable manner. - With continuing reference to
FIG. 8 ,method 800 can begin when acontext building user 122 decides to add a job (or user-designed module 238) to a context. In thecurrent embodiment user 122 accesses any of the computing platforms in system 100 (or in communication therewith) and can start a wizard for setting up an instance of the job in the context. The wizard can present a list of pre-existing user-designedmodules 238 and contexts from whichuser 122 selects the context and the module to add to that context. Seereference 802. Of course, the wizard could include an option to build a new user-designedmodule 238 if desired and/or could default to the current context if the context building user fails to select a context. In that way, ifuser 122 is adding multiple user-designedmodules 238 to a given context (for instance, some wellbore context)user 122 need not repeatedly select the context. - Once
user 122 selects the user-designedmodule 238 of interest, the wizard examines the metadata associated with the connector(s) of the user-designedmodule 238. To do so, it examines the declarations (and/or metadata) related to the inputs and outputs of the user-designedmodule 238 as well as any events, data types, resources, etc. associated with the selected user-designedmodule 238. Seereference 804. At some point, the wizard invokes a function to get the parameters (for instance, various pieces ofdrilling data user 122 to select parameters from other contexts if desired. The call to the function could take a form such as getParameter(context). Seereference 806. In some embodiments the desired instance of the user-designedmodule 238 could be instantiated atreference 806. - As
FIG. 8 also illustrates (at reference 808) the UI could include a form which promptsuser 122 to enter (or select) the parameters of interest for the current user-designedmodule 238. The form could be an HTML form and could allowuser 122 to enter names for the parameters to be added to the instance ofmodule 238 to be created. With the parameters selected in this manner, or others, the wizard could invoke another function to validate the parameters asreference 810 illustrates. The call to the function could therefore include parameter: context pairs (whenextra-contextual drilling data - Note that, typically, a user-designed
module 238 will execute using resources in one and only one context. If auser 122 designs a user-designedmodule 238 that includes inputs from more than one context (for instance two wellbore contexts), processing system does not open two contexts to execute that user-designedmodule 238. Instead, theuser 122 could select to use an extra-contextual API or could build a context (provided that theuser 122 has appropriate privileges) incorporating appropriate objects that would otherwise be in the two or more contexts. In some embodiments,processing system 236 provides a user interface that allowsusers 122 to do so. - The validation function can then run and return an indication of the success/failure of the validation(s) attempted. If the validation function fails to validate the parameters (for instance, the user entered an invalid parameter),
method 800 can return toreference 808 and prompt theuser 122 to correct or otherwise modify the list of parameters for the instance of the user-designedmodule 238 being added to the selected context. Otherwise, as illustrated bydecision 812,method 800 can proceed to reference 814 - At
reference 814, the wizard can create the desired instance of the user-designedmodule 238 in the desired context with its in-context and/or extra-contextual parameters validated. In addition, the wizard can save the state of the newly created instance either implicitly or explicitly. Respectively, the saving can be by way of serializing the module instance using the facility(s) provided by the programming language being used or by way of invoking a function ofprocessing system 236 to do so. Ifprocessing system 236 has such a function it could take a form such as saveState(context):object which gets the values of the in-context and extra-contextual parameters and returns an object with property:value pairs representing the state of the object. Thus,method 800 allows acontext building user 122 to add an instance of a user-designedmodule 238 to a context which includes selecting the parameters for that instance of that module whether in-context or extra-contextual. - With respect now to
FIG. 9 , the drawing illustrates a method of executing a drilling data processing job in a context. More particularly, once a user-designedmodule 238 has been instantiated in a particular context by some method such asmethod 800,processing system 236 can begin executing that instance.Method 900 illustrates that the execution of a module instance can begin with initializing the context if it is not initialized or ifuser 122 desires to do so. Seereference 902. Since many user-designedmodules 238 can be designed to wait for the occurrence of an event before executing,method 900 includes waiting for such an event to occur. Seereference 904. If the event has not occurred,method 900 can wait atreference 904 as indicated by the “no” loop. However, if the event occurs,processing system 236 can proceed toreference 906. - It is noted here that in some embodiments, all user-designed
modules 238 are designed to be driven by events. Some user-designed modules are driven by periodic events thatprocessing system 236 fires at some selected frequency. Indeed, some user designedmodules 238 can be designed to be driven by one and only one periodic event so that they execute periodically if desired. Of course, other events can be aperiodic, logical, physical, arising from conditions insystem 100, generated by user-designedmodules 238, etc. Moreover, user-designedmodules 238 of some embodiments include metadata identifying the types of events it will respond to thereby allowingprocessing system 236 to notify these user-designedmodules 238 when pertinent events occur insystem 100. - At
reference 906,processing system 236 of the current embodiment sorts the user-designedmodule 238 instances in the context according to their dependencies. In part,processing system 236 can do so by examining the declarations of the user-designedmodules 238 and determining which in-context user-designedmodule 238 instances depend on other module instances (or other processes) for inputs and other resources with which to operate.Processing system 236 can therefore order those module instances which generate outputs used by other module instances (as inputs) earlier. At some point,processing system 236 settles on a schedule for the execution of the module instances so that each module instance will receive new or updated inputs (and/or other resources) from the other modules (and/or other sources).Processing system 236 therefore orchestrates the execution of the module instances with dependent module instances to be run in series with (and after) the module instances on which they depend.Processing system 236 also schedules the execution of other module instances in parallel or at other times than the dependency-pairs of module instances. - At
reference 908processing system 236 determines whether the scheduling generated atreference 906 is complete. In other words,processing system 236 can check for additional events that might have occurred during the scheduling atreference 906 and re-schedule if desired. Of course,processing system 236 can instead execute the recently generated schedule before checking for additional events which might be waiting to be processed. Either way,processing system 236 begins executing module instances according to the schedule which it arrived at viareferences reference 910. -
Processing system 236 can begin execution with the module instance satisfying the earliest dependency in the schedule and/or module instances which the schedule indicates can execute in parallel therewith.Processing system 236 works its way through the schedule until all of the module instances in it have executed. Seereference 912.Processing system 236 can repeatmethod 900 for each context as might be desired and repeatedly do so until all module instances in all contexts have executed or until processingsystem 236 is paused or stopped by auser 122. In the alternative,processing system 236 can be configured to loiter atreference 904 when no modules are ready to execute waiting for events to happen and then precede throughmethod 900 as desired. Thus,processing system 236 can orchestrate the execution of the various instances of the various user-designed modules 238 (and other processes) through-outsystem 100 not just those associated with a particular drilling structure or a particular context. - In some embodiments though,
processing system 236 does not serialize the user-designedmodules 238 instead processingsystem 236 uses an anarchic model to schedule user-designedmodules 238 for execution. In the current embodiment each user-designedmodule 238 runs on its own schedule executing (in many cases) periodically driven by some periodic scheduling event. Of course, the frequency of execution can be selected and designed into the corresponding scheduling event for any given user-designedmodule 238. For instance, some user-designedmodules 238 can be designed to run at 1 minute intervals, 5 minute intervals, or even faster or slower. Each time through the loop,executor 714 waits for the next periodic scheduling event to fire and then executes those user-designed modules which, according to their event-related metadata, have been designed to execute based on the pertinent scheduling event. Processingsystems 236 of some embodiments include one such loop for each user-designedmodule 238. Again, seereference -
FIG. 10 illustrates a method of executing a drilling data processing module in a context. More particularly,FIG. 10 illustratesmethod 1000 in whichprocessing system 236 executes a particular in-context user-designedmodule 238 instance.Method 1000 can begin by loading the code of the user-designedmodule 238 into memory. The code can take any convenient form such as being a script, a dynamic link library (dll), etc. Seereference 1002.Processing system 236 can also load the saved state of the user-designedmodule 238 instance into memory from persistent storage or can indicate to adata processing system 216 of some drilling structure to do so. Seereference 1004. - At
reference 1006,processing system 236 invokes the user-designedmodule 238 instance within the appropriate context and with its retrieved state. As the user-designedmodule 238 instance executes it accepts inputs and resources from its context (viaprocessing system 236 and various network intermediaries) and generates outputs. Those outputs can take many forms. For instance, some module instances can generatedrilling data 114 and/or 116 in WITSML format for inclusion in a data repository, input/output file 240, and/or persistent storage. Seereference 1008. In addition, or in the alternative, a user-designedmodule 238 instance could generate an HTML formattedoutput 1010 or an event(s) 1012 if theuser 122 designed into user-designedmodule 238 those effects (or side-effects as the case might be).Method 1000 also includes saving the state of the user-designedmodule 238 instance at some point typically during or after the execution of the user-designedmodule 238. The saving of that state can be to some persistent memory if desired. Seereference 1014. -
FIG. 11 illustrates aspects of a user-designed context. More specifically,FIG. 11 illustrates user-designed context 1100 (named byuser 122 as “UDC00007”) which was apparently built to enable processing of data related to the torque and drag of wellbore WB00001. As such it happens to includewellbore object 1102 which corresponds to wellbore WB00001. However, this association was created because thecontext building user 122 chose to placewellbore object 1102 in user-designedcontext 1100 althoughcontext building user 122 could have chosen not to do so. Indeed,user 122 could have built user-designedcontext 1100 from the individual pieces ofdrilling data wellbore object 1102. In addition, or in the alternative,user 122 could have built user-designedcontext 1100 from a subset or a superset of those components or from entirely different sources, objects, etc.User 122 therefore designs such contexts and (via context-based security mechanisms provided by processing system 236) determines the input/output behavior allowed to instances of modules therein by processingsystem 236. - As mentioned previously, user-designed
context 1100 enables processing ofdrilling data context building user 122 included in the design of its modules input connectors (via related declarations) for the following in-context pieces ofdrilling data 114 and 116:hook load 1104,RPM 1106,block height 1108, measureddepth 1110, and (incidentally)gamma ray 1112. Taken together, these inputs enable the user-designed modules in user-designedcontext 1100 to generate torque and drag chart 1114 (see the lower portion ofFIG. 11 ). Indeed, if user-designed modules in user-designedcontext 1100 were to connect to an HTML editing resource they could generate HTML versions of torque anddrag chart 1114 which could be programmed to be e-mailed tovarious users 122. Note that acontext building user 122 could choose to include user-designedcontext 1100 in system 100 (at various locations) as a built-in context such as wellbore context 132 ofFIG. 1 . - Furthermore,
FIG. 11 illustrates other aspects ofsystem 100. For instance, insystem 100 of embodiments user-designed and/or built-in contexts such as user-designedcontext 1100 define a scope. In this manner, “things in a context” are ordinarily containers like wellbores. When you a user queries such user-designedcontexts 1100 for all logs (orother drilling data 114 or 116),system 100 returns all logs in that user-designedcontext 110. For instance, if user-designedcontext 110 corresponds to a wellbore,system 100 returns all logs associated with thatwellbore 112. Similarly, if a user-designedcontext 1100 corresponds to somefield 106,system 100 would return all logs associated with thatfield 106. Thus, if a user-designedcontext 1100 includes logs from twowellbores 112, a query would return both sets of logs. Ordinarily, but not always, user-designedcontexts 1100 correspond to one drilling structure. - Apparently,
user 122 realized that these input pieces ofdrilling data user 122 included in the design of user-designedcontext 1100 clean data module 1115 and declared that each of the foregoing pieces ofdrilling data data module instances 1115A-1115E might exist in user-designedcontext 1100 in various combinations (determined at least in part by the scheduling of their execution). Each instance of clean data module 1115 therefore outputs (via an output connector and associated declaration) a version of (whateverdrilling data user 122 also designed user-designedcontext 1100 to include hook load-clean 1116, RPM-clean 1118, block height-clean 1120, measured depth-clean 1122, and gamma ray-clean 1124 pieces ofoutput drilling data context building user 122 chose to run these jobs in a particular user-designed wellbore context. As a result,executor 714 exposed only thepertinent drilling data - Moreover,
context building user 122 included rig-condition detection user-designedmodule 1126 in user-designedcontext 1100 to aid in generating torque anddrag chart 1114. For inputs,user 122 declared hook load-clean 1116, RPM-clean 1118, and block height-clean 1120 to create corresponding input connectors.User 122 also designed rig-condition detection user-designedmodule 1126 to output computed rig condition report 1128 (in WITSML format as an operations report) as an output piece ofdrilling data user 122 declared this output to create a corresponding connector for rig-condition detection user-designedmodule 1126. Here, declare takes on two meanings. Namely, designatingdrilling data - Furthermore,
user 122 included torque and drag chart maker user-designedmodule 1130 in user-designedcontext 1100. As its inputs,user 122 declared an input for computedrig condition report 1128 and measured depth-clean 1122. Using these inputs, torque and drag maker user-designedmodule 1130 is therefore designed to generate (as an output) torque anddrag chart 1114 thereby providing the desired functionality of user-designedcontext 1100. -
Module authoring user 122, though, might or might not have ensured for the proper ordering of the various instances of user-designedmodules user 122 to ensure proper ordering of these modules would likely be fatal, problematic, or (at least) frustrating tousers 122. Moreover, without clean data, data homogeneity and heterogeneity issues might also have causeduser 122 considerable frustration. Processingsystems 236 of the current embodiment at least partially relievemodule authoring users 122 from burdens associated with these issues. - More particularly,
processing system 236 of some embodiments examines the input, output, etc. declarations ofmodules drilling data modules 1115, 1126, and 1130). For each input,processing system 236 searches for user-designedmodules 238 outputting thesame drilling data 1114 or 1116 (or other sources of the same). Eachtime processing system 236 identifies a process (be it a user-designedmodule 238 or some other source) it orders the execution of that process and its dependent user-designedmodule 238 accordingly. For instance, in the current embodiment,processing system 236 determines that torque and drag user-designedmaker module 1130 is designed to accept computedrig condition report 1128 as an input while rig-condition detection user-designedmodule 1126 outputs the same. Thus,processing system 236 orders the execution of torque and drag chart maker user-designedmodule 1130 after rig-condition detection user-designedmodule 1126. - After analyzing the set of declarations of the
various module instances 1115A-E, 1126, and 1130, insystem 100,processing system 236 of the current embodiment orchestrates their operation so that the instances ofclean data module 1115A-C can operate in parallel but before (the applicable instance of) rig-condition detection user-designedmodule 1126. Similarly,processing system 236 schedules cleandata module instance 1115D before that instance of torque and drag chart maker user-designedmodule 1130 so that in-context measured depth-clean becomes available prior to execution of that in-context instance of torque and drag chart maker user-designedmodule 1130. Thus,FIG. 11 illustrates thatprocessing system 236 of the current embodiment schedules a mixture of potentially parallel and serial instance executions which are derived from the declarations of the various user-designedmodules system 100 if desired). After creating the declarations of such user-designedmodules user 122 did not have to take action to ensure that user-designedmodules 1115, 1126, and 1130 (or rather instances thereof) would execute in such a way as to produce repeatable and reliable results: here torque anddrag chart 1114. Thus,processing system 236 of embodiments allowsusers 122 to design multi-purpose modules without having to concern themselves with scheduling the same in most cases. - In the alternative, or in addition,
processing system 236 could be configured such that all user-designedmodules 238 execute periodically and that user-designedmodules 238 rely on input/output files 240 (seeFIG. 1 ) for their inputs and outputs. In those situations in which one user-designedmodule 238 depends on another user-designedmodule 238 to produce one of its inputs,processing system 236 identifies such dependencies and routes the pertinent output to the input/output file 240 of the dependent user-designedmodule 238. Thus, upon beginning an execution, the dependent user-designedmodule 238 checks its input/output file for pertinent changes. If it finds no differences in its input/output file 240 from when it last executed, user-designed module can return to a dormant state. If, it finds a pertinent change, user-designedmodule 238 can execute accordingly. Moreover, whileFIG. 11 only shows certain pieces ofdrilling data contexts 1100 will include potentially numerous resources associated with some drilling structure such as aparticular wellbore 112. -
FIG. 11 also illustrates that user-designedcontext 110 was set up such that the inputs of one module and the outputs of another happen to be separated by an intermediate dataset (the cleaned versions of thedrilling data -
FIG. 12 illustrates aspects of several particular user-designed contexts. More specifically,FIG. 12 illustrates thatcontext authoring users 122 can include various pieces ofdrilling data contexts context building users 122 can include whole objects (including all of its contents) corresponding to a particular drilling structure (for instance, a wellbore 112) in a user-designed context. More particularly,processing system 236 does not typically impose any a priori constraints on the design of user-designedcontexts Users 122 can place therein any objects,drilling data 114 and/or 116, resources, extra-contextual data, etc. which they feel might be appropriate. Of course, some embodiments provide forprocessing system 236 imposing one-to-one correspondence between drilling structure related objects and user-designed contexts. Thus, for user-designedcontext 1202,user 122 included therein jobs corresponding to clean data module 1115 (five jobs), a job corresponding to rig condition detection user-designedmodule 1126, and a job corresponding to torque and drag chart maker user-designedmodule 1130. Additionally, via the declarations of the modules,user 122 included various pieces of drilling data includinghook load user 122 did so without being required by theprocessing system 236 of the current embodiment to consider or adhere to restrictions associated with hierarchical and/or framework-based approaches - With continuing reference to
FIG. 12 ,user 122 designed this particular user-designedcontext 1204 to includejobs drilling data context 1204. Likewise, user definedcontext 1206 includes jobs corresponding to rig-condition detector user-designedmodule 1126 and torque and drag chart maker user-designedmodule 1130 anddrilling data hook load 1104 and, perhaps,other drilling data context 1208 includes ajob 1216 corresponding to a drilling efficiency report module anddrilling data wells report 1218, a wellbores report 1220 (for the wellbores in the wells listed in the wells report), andvarious operations reports 1222 for the wellbores. - Accordingly,
FIG. 12 illustrates that systems of the current embodiment allowusers 122 to design user-designed contexts with the jobs, inputs, output, resources, etc. whichusers 122 believe will processdrilling data processing system 236 of the current embodiment imposes no limitations on such choices made byusers 122. However,processing system 236 will enforce those user defined contexts as designed byusers 122 while also reducing or eliminating the effects of data homogeneity, data heterogeneity, etc. - Embodiments provide systems and methods for processing drilling data which might exhibit issues related to both data homogeneity and heterogeneity and/or scheduling issues peculiar to drilling structures. Systems of embodiments can build user-designed contexts and/or user-designed modules according to embodiments disclosed herein. Systems of embodiments orchestrate the execution of data processing processes within the contexts and also connect in-context and extra-contextual drilling data to the processes as indicated by declarations of the modules. Thus, users of the systems (and methods) provided herein avoid much, or all, of the cumbersome, error-prone, and inefficient single purpose and/or point-to-point configuration of previously available systems. Embodiments also allow users with context building privileges to set the scope for user-designed modules authored by other users (with module authoring privileges). These author modules are free therefore to access drilling data and other resources within the scope of the contexts within which their modules execute. Other users (without such privileges) are restricted to viewing the results of the in-scope execution of the user-designed modules. Moreover, while the foregoing used drilling data and drilling structures to illustrate aspects of various embodiments, such data processing systems, methods, etc. could be used to process other types of data without departing from the scope of the disclosure.
- Although the subject matter has been disclosed in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts disclosed above. Rather, the specific features and acts described herein are disclosed as illustrative implementations of the claims.
Claims (21)
1-20. (canceled)
21. A system for processing operational data, the system comprising:
a network interface;
a processor in communication with the interface;
the processor being configured to build user-designed contexts for processing operational data wherein the user-designed contexts are defined by user selections of operational objects for inclusion in the user-designed contexts;
the processor being further configured to orchestrate execution of operational data processing modules within the user-designed contexts wherein the order of execution of the modules is determined at least in part by drilling data produced by the modules; and
the processor being further configured to provide a first operational data from a user-designed context to a module via the interface and to accept a second operational data from the module via the interface.
22. A system for processing drilling related data, the system comprising:
a network interface;
a processor in communication with the interface;
the processor being configured to build user-designed contexts for processing drilling data wherein the user-designed contexts are defined by users selections of operational objects for inclusion in the user-designed contexts; and
the processor being further configured to provide a first drilling data from a user-designed context to a module via the interface and to accept a second drilling data from the module via the interface.
23. The system of claim 22 wherein the user-designed context approximately corresponds to a drilling structure.
24. The system of claim 22 wherein the processor is further configured to orchestrate execution of drilling data processing modules within the user-designed contexts wherein the order of execution of the modules is determined at least in part by drilling data produced by the modules.
25. The system of claim 22 wherein the processor is further configured to orchestrate the execution of the modules responsive to a declaration of a module associated with generating the first drilling data.
26. The system of claim 22 wherein the processor is further configured to provide an extra contextual application program interface to the modules.
27. The system of claim 22 wherein the processor is further configured to enforce the user-designed contexts.
28. The system of claim 22 wherein the module executes in the user-designed context and operates on the first drilling data to produce the second drilling data.
29. The system of claim 22 wherein at least one of the user-designed contexts is built in.
30. The system of claim 22 wherein the first drilling data is extra-contextual.
31. A system for processing drilling related data, the system comprising:
a network interface;
a processor in communication with the interface;
the processor being configured to orchestrate execution of drilling data processing modules within user-designed contexts wherein the order of execution of the modules is determined at least in part by drilling data produced by the modules; and
the processor being further configured to provide a first drilling data to a module via the interface and to accept a second drilling data from the module via the interface.
32. The system of claim 31 wherein the processor is further configured to orchestrate the execution of the modules responsive to a declaration of a module associated with generating the first drilling data.
33. The system of claim 31 wherein the module executes in the user-designed context and operates on the first drilling data to produce the second drilling data.
34. The system of claim 31 wherein the processor is further configured to monitor the first drilling data to detect an event and to orchestrate the execution of the modules responsive to detecting the event.
35. The system of claim 31 further comprising a web server in which the processor is located, the interface being to a network wherein the orchestration of the execution of modules within the user-designed contexts is exposed as a service to the modules residing on the network.
36. The system of claim 31 wherein the processor is further configured to accept a modification of one of the modules.
37. The system of claim 36 wherein the processor is further configured to orchestrate the execution of the modules responsive to the modification of the module.
38. The system of claim 37 wherein the modification of the module is such that a drilling data one of the modules depends on is deleted.
39. The system of claim 37 wherein the wherein the modification of the module is such that an availability of the first drilling data changes.
40. The system of claim 31 wherein the first drilling data is extra-contextual.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/677,756 US20150317184A1 (en) | 2012-09-07 | 2015-04-02 | Systems and Methods For Processing Drilling Data |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/606,965 US9024778B2 (en) | 2012-09-07 | 2012-09-07 | Systems and methods for processing drilling data |
US14/677,756 US20150317184A1 (en) | 2012-09-07 | 2015-04-02 | Systems and Methods For Processing Drilling Data |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/606,965 Continuation US9024778B2 (en) | 2012-09-07 | 2012-09-07 | Systems and methods for processing drilling data |
Publications (1)
Publication Number | Publication Date |
---|---|
US20150317184A1 true US20150317184A1 (en) | 2015-11-05 |
Family
ID=50232714
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/606,965 Expired - Fee Related US9024778B2 (en) | 2012-09-07 | 2012-09-07 | Systems and methods for processing drilling data |
US14/677,756 Abandoned US20150317184A1 (en) | 2012-09-07 | 2015-04-02 | Systems and Methods For Processing Drilling Data |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/606,965 Expired - Fee Related US9024778B2 (en) | 2012-09-07 | 2012-09-07 | Systems and methods for processing drilling data |
Country Status (1)
Country | Link |
---|---|
US (2) | US9024778B2 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10776170B2 (en) * | 2016-10-21 | 2020-09-15 | Fujitsu Limited | Software service execution apparatus, system, and method |
Families Citing this family (25)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8210283B1 (en) | 2011-12-22 | 2012-07-03 | Hunt Energy Enterprises, L.L.C. | System and method for surface steerable drilling |
US9297205B2 (en) | 2011-12-22 | 2016-03-29 | Hunt Advanced Drilling Technologies, LLC | System and method for controlling a drilling path based on drift estimates |
US11085283B2 (en) | 2011-12-22 | 2021-08-10 | Motive Drilling Technologies, Inc. | System and method for surface steerable drilling using tactical tracking |
US8596385B2 (en) | 2011-12-22 | 2013-12-03 | Hunt Advanced Drilling Technologies, L.L.C. | System and method for determining incremental progression between survey points while drilling |
US9404356B2 (en) * | 2011-12-22 | 2016-08-02 | Motive Drilling Technologies, Inc. | System and method for remotely controlled surface steerable drilling |
US9024778B2 (en) * | 2012-09-07 | 2015-05-05 | Hugh Winkler | Systems and methods for processing drilling data |
US20150014056A1 (en) * | 2013-07-15 | 2015-01-15 | Ryan Directional Services | Dynamic response apparatus and methods triggered by conditions |
US11106185B2 (en) | 2014-06-25 | 2021-08-31 | Motive Drilling Technologies, Inc. | System and method for surface steerable drilling to provide formation mechanical analysis |
US9957780B2 (en) * | 2014-08-01 | 2018-05-01 | Baker Hughes, A Ge Company, Llc | Oilfield data analytics and decision workflow solution |
US10577894B1 (en) | 2015-06-08 | 2020-03-03 | DataInfoCom USA, Inc. | Systems and methods for analyzing resource production |
US9792571B1 (en) * | 2016-04-14 | 2017-10-17 | Nabors Drilling Technologies Usa, Inc. | Efficiency tracking system for a drilling rig |
CN106121623A (en) * | 2016-08-19 | 2016-11-16 | 太重(天津)重型装备科技开发有限公司 | Safety monitoring control system and well system |
US11933158B2 (en) | 2016-09-02 | 2024-03-19 | Motive Drilling Technologies, Inc. | System and method for mag ranging drilling control |
US11021944B2 (en) | 2017-06-13 | 2021-06-01 | Schlumberger Technology Corporation | Well construction communication and control |
US20180359130A1 (en) * | 2017-06-13 | 2018-12-13 | Schlumberger Technology Corporation | Well Construction Communication and Control |
US11143010B2 (en) | 2017-06-13 | 2021-10-12 | Schlumberger Technology Corporation | Well construction communication and control |
US10782677B2 (en) | 2017-09-25 | 2020-09-22 | Schlumberger Technology Corporation | System and method for network integration of sensor devices within a drilling management network having a control system |
US10866962B2 (en) | 2017-09-28 | 2020-12-15 | DatalnfoCom USA, Inc. | Database management system for merging data into a database |
US10920562B2 (en) | 2017-11-01 | 2021-02-16 | Schlumberger Technology Corporation | Remote control and monitoring of engine control system |
WO2019147689A1 (en) | 2018-01-23 | 2019-08-01 | Baker Hughes, A Ge Company, Llc | Methods of evaluating drilling performance, methods of improving drilling performance, and related systems for drilling using such methods |
GB2584035B (en) * | 2018-03-08 | 2022-11-02 | Landmark Graphics Corp | Using existing servers in a wellbore environment as data sources for streaming servers |
US10705499B2 (en) | 2018-03-30 | 2020-07-07 | Schlumberger Technology Corporation | System and method for automated shutdown and startup for a network |
US10808517B2 (en) | 2018-12-17 | 2020-10-20 | Baker Hughes Holdings Llc | Earth-boring systems and methods for controlling earth-boring systems |
US11907300B2 (en) * | 2019-07-17 | 2024-02-20 | Schlumberger Technology Corporation | Geologic formation operations relational framework |
US11409592B2 (en) | 2020-02-13 | 2022-08-09 | Baker Hughes Oilfield Operations Llc | Methods of predicting electronic component failures in an earth-boring tool and related systems and apparatus |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4806928A (en) * | 1987-07-16 | 1989-02-21 | Schlumberger Technology Corporation | Apparatus for electromagnetically coupling power and data signals between well bore apparatus and the surface |
US5278550A (en) * | 1992-01-14 | 1994-01-11 | Schlumberger Technology Corporation | Apparatus and method for retrieving and/or communicating with downhole equipment |
US5375098A (en) * | 1992-08-21 | 1994-12-20 | Schlumberger Technology Corporation | Logging while drilling tools, systems, and methods capable of transmitting data at a plurality of different frequencies |
US5402068A (en) * | 1988-03-24 | 1995-03-28 | Baker Hughes Incorporated | Method and apparatus for logging-while-drilling with improved performance through cancellation of systemic errors through combination of signals, utilization of dedicated transmitter drivers, and utilization of selected reference signals |
US6237404B1 (en) * | 1998-02-27 | 2001-05-29 | Schlumberger Technology Corporation | Apparatus and method for determining a drilling mode to optimize formation evaluation measurements |
US9024778B2 (en) * | 2012-09-07 | 2015-05-05 | Hugh Winkler | Systems and methods for processing drilling data |
-
2012
- 2012-09-07 US US13/606,965 patent/US9024778B2/en not_active Expired - Fee Related
-
2015
- 2015-04-02 US US14/677,756 patent/US20150317184A1/en not_active Abandoned
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4806928A (en) * | 1987-07-16 | 1989-02-21 | Schlumberger Technology Corporation | Apparatus for electromagnetically coupling power and data signals between well bore apparatus and the surface |
US5402068A (en) * | 1988-03-24 | 1995-03-28 | Baker Hughes Incorporated | Method and apparatus for logging-while-drilling with improved performance through cancellation of systemic errors through combination of signals, utilization of dedicated transmitter drivers, and utilization of selected reference signals |
US5278550A (en) * | 1992-01-14 | 1994-01-11 | Schlumberger Technology Corporation | Apparatus and method for retrieving and/or communicating with downhole equipment |
US5375098A (en) * | 1992-08-21 | 1994-12-20 | Schlumberger Technology Corporation | Logging while drilling tools, systems, and methods capable of transmitting data at a plurality of different frequencies |
US6237404B1 (en) * | 1998-02-27 | 2001-05-29 | Schlumberger Technology Corporation | Apparatus and method for determining a drilling mode to optimize formation evaluation measurements |
US9024778B2 (en) * | 2012-09-07 | 2015-05-05 | Hugh Winkler | Systems and methods for processing drilling data |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10776170B2 (en) * | 2016-10-21 | 2020-09-15 | Fujitsu Limited | Software service execution apparatus, system, and method |
Also Published As
Publication number | Publication date |
---|---|
US20140070956A1 (en) | 2014-03-13 |
US9024778B2 (en) | 2015-05-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9024778B2 (en) | Systems and methods for processing drilling data | |
US10275715B2 (en) | Control variable determination to maximize a drilling rate of penetration | |
US20200165910A1 (en) | System and console for monitoring data stream quality in drilling and production operations at a well site | |
US9608931B2 (en) | Migration assessment for cloud computing platforms | |
US10067755B2 (en) | Model driven customization framework | |
US20210026030A1 (en) | Geologic formation operations framework | |
CN112136292B (en) | System and method for automatic shutdown and startup of a network | |
US20220103499A1 (en) | Notification and task management system | |
Bello et al. | Next generation downhole big data platform for dynamic data-driven well and reservoir management | |
US8942960B2 (en) | Scenario analyzer plug-in framework | |
CA3075754A1 (en) | Data searching, enrichment and consumption techniques using exploration and/or production entity relationships | |
CN112507505A (en) | Method and system for integrated well construction | |
US20240086600A1 (en) | Petro-Technical Global Fluid Identity Repository | |
CN106462415B (en) | Accessing semantic content in a development system | |
US9626392B2 (en) | Context transfer for data storage | |
US11416276B2 (en) | Automated image creation and package management for exploration and production cloud-based applications | |
WO2002026014A2 (en) | Project management system and method | |
US20200272640A1 (en) | Data authentication techniques using exploration and/or production data | |
US11803530B2 (en) | Converting uni-temporal data to cloud based multi-temporal data | |
Kiani Nassab et al. | Well Design and Engineering Process Automation | |
Soni et al. | Deploy a Spring Boot Application Talking to MySQL in AWS | |
WO2021195242A1 (en) | Virtual machine bootstrap agent | |
Zhai et al. | Designing and Developing High-Confidence Petroleum Extraction Cyber-Physical System Using the Model-Driven Architecture | |
US20220391201A1 (en) | Widget delivery workflow system and method | |
Lindholm | IoT-based asset tracking and measurement monitoring platform |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |