FIELD EQUIPMENT SYSTEM

Description

RELATED APPLICATIONS

This application claims priority to and the benefit of a U.S. Provisional Application having Ser. No. 63/557,792, filed 26 Feb. 2024, which is incorporated by reference herein in its entirety.

BACKGROUND

A reservoir may be a subsurface formation that may be characterized at least in part by its porosity and fluid permeability. As an example, a reservoir may be part of a basin such as a sedimentary basin. A basin may be a depression (e.g., caused by plate tectonic activity, subsidence, etc.) in which sediments accumulate. As an example, where hydrocarbon source rocks occur in combination with appropriate depth and duration of burial, a petroleum system may develop within a basin, which may form a reservoir that includes hydrocarbon fluids (e.g., oil, gas, etc.). Various operations may be performed in the field to access such hydrocarbon fluids and/or produce such hydrocarbon fluids. For example, consider equipment operations where equipment may be controlled to perform one or more operations.

SUMMARY

A method may include receiving data from a pump system at a field site; processing the data to generate card format data; detecting an operational condition of the pump system using a machine learning model and the card format data; and, responsive to the detecting, controlling operation of the pump system at the field site. A system may include a processor; memory accessible to the processor; and processor-executable instructions stored in the memory to instruct the system to: receive data from a pump system at a field site; process the data to generate card format data; detect an operational condition of the pump system using a machine learning model and the card format data; and, responsive to detection of the operational condition, controlling operation of the pump system at the field site. One or more computer-readable storage media may include processor-executable instructions to instruct a wellsite computing system to: receive data from a pump system at a field site; process the data to generate card format data; detect an operational condition of the pump system using a machine learning model and the card format data; and, responsive to detection of the operational condition, controlling operation of the pump system at the field site. Various other apparatuses, systems, methods, etc., are also disclosed.

This summary is provided to introduce a selection of concepts that are further described below in the detailed description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in limiting the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of the described implementations may be more readily understood by reference to the following description taken in conjunction with the accompanying drawings.

FIG. 1 illustrates an example system that includes various framework components associated with one or more geologic environments;

FIG. 2 illustrates examples of equipment, an example of a network and an example of a system;

FIG. 3 illustrates example of equipment;

FIG. 4 illustrates an example of pump equipment;

FIG. 5 illustrates an example of a system;

FIG. 6 illustrates an example of a workflow;

FIG. 7 illustrates an example of a workflow and an example of a graphical user interface;

FIG. 8 illustrates an example of a graphical user interface;

FIG. 9 illustrates an example of a graphical user interface;

FIG. 10 illustrates an example of a workflow;

FIG. 11 illustrates an example of a workflow;

FIG. 12 illustrates examples of data;

FIG. 13 illustrates an example of a workflow;

FIG. 14 illustrates an example of a method and an example of a system; and

FIG. 15 illustrates examples of computer and network equipment.

DETAILED DESCRIPTION

This description is not to be taken in a limiting sense, but rather is made merely for the purpose of describing the general principles of the implementations. The scope of the described implementations should be ascertained with reference to the issued claims.

FIG. 1 shows an example of a system 100 that includes a workspace framework 110 that may provide for instantiation of, rendering of, interactions with, etc., a graphical user interface (GUI) 120. In the example of FIG. 1, the GUI 120 may include graphical controls for computational frameworks (e.g., applications) 121, projects 122, visualization 123, one or more other features 124, data access 125, and data storage 126.

In the example of FIG. 1, the workspace framework 110 may be tailored to a particular geologic environment such as an example geologic environment 150. For example, the geologic environment 150 may include layers (e.g., stratification) that include a reservoir 151 and that may be intersected by a fault 153. As an example, the geologic environment 150 may be outfitted with a variety of sensors, detectors, predictors, actuators, etc. For example, equipment 152 may include communication circuitry to receive and to transmit information with respect to one or more networks 155. Such information may include information associated with downhole equipment 154, which may be equipment to acquire information, to assist with resource recovery, etc. Other equipment 156 may be located remote from a wellsite and include sensing, detecting, predicting, emitting or other circuitry. Such equipment may include storage and communication circuitry to store and to communicate data, instructions, etc. As an example, one or more satellites may be provided for purposes of communications, data acquisition, etc. For example, FIG. 1 shows a satellite in communication with the network 155 that may be configured for communications, noting that the satellite may additionally or alternatively include circuitry for imagery (e.g., spatial, spectral, temporal, radiometric, etc.).

FIG. 1 also shows the geologic environment 150 as optionally including equipment 157 and 158 associated with a well that includes a substantially horizontal portion that may intersect with one or more fractures 159. For example, consider a well in a shale formation that may include natural fractures, artificial fractures (e.g., hydraulic fractures) or a combination of natural and artificial fractures. As an example, a well may be drilled for a reservoir that is laterally extensive. In such an example, lateral variations in properties, stresses, etc. may exist where an assessment of such variations may assist with planning, operations, etc. to develop a laterally extensive reservoir (e.g., via fracturing, injecting, extracting, etc.). As an example, the equipment 157 and/or 158 may include components, a system, systems, etc. for fracturing, seismic sensing, analysis of seismic data, assessment of one or more fractures, etc.

In the example of FIG. 1, the GUI 120 shows some examples of computational frameworks, including the DRILLPLAN, PETREL, TECHLOG, PETROMOD, ECLIPSE, and INTERSECT frameworks (SLB, Houston, Texas).

The DRILLPLAN framework provides for digital well construction planning and includes features for automation of repetitive tasks and validation workflows, enabling improved quality drilling programs (e.g., digital drilling plans, etc.) to be produced quickly with assured coherency.

The DRILLOPS framework may execute a digital drilling plan and ensures plan adherence, while delivering goal-based automation. The DRILLOPS framework may generate activity plans automatically individual operations, whether they are monitored and/or controlled on the rig or in town. Automation may utilize data analysis and learning systems to assist and optimize tasks, such as, for example, setting ROP to drilling a stand. A preset menu of automatable drilling tasks may be rendered, and, using data analysis and models, a plan may be executed in a manner to achieve a specified goal, where, for example, measurements may be utilized for calibration. The DRILLOPS framework provides flexibility to modify and replan activities dynamically, for example, based on a live appraisal of various factors (e.g., equipment, personnel, and supplies). Well construction activities (e.g., tripping, drilling, cementing, etc.) may be continually monitored and dynamically updated using feedback from operational activities. The DRILLOPS framework may provide for various levels of automation based on planning and/or re-planning (e.g., via the DRILLPLAN framework), feedback, etc.

The PETREL framework may be part of the DELFI cognitive exploration and production (E&P) environment (SLB, Houston, Texas, referred to as the DELFI environment) for utilization in geosciences and geoengineering, for example, to analyze subsurface data from exploration to production of fluid from a reservoir.

One or more types of frameworks may be implemented within or in a manner operatively coupled to the DELFI environment, which is a secure, cognitive, cloud-based collaborative environment that integrates data and workflows with digital technologies, such as artificial intelligence (AI) and machine learning (ML). As an example, such an environment may provide for operations that involve one or more frameworks. The DELFI environment may be referred to as the DELFI framework, which may be a framework of frameworks. As an example, the DELFI environment may include various other frameworks, which may include, for example, one or more types of models (e.g., simulation models, etc.).

The TECHLOG framework may handle and process field and laboratory data for a variety of geologic environments (e.g., deepwater exploration, shale, etc.). The TECHLOG framework may structure wellbore data for analyses, planning, etc.

The PIPESIM simulator includes solvers that may provide simulation results such as, for example, multiphase flow results (e.g., from a reservoir to a wellhead and beyond, etc.), flowline and surface facility performance, etc. The PIPESIM simulator may be integrated, for example, with the AVOCET production operations framework (SLB, Houston Texas). As an example, a reservoir or reservoirs may be simulated with respect to one or more enhanced recovery techniques (e.g., consider a thermal process such as steam-assisted gravity drainage (SAGD), etc.). As an example, the PIPESIM simulator may be an optimizer that may optimize one or more operational scenarios at least in part via simulation of physical phenomena.

The ECLIPSE framework provides a reservoir simulator (e.g., as a computational framework) with numerical solutions for fast and accurate prediction of dynamic behavior for various types of reservoirs and development schemes.

The INTERSECT framework provides a high-resolution reservoir simulator for simulation of detailed geological features and quantification of uncertainties, for example, by creating accurate production scenarios and, with the integration of precise models of the surface facilities and field operations, the INTERSECT framework may produce reliable results, which may be continuously updated by real-time data exchanges (e.g., from one or more types of data acquisition equipment in the field that may acquire data during one or more types of field operations, etc.). The INTERSECT framework may provide completion configurations for complex wells where such configurations may be built in the field, may provide detailed chemical-enhanced-oil-recovery (EOR) formulations where such formulations may be implemented in the field, may analyze application of steam injection and other thermal EOR techniques for implementation in the field, advanced production controls in terms of reservoir coupling and flexible field management, and flexibility to script customized solutions for improved modeling and field management control. The INTERSECT framework, as with the other example frameworks, may be utilized as part of the DELFI cognitive E&P environment, for example, for rapid simulation of multiple concurrent cases. For example, a workflow may utilize one or more of the DELFI on demand reservoir simulation features.

The aforementioned DELFI environment provides various features for workflows as to subsurface analysis, planning, construction and production, for example, as illustrated in the workspace framework 110. As shown in FIG. 1, outputs from the workspace framework 110 may be utilized for directing, controlling, etc., one or more processes in the geologic environment 150 and, feedback 160, may be received via one or more interfaces in one or more forms (e.g., acquired data as to operational conditions, equipment conditions, environment conditions, etc.).

As an example, a workflow may progress to a geology and geophysics (“G&G”) service provider, which may generate a well trajectory, which may involve execution of one or more G&G software packages.

In the example of FIG. 1, the visualization features 123 may be implemented via the workspace framework 110, for example, to perform tasks as associated with one or more of subsurface regions, planning operations, constructing wells and/or surface fluid networks, and producing from a reservoir.

As an example, a visualization process may implement one or more of various features that may be suitable for one or more web applications. For example, a template may involve use of the JAVASCRIPT object notation format (JSON) and/or one or more other languages/formats. As an example, a framework may include one or more converters. For example, consider a JSON to PYTHON converter and/or a PYTHON to JSON converter. In such an approach, one or more features of a framework that may be available in one language may be accessed via a converter. For example, consider the APACHE SPARK framework that may include features available in a particular language where a converter may convert code in another language to that particular language such that one or more of the features may be utilized. The APACHE SPARK framework also provides an analytics engine for large-scale data processing along with an interface for programming clusters with implicit data parallelism and fault tolerance. As an example, a production field may include various types of equipment, be operable with various frameworks, etc., where one or more languages may be utilized. In such an example, a converter may provide for feature flexibility and/or compatibility.

As an example, visualization features may provide for visualization of various earth models, properties, etc., in one or more dimensions. As an example, visualization features may provide for rendering of information in multiple dimensions, which may optionally include multiple resolution rendering. In such an example, information being rendered may be associated with one or more frameworks and/or one or more data stores. As an example, visualization features may include one or more control features for control of equipment, which may include, for example, field equipment that may perform one or more field operations. As an example, a workflow may utilize one or more frameworks to generate information that may be utilized to control one or more types of field equipment (e.g., drilling equipment, wireline equipment, fracturing equipment, etc.).

While several simulators and frameworks are illustrated in the example of FIG. 1, one or more other simulators and/or frameworks may be utilized, additionally or alternatively. For example, consider the VISAGE geomechanics simulator (SLB, Houston Texas), the KINETIX framework (SLB Houston, Texas), the PETROMOD simulator (SLB, Houston Texas), etc. The VISAGE simulator includes finite element numerical solvers that may provide simulation results such as, for example, results as to compaction and subsidence of a geologic environment, well and completion integrity in a geologic environment, cap-rock and fault-seal integrity in a geologic environment, fracture behavior in a geologic environment, thermal recovery in a geologic environment, CO₂ disposal, etc. As an example, the KINETEX framework (SLB, Houston, Texas) may be utilized, for example, as a well services plug-in for the PETREL framework. The KINETIX framework may provide for multistage completion and stimulation design and production evaluation for conventional and unconventional reservoirs. As an example, the VISAGE geomechanics simulator and the KINETIX framework may be operative coupled (e.g., for running stimulation stresses processes, etc.).

As an example, the PETROMOD framework may be utilized. The PETROMOD framework provides petroleum systems modeling capabilities that may combine one or more of seismic, well, and geological information to model the evolution of a sedimentary basin. The PETROMOD framework may predict if, and how, a reservoir has been charged with hydrocarbons, including the source and timing of hydrocarbon generation, migration routes, quantities, and hydrocarbon type in the subsurface or at surface conditions. The MANGROVE simulator (SLB, Houston, Texas) provides for optimization of stimulation design (e.g., stimulation treatment operations such as hydraulic fracturing) in a reservoir-centric environment. The MANGROVE framework may combine scientific and experimental work to predict geomechanical propagation of hydraulic fractures, reactivation of natural fractures, etc., along with production forecasts within 3D reservoir models (e.g., production from a drainage area of a reservoir where fluid moves via one or more types of fractures to a well and/or from a well). The MANGROVE framework may provide results pertaining to heterogeneous interactions between hydraulic and natural fracture networks, which may assist with optimization of the number and location of fracture treatment stages (e.g., stimulation treatment(s)), for example, to increased perforation efficiency and recovery.

FIG. 2 shows an example of a geologic environment 210 that includes reservoirs 211-1 and 211-2, which may be faulted by faults 212-1 and 212-2, an example of a network of equipment 230, an enlarged view of a portion of the network of equipment 230, referred to as network 240, and an example of a system 250. FIG. 2 shows some examples of offshore equipment 214 for oil and gas operations related to the reservoir 211-2 and onshore equipment 216 for oil and gas operations related to the reservoir 211-1. In the example of FIG. 2, the geologic environment 210 may include fluids such as oil (o), water (w) and gas (g), which may be stratified in the reservoirs 211-1 and 211-2.

In the example of FIG. 2, the equipment 214 and 216 may include one or more of drilling equipment, wireline equipment, production equipment, etc. For example, consider the equipment 214 as including a drilling rig that may drill into a formation to reach a reservoir target where a well may be completed for production of hydrocarbons. As an example, the equipment 216 may include production equipment such as wellheads, valves, pump equipment, gas handling equipment, etc. As an example, one or more features of the system 100 of FIG. 1 may be utilized for operations in the geologic environment 210. For example, consider utilizing a drilling or well plan framework, a drilling execution framework, a production framework, etc., to plan, execute, etc., one or more drilling operations, production operations, etc.

In FIG. 2, the network 240 may be an example of a relatively small production system network. As shown, the network 240 forms somewhat of a tree like structure where flowlines represent branches (e.g., segments) and junctions represent nodes. As shown in FIG. 2, the network 240 provides for transportation of fluid (e.g., oil, water and/or gas) from well locations along flowlines interconnected at junctions with final delivery at a central processing facility (CPF). Where fluid includes solids (e.g., sand, etc.), one or more pieces of equipment may provide for solids removal, collection, etc. The network 240 may include various types of equipment, including surface and/or downhole equipment. Equipment may include powered equipment, which may be powered using one or more power sources. For example, consider electrical power from sources such as a power grid, solar, wind, fuel generator (e.g., gas turbine generator, combustion engine generator, etc.), etc., and/or power from mechanical, hydraulic, etc., sources. As mentioned, equipment may include fluid handling equipment, which may include pumps, which may be driven by one or more power sources. A pump may be a surface pump, a downhole pump, part of a system with surface components and downhole components. As an example, a pump may be a compressor. A compressor may be equipment that may raise pressure of fluid (e.g., air, natural gas, etc.). As an example, a compressor may utilize a positive displacement mechanism to compress fluid to higher pressures so that the fluid may flow via one or more pipelines, etc.

In the example of FIG. 2, various portions of the network 240 may include conduit, which may be in the form of one or more pipelines. For example, consider two conduits which may be a conduit to Man1 and a conduit to Man3 in the network 240, where Man1, Man2 and Man3 are manifolds. In the example of FIG. 2, the manifolds provide for flow of fluid from the various wells (Well_11, Well_12, Well_21 and Well_22) to the CPF. Fluid may be single phase and/or multiphase. The network 240 may include one or more pumps, which may be suitable for single phase fluid and/or multiphase fluid.

As shown in FIG. 2, the example system 250 includes one or more information storage devices 252, one or more computers 254, one or more networks 260 and instructions 270 (e.g., organized as one or more sets of instructions). As to the one or more computers 254, each computer may include one or more processors (e.g., or processing cores) 256 and memory 258 for storing the instructions 270 (e.g., one or more sets of instructions), for example, executable by at least one of the one or more processors. As an example, a computer may include one or more network interfaces (e.g., wired or wireless), one or more graphics cards, a display interface (e.g., wired or wireless), etc. As an example, imagery such as surface imagery (e.g., satellite, geological, geophysical, etc.) may be stored, processed, communicated, etc. As an example, data may include SAR data, GPS data, etc. and may be stored, for example, in one or more of the storage devices 252. As an example, information that may be stored in one or more of the storage devices 252 may include information about equipment, location of equipment, orientation of equipment, fluid characteristics, etc.

As an example, the instructions 270 may include instructions (e.g., stored in the memory 258) executable by at least one of the one or more processors 256 to instruct the system 250 to perform various actions. As an example, the system 250 may be configured such that the instructions 270 provide for establishing a framework, for example, that may perform network modeling (see, e.g., the PIPESIM framework of the example of FIG. 1, etc.) and/or other modeling. As an example, one or more methods, techniques, etc. may be performed using one or more sets of instructions, which may be, for example, the instructions 270 of FIG. 2. As an example, the instructions 270 may include instructions for one or more of monitoring one or more portions of the network of equipment 230, controlling one or more portions of the network of equipment 230, receiving data from one or more portions of the network of equipment 230, etc.

As an example, various graphics in FIG. 2 may be part of a graphical user interface (GUI) that may be generated using executable instructions that may be executable locally and/or remotely using local and/or remote display devices (e.g., a mobile device, a workstation, etc.).

FIG. 3 shows examples of equipment 310, 330, 350 and 370 that may be utilized in the field to move fluid. As an example, the geologic environment 150 of FIG. 1 and/or the geologic environment 210 of FIG. 2 may include one or more instances of the examples of equipment 310, 330, 350 and 370. As shown, the equipment 310 may include gas-lift equipment, the equipment 330 may include sucker rod pump equipment, the equipment 350 may include electric submersible pump (ESP) equipment, and the equipment 370 may include progressive cavity pump (PCP) equipment.

In FIG. 3, the equipment 310, 330, 350 and 370 may be artificial lift equipment, where one or more controllers 312, 332, 352 and 372 may be included with the equipment 310, 330, 350 and 370 and/or operatively coupled to the equipment 310, 330, 350 and 370. In such an example, one or more features of the system 250 may be included in the one or more controllers 312, 332, 352 and 372 and/or operatively coupled to the one or more controllers 312, 332, 352 and 372.

Artificial lift equipment may add energy to a fluid column in a wellbore with the objective of initiating and/or improving production from a well. Artificial lift systems may utilize a range of operating principles (e.g., rod pumping, gas lift, electric submersible pumps, etc.). As such, artificial lift equipment may operate through utilization of one or more resources (e.g., fuel, electricity, gas, etc.).

Gas lift is an artificial-lift method in which gas is injected into production tubing to reduce hydrostatic pressure of a fluid column. The resulting reduction in bottomhole pressure allows reservoir liquids to enter a wellbore at a higher flow rate. In gas lift, injection gas may be conveyed down a tubing-casing annulus and enter a production train through a series of gas-lift valves. In such an approach, a gas-lift valve position, operating pressure and gas injection rate may be operational parameters (e.g., determined by specific well conditions, etc.).

A sucker rod pump is an artificial-lift pumping system that uses a surface power source to drive a downhole pump assembly. For example, a beam and crank assembly may create reciprocating motion in a sucker rod string that connects to a downhole pump assembly. In such an example, the pump may include a plunger and valve assembly to convert the reciprocating motion to vertical fluid movement. As an example, a sucker rod pump may be driven using electricity and/or fuel. For example, a prime mover of a sucker rod pump may be an electric motor or an internal combustion engine.

An ESP is an artificial-lift system that utilizes a downhole pumping system that is electrically driven. In such an example, the pump may include staged centrifugal pump sections that may be specifically configured to suit production and wellbore characteristics of a given application. ESP systems may provide flexibility over a range of sizes and output flow capacities.

A PCP is a type of a sucker rod-pumping unit that uses a rotor and a stator. In such an approach, rotation of a rod by means of an electric motor at surface causes fluid contained in a cavity to flow upward. A PCP may be referred to as a rotary positive-displacement unit.

In the examples of FIG. 3, one or more sensors may be included. For example, consider a gauge coupled to a downhole end of an ESP where signals from sensors of the gauge may be transmitted to surface equipment using a power cable and/or a dedicated gauge cable. For example, consider the PHOENIX gauge (SLB, Houston, Texas), which include sensors that may measure intake pressure, temperature, motor oil temperature, winding temperature, vibration, current leakage and/or pump discharge pressure. A gauge may be operatively coupled to a controller, which may, for example, provide controls for backspin of an ESP, sanding of an ESP, flux of an ESP and gas related issues of an ESP. For example, during operation where sand is present (e.g., suspended solid matter, etc.), sand may accumulate in one or more stages of an ESP where a control scheme may act to rid the ESP of at least a portion of the sand.

As an example, a PCP may be suitable for use in production for wells characterized by highly viscous fluid and high sand cut where the PCP has some sand-lifting capability. However, sand may accumulate where a control scheme may be utilized to rid the PCP of at least a portion of the sand.

As an example, a sucker rod pump may be operable via as a stroke-through pump to release sand and other material. In such an example, to minimize damage to a plunger and barrel, a grooved-body plunger may be used to catch and carry the sand away from those components.

As an example, gas lift equipment may be utilized in applications where abrasive materials, such as sand, may be present and may be used in low-productivity, high-gas/oil ratio-wells or deviated wellbores. As an example, gas lift equipment such as pocketed mandrels may utilize slickline-retrievable gas lift valves, which may be pulled and replaced without disturbing tubing.

As an example, equipment may include water flooding equipment. For example, consider an enhanced oil recovery (EOR) process in which a small amount of surfactant is added via appropriate equipment to an aqueous fluid injected to sweep a reservoir. In such an example, presence of surfactant reduces the interfacial tension between oil and water phases and may also alter wettability of reservoir rock (e.g., to improve oil recovery). In such an example, movement of fluid (e.g., oil and/or water) and/or presence of surfactant may carry particles of the reservoir rock to a production well or production wells where such particles (e.g., sand) may result in a sand event, whether one or more of the production well or wells include artificial lift equipment or not. As water flooding becomes more prevalent globally, an increase in sand related issues may be expected (e.g., sand influx into production wells).

As an example, equipment may include a choke or chokes, which may include a surface choke and/or a downhole choke. A choke is a device that includes an orifice that may be used to control flow of fluid through the orifice, for example, to control fluid flow rate, downstream system pressure, etc. Chokes are available in various configurations, which include fixed and adjustable chokes. An adjustable choke enables fluid flow and pressure parameters to be changed as desired (e.g., for process, production, etc.).

An adjustable choke includes a valve that may be adjusted to control well operations, for example, to reduce pressure of a fluid from high pressure in a closed wellbore to atmospheric pressure. An adjustable choke valve may be adjusted (e.g., fully opened, partially opened or closed) to control pressure drop. As an example, an adjustable choke may be manually adjustable or adjustable via a controller that may be integral to or operatively coupled to the adjustable choke. A controller for an adjustable choke may respond to locally generated and/or remotely generated signals.

A downhole choke or bottom hole choke may be a downhole device used to control fluid flow under downhole conditions. As an example, a downhole choke may be removable via slickline intervention where the downhole choke may be located in a landing nipple in a tubing string. In some scenarios, a downhole chock may be used as a flow regulator and to take part of the pressure drop downhole, which may help to reduce potential of hydrate issues.

As an example, a system may be a pump system that includes one or more mechanisms to reciprocate a rod string where the rod string may include rods that are joined via couplings. For example, a rod may include opposing threaded ends, which may be referred to as pins, where each of the ends may be threaded into mating threads of a coupling. In such an example, a long rod string may be assembled that is made up of a series of rods where the rods are joined by couplings. Such a rod string may be meters in length.

As an example, a rod may be a sucker rod. A sucker rod may be a steel rod that is used to make up a mechanical assembly between the surface and downhole components of a rod pumping system. As an example, a sucker rod may be a non-standardized length or a standardized length. As an example, a standardized length of a sucker rod may be in a range from about 25 ft to about 30 ft (e.g., about 7 m to about 9 m).

As an example, a pumping system may be an artificial-lift pumping system that may be powered using a surface power source to drive a downhole pump assembly. As an example, a pumping system may include a beam and crank assembly that creates reciprocating motion in a rod string that connects to the downhole pump assembly. In such an example, the downhole pump assembly may include a plunger and valve sub-assembly that may convert reciprocating motion to vertical fluid movement.

As an example, an electric motor may be utilized to reciprocate a rod string, optionally via one or more belt or chain drives. For example, a belt driven pumping unit may include a belt that is coupled to a rod string for reciprocating the rod string vertically within a well as the belt is driven by an electric motor. As an example, a pump may be a sucker rod pump that includes a sucker rod string.

FIG. 4 shows an example of a system 400 that includes a pump assembly 401 as driven by a pump drive system 404 that is operatively coupled to a controller 422. In the example of FIG. 4, the pump assembly 401 and drive system 404 are arranged as a beam pump. As shown in FIG. 4, a walking beam 438 reciprocates a rod string 444 that includes a polished rod portion 446 that may move in a bore of a stuffing box 450 of a well head assembly that includes a discharge port in fluid communication with a flowline 452. The rod string 444 may be suspended from the walking beam 438 via one or more cables 442 hung from a horse head 440 for actuating a downhole pump 410 of the pump assembly 401 where the downhole pump 410 is positioned in a well 402, for example, near a bottom 412 of the well 402.

A well in a subterranean environment may be a cased well or an open well or, for example, a partially cased well that may include an open well portion or portions. In the example of FIG. 4, the well 402 includes casing 406 that defines a cased bore where tubing 408 is disposed in the cased bore. As shown, an annular space may exist between an outer surface of the tubing 408 and an inner surface of the casing 406.

In the example of FIG. 4, the walking beam 438 is actuated by a pitman arm (or pitman arms), which is reciprocated by a crank arm (or crank arms) 434 driven by a prime mover 430 (e.g., electric motor, etc.). As shown, the prime mover 430 may be coupled to the crank arm 434 through a gear reduction mechanism, such as gears of a gearbox 432. As an example, the prime mover 430 may be a three-phase AC induction motor that may be controlled via circuitry of the controller 422, which may be connected to a power supply. The gearbox 432 of the pump drive system 404 may convert electric motor torque to a low speed, high torque output for driving the crank arm 434. The crank arm 434 may be operatively coupled to one or more counterweights 442 that serve to balance the rod string 444 and other equipment as suspended from the horse head 440 of the walking beam 438. A counterbalance may be provided by an air cylinder such as those found on air-balanced units.

The downhole pump 410 may be a reciprocating type pump that includes a plunger 416 attached to an end of the rod string 444 and a pump barrel 414, which may be attached to an end of the tubing 408 in the well 402. The plunger 416 may include a traveling valve 418 and a standing valve 420 positioned at or near a bottom of the pump barrel 414. During operation, for an up stroke where the rod string 444 translates upwardly, the traveling valve 418 may close and lift fluid (e.g., oil, water, etc.) above the plunger 416 to a top of the well 402 and the standing valve 420 may open to allow additional fluid from a reservoir to flow into the pump barrel 414. As to a down stroke where the rod string 444 translates downwardly, the traveling valve 418 may open and the standing valve 420 may close to prepare for a subsequent cycle. Operation of the downhole pump 410 may be controlled such that a fluid level is maintained in the pump barrel 414 where the fluid level may be sufficient to maintain the lower end of the rod string 444 in the fluid over its entire stroke.

As an example, the system 400 may include a beam pump system. As explained, a prime mover may rotate a crank arm, whose movement is converted to reciprocal movement through a beam. The beam may include counterweights or a compressed air cylinder to help reduce load on the beam pump system during the upstroke. The beam may be attached to a polished rod by cables hung from a horsehead at the end of the beam. The polished rod may pass through a stuffing box and be operatively coupled to the rod string. As explained, the rod string may be lifted and lowered within the production tubing of a cased well by the reciprocal movement of the beam, enabling the downhole pump to capture and lift formation fluid(s) in a direction toward surface (e.g., with a flow vector component against gravity) in the tubing and through a pumping tee that directs the fluid into a flowline.

As an example, the prime mover may be an internal combustion engine or an electric motor that provides power to the pumping unit. As an example, a prime mover may deliver high-speed, low-torque power to a gear reducer, which converts that energy into the low-speed, high-torque energy utilized by the surface pump. As shown in FIG. 4, a beam pumping unit, beam pump system or merely beam pump, converts the rotational motion of the prime mover into a reciprocating vertical motion that lifts and lowers a rod string connected to a subsurface pump.

Some aspects of a system may include prime mover type; pumping unit size, stroke length and speed setting; rod and tubing diameter; and downhole pump diameter, for example, based at least in part on reservoir fluid composition, wellbore fluid depth and reservoir productivity.

As an example, a design framework may facilitate some decisions as to design, for example, to arrive at a desired pump speed to attain production targets without overloading the system or overwhelming the formation's ability to deliver fluids to a wellbore.

Beam pumps may be constructed in a variety of sizes and configurations. Some systems include design aspects that may aim to better manage torque, rod wear and/or footprint. For example, as to some design aspects, consider locating counterweights on the crank arm or on the beam and use of compressed air rather than weight to assist in load balancing. Further examples may involve changes to crank, gear reducer and motor position relative to the beam, as well as alternative beam designs, where such factors may change system loading.

As an example, a system may place heavier rods, or sinker bars, in the lower section of the rod string to keep the rod string in tension, which reduces buckling and may help prevent contact with the tubing wall. Rod strings may also include stabilizer bars between sinker bars to centralize the rods, further reducing tubing wear.

Rod guides, which may be made of reinforced plastics, may be molded onto steel rods at depths where engineers may predict the rods will experience side loading due to a deviated wellbore path. The guides may act like bearings between the tubing wall and the rod to prevent rod and tubing wear. Sliding guides may be able to move between molded guides during the pump cycle, aiding production by scraping paraffin from the tubing wall, which helps prevent well plugging. A rod rotator or tubing rotator may be used to rotate the rod a small fraction of a revolution on each stroke of the pumping unit to further extend rod string life. As an example, slow rotation of rod guides may help scrape paraffin from the tubing wall.

Sucker rods may be connected to the surface pumping unit by a polished rod. A polished rod, for example, made of standard alloy steel and hard-surface spray metal coating, may support loads created during a pump cycle and help to ensure a seal through a stuffing box at a top of a well. The stuffing box may be attached to a wellhead or pumping tee and may form a low-pressure tight seal against a polished rod. The seal may form a barrier between a well and atmosphere and may allow flow to be diverted into a flowline, for example, via a pumping tee.

A dynamometer is an instrument used in sucker-rod pumping to record the variation between the polished rod load and the polished rod displacement. A dynamometer card (e.g., dynacard) is a record made by a dynamometer. An analysis of dynamometer measurements may reveal a defective pump, leaky tubing, inadequate balance of the pumping unit, a partially plugged mud anchor, gas locking of the pump or an undersized pumping unit. A dynamometer card may be in the form of a graph, such as a dynagraph (e.g., a dynacard graph). As an example, a dynacard or dynagraph may be generated in digital form, for example, as a digital image.

FIG. 4 also shows a surface condition plot 452 and a downhole condition plot 454, which are plots of load versus distance with respect to time, for example, with respect to one or more cycles of a pump such as a sucker-rod pump.

As to the downhole condition plot 454, as mentioned, it may be based on a model. Such a model may include various types of factors such as, for example, velocity of sound in a rod, modulus of elasticity of the material of rods, length of a rod string, number of increments in position, number of discretization in time, pump velocity (e.g., cycles per minute, stroke per minute, etc.), rod stroke length, rod diameter, specific weight of rod material, a factor of dimensionless damping, specific gravity of fluid, diameter of tubing, etc.

As an example, a dynamometer card may exhibit shape variations, which may facilitate behavior and/or condition identification and/or control. For example, shapes may correspond to dynamic issues such as a perfect trace, rod stretch, partial pump fill, acceleration and harmonics, low filage, tapping down, tapping up, worn barrel, delayed traveling valve (tv) sensing, bad tv, bad standing valve (sv), pounding hard, gas lock or bad sv, deep rod part, excessive harmonics, high fluid level, excessive friction, excessive rod stretch, stuck pump, bad position signal, bad load signal or galded pump, etc. The foregoing types of issues may depend on equipment specifics, site specifics, etc., noting that one or more other types of issues may be identified using pump equipment data.

In the example of FIG. 4, some examples of data and associated behaviors are shown, which include data indicative of pound behavior 455, data indicative of tag behavior 456, data indicative of gas interference (GI) behavior 457 and data indicative of normal behavior 458.

As an example, a sucker rod pump may exhibit behavior such as fluid pound. In fluid pound, each impact load imparted to the pump's plunger causes the rods to buckle and hit the tubing where high load impacts, which beat out the traveling valve (tv) ball and seat, may causes the pump's valve rod to buckle creating side-loading of the plunger onto the barrel where stresses imparted in the rod may drastically increase rod loading and reduce the rod life. Further, impact load may eventually transmit up the rod-string and damage tightly inter-locking teeth in a gearbox.

As an example, a sucker rod pump may exhibit behavior such as gas interference. While gas interference (or gas pound) is in many regards similar to fluid pound, it does not create nearly the same type of impact load; however, volumetrically it may be just as inefficient. And, due to the inefficiency, in the presence of gas interference, additional strokes may be required that may be quite damaging to the equipment. Also, gas that enters a pump eventually makes its way up the tubing string, which may be a cause of stuffing box leaks. Gas interference may make pump performance erratic.

As an example, a sucker rod pump may exhibit behavior such as pump tagging, which may be referred to simply as tagging. Tagging may occur deliberately, for example, where a pump is spaced such that at the bottom of the stroke, actual contact, that tends to be light, is made between the plunger and the bottom of the pump. While some light pump tagging may have a place in the oilfield, tagging may be a behavioral issue, particularly where tagging is beyond “light”. As to what is a “light” tag, that may be subjective when handled by a human, particularly a human that may not have the level of knowledge of a subject matter expert (SME), which may be a domain expert. For example, a human may report that a well has a “light” tag where it might feel “light” at surface, but it is not known how “light” the tag actually is downhole, which may be a considerable distance downhole (e.g., hundreds of meters or more). And when not periodically monitored, a “light” tag may become a little heavier a couple weeks later. As fiberglass rod strings absorb much of the tag and do not transmit the shock wave vertically as effectively as steel does, a “light” tag on a fiberglass rod well might be twice as hard as “light” tag on a steel rod string. Tagging may be destructive to a pump, rods and tubing, along with reducing downhole plunger travel. Tagging behavior may be associated with inefficiency, for example, where a pump may lose a certain percentage of its total downhole stroke-length as a result of the tag. Also, pump tagging tends to hammer the pump into the seating nipple (e.g., making it more difficult to unseat next pull).

While details of a particular type of equipment are shown in FIG. 4, other types of equipment may have their own associated details, which may include features that may be alternative to, additional to, different than, etc., the features of the system 400 of FIG. 4. And, while pumps are mentioned, as explained, field equipment may include equipment other than pumps or additional to one or more pumps.

Prognostic health monitoring for sucker rod pumps (SRPs) tends to be performed manually, and therefore may be prone to human error. As an example, a framework may utilize machine learning (ML) (e.g., more generally artificial intelligence (AI)) to detect issues in field equipment in real-time and, for example, provide an internal cloud-based dashboard for data analysis.

As an example, a framework may provide for SRP operations diagnosis solutions (ODS). As an example, such a framework may be implemented as part of or operatively coupled to one or more other framework and/or a framework environment (e.g., consider the DELFI environment). As an example, a framework may implement one or more techniques that may be available, for example, via a data science platform that may include various libraries (e.g., consider the DATAIKU platform, Paris, France). As an example, a framework may provide for an integrated end-to-end DELFI and DATAIKU-based pipeline for monitoring and/or controlling SRP operations. As an example, a framework may utilize machine learning and computer vision to identify one or more of various operating conditions with acceptable accuracy and reliability by ingesting field data, evaluating one or more ML models and, for example, performing one or more other tasks that may involve monitoring and/or control. For example, consider displaying an interactive visual dashboard to review issues in real-time and/or for issuance of one or more control instructions, which may be performed via such a dashboard, etc. As an example, a framework may help to reduce costs for maintenance and energy consumption as one or more mitigation workflows may be triggered, for example, earlier than with manual analysis. As an example, a framework may operate to reduce non-productive time (NPT) and/or to reduce human error.

As an example, a framework may provide for entity alignment toward one or more sustainable development strategies that may contribute toward energy demands of one or more service regions. As explained, the DELFI environment may be utilized, which may include and/or operatively coupled to one or more production operations frameworks (e.g., a DELFI-ProdOps ecosystem), which may diminish demands as to reliance on one or more third-party cloud services or platforms. As an example, a framework may be part of a practical system deployable on premises.

As an example, a framework may include an embedded ensemble machine learning component, modeling and inference pipelines, data ingestion workflows and interactive visualization dashboards. Such features may be provided within a product suite and, for example, offered as a subscription-based software as a service (SaaS) to one or more entities.

As an example, a framework may help to reduce environmental impact of one or more SRP systems and to generate associated savings, which may help contribute toward building a sustainable energy infrastructure. As an example, a framework may be adopted over a manual well analysis and calibration approach to effectively reduce action response time with agile decision-making, which may number of instances of downtime, downtime, and/or number of failures. As an example, a framework may provide for time savings of the order of 5 hours to 10 hours per week per instance.

As explained, an SRP ODS may be provided as an integrated end-to-end framework environment and data science platform pipeline (e.g., DELFI and DATAIKU-based pipeline) for monitoring and/or controlling SRP operations. As explained, such a framework may implement machine learning (ML) based computer vision (CV) techniques that may help to identify well operating conditions with acceptable accuracy and reliability. As an example, an ODS framework may be embedded within the DELFI environment and leverage the DATAIKU platform and, for example, the SPOTFIRE platform (Somerville, Massachusetts), to automate SRP operation diagnosis by ingesting field data, evaluating ML models and displaying an interactive visual dashboard for identifying and responding to well issues in real-time. As to the SPOTFIRE platform, it includes features such as natural language query (NLQ) powered search, Al-driven recommendations, and model-based processing.

As an example, a framework may provide for operationalizing one or more workflows that may act to mask data handling and underlying ML components in a manner that facilitates use, which may expedite taking of mitigative actions. As an example, an SRP ODS framework may be operable to detect whether a pump is operating normally or exhibiting an issue, such as, for example, fluid pound behavior. As an example, a framework may ingest field pump sensor data (e.g., using DATAIKU platform plugins and connectors from one or more entity databases). As an example, a dataset may include surface and downhole load and position values for individual pumps which may be preprocessed, checked for quality, and converted to images, termed as cards (see, e.g., pump cards, dynacards, etc.). As an example, such cards may be passed through a transfer learning-based CV model to diagnose one or more pump issues. As an example, a CV model may implement supervised learning, for example, as trained on SME approved and labeled pump cards. As an example, one or more inferences from a CV model may include a class indicating well operating condition and a corresponding probability value, which may be generated at an appropriate frequency (e.g., 1 Hz, etc.) as sensor data are streamed (e.g., received). Such results may be processed using one or more features of the SPOTFIRE platform to provide an interactive visual dashboard (e.g., for local and/or remote viewing). As an example, a dashboard may include features for generation, presentation, and interaction with operational summaries, performance indicators (PIs), metrics and card images, which may be assessed by one or more engineers to reference and/or evaluate. As an example, a framework may provide features for well-based and/or time-based filters, for example, for in-depth operational and trend analysis.

As an example, a framework may be robust, flexible, reusable and scalable to integrate new wells. As an example, an SRP ODS framework may be implemented effectively for identifying issues, reducing maintenance costs and energy consumption for pump controllers. As an example, an SRP ODS framework implementation provided ML-based diagnoses in real-time, with an average response time of 0.4 seconds. Such an implementation reduced turnaround time for detecting rod pump issues in various wells from 1-3 days to a few minutes. As explained, a framework may provide for visualization, interactions, control, etc., which may help to reduce NPT (e.g., saving an estimated 5-10 hours per installation per week).

As an example, a framework may have capacity to run, update and tune well models in a relatively constant manner to check well potentials, considering a holistic approach of reservoir diagnostics and artificial lift surveillance by using a cognitive and collaborative environment. In such an example, an entity (e.g., operator, etc.) may readily identify one or more optimization opportunities in an expedited manner.

FIG. 5 shows an example of a system 500 and an example of an architecture 501 where the system 500 may include various local components that may be in communication with one or more remote components. FIG. 5 also shows an example where multiple instances of the system 500 may be deployed, for example, as indicated by systems 500-1, 500-2, 500-3, 500-4, and 500-N, where N may be a number that represents a number of different equipment installations in one or more fields. In such an example, the instances of the system 500 may include common features, which may provide for computational capabilities, memory capabilities, networking capabilities, etc., noting that local environments, local operations, local conditions, etc., may differ for the various instances of the systems 500-1, 500-2, 500-3, 500-4, and 500-N, such that a framework-based approach may provide for tailoring monitoring and/or control at each site. For example, equipment at one site may experience one type of issue that may not be experienced at one or more other sites. Hence, a system may be operated in a reflective manner that reflects one or more issues that may occur, be expected to occur, etc., at a site. Accordingly, a system of the systems 500 may be operable in a flexible manner, an extensible manner, etc., such that individual sites are appropriately monitored and/or controlled, which may be, at least in part, via computational resources at one or more remote sites, which may be in communication via wired and/or wireless technologies. For example, consider the one or more remote sites 552 and 554 as examples that may provide for cloud platform resources, etc. In such an example, updates, tailoring, etc., may occur in the cloud while deployment and implementation of monitoring and control by an instance of the system 500 occurs in the field. As an example, overarching computational resources may provide for dynamic operations in the field, which may include selecting, building, deploying, implementing, etc., one or more models responsive to data acquired from the field. In such an example, an approach may provide for group learning and individual learning where group learning may benefit a group of systems and where individual learning may benefit individual systems in a tailored manner (e.g., according to receipt of field data, feedback, etc.).

As shown in the example of FIG. 5, the architecture 501 may provide for one or more security components 502, one or more machine learning models 503, data 504, objects 505, classification and/or prediction techniques 506 (e.g., recognition, detection, classification, prediction, etc.), analysis techniques 507 and output(s) 508. In the example of FIG. 5, the architecture 501 may be tailored for one or more instances of the system 500. For example, one or more ML models 503 may be tailored for one or more tasks such as classification and/or prediction to address one or more issues that may have occurred and/or be expected to occur, for example, with a level of confidence above a threshold, at one or more sites. In such an example, where an issue may be unlikely to occur at a site, an instance of the system 500 at that site may forego implementation of one or more associated ML models, predictors, classifiers, etc. As an example, a system of instances of the systems 500 may be dynamically optimized in an approach that involves continual learning such that heterogeneous and/or homogeneous equipment installations in one or more fields may be appropriately monitored and/or controlled.

As an example, the system 500 may be operatively coupled to one or more types of equipment, which may include one or more pumps and/or one or more non-pump equipment. While examples in FIG. 5 illustrate SRPs, one or more other types of pumps may be subject to monitoring and/or control using an instance of the system 500. As an example, the instances of the system 500-1, 500-2, 500-3, 500-4, and 500-N may be for a mix of equipment, which may include different types of pumps and/or different sets-ups, manufacturers, ages, etc., of a common type of pump. For example, consider an SRP made by one manufacturer installed at one site and an SRP made by another manufacturer installed at another, different site where, for example, an instance of the system 500 may be present at each of the sites and operable in a common manner and/or in a tailored manner with respect to the SRPs at the sites. As an example, the system 500 may operate as a controller, a motor controller, etc., and/or provide information to a controller, a motor controller, etc.

As shown, the system 500 may include a power source 513 (e.g., solar, generator, batter, grid, etc.) that may provide power to an edge framework gateway 510 that may include one or more computing cores 512 and one or more media interfaces 514 that can, for example, receive a computer-readable medium 540 that may include one or more data structures such as an operating system (OS) image 542, a framework 544 and data 546. In such an example, the OS image 542 may cause one or more of the one or more cores 512 to establish an operating system environment that is suitable for execution of one or more applications. For example, the framework 544 may be an application suitable for execution in an established operating system in the edge framework gateway 510.

In the example of FIG. 5, the edge framework gateway 510 (“EF”) may include one or more types of interfaces suitable for receipt and/or transmission of information. For example, consider one or more wireless interfaces that may provide for local communications at a site such as to one or more pieces of local equipment, which may include equipment 532, equipment 534 and equipment 536 and/or remote communications to one or more remote sites 552 and 554. In such an example, lesser or more equipment may be included.

As an example, the equipment 532, 534 and 536 may include one or more types of equipment such as, for example, one or more instances of the equipment 310, the equipment 330, the equipment 350 and the equipment 370 of FIG. 3. As an example, equipment may include non-artificial lift equipment and/or artificial lift equipment.

As an example, the EF 510 may be installed at a site where the site is some distance from a city, a town, etc. In such an example, the EF 510 may be accessible via a satellite communication network and/or one or more other networks where data, control instructions, etc., may be transmitted, received, etc.

As an example, one or more pieces of equipment at a site may be controllable locally and/or remotely. For example, a local controller may be an edge framework-based controller that may issue control instructions to local equipment via a local network and a remote controller may be a cloud-based controller or other type of remote controller that may issue control instructions to local equipment via one or more networks that reach beyond the site. As an example, a site may include features for implementation of local and/or remote control. As an example, a controller may include an architecture such as a supervisory control and data acquisition (SCADA) architecture.

Satellite communication tends to be slower and more costly than other types of electronic communication due to factors such as distance, equipment, deployment and maintenance. For wellsites that do not have other forms of communication, satellite communication may be limiting in one or more aspects. For example, where a controller is to operate in real-time or near real-time, a cloud-based approach to control may introduce too much latency.

As shown in the example of FIG. 5, the EF 510 may be deployed where it may operate locally with the one or more pieces of equipment 532, 534 and 536, etc. As an example, the EF 510 may include switching and/or communication capabilities, for example, for information transmission between equipment, etc.

As desired, from time to time, communication may occur between the EF 510 and one or more remote sites 552, 554, etc., which may be via satellite communication where latency and costs are tolerable. As an example, the CRM 540 may be a removable drive that may be brought to a site via one or more modes of transport. For example, consider an air drop, a human via helicopter, plane, boat, etc.

As explained with respect to FIG. 5, an EF may execute within a gateway such as, for example, an AGORA gateway (SLB, Houston, Texas), which may include one or more processors, memory, etc., which may be deployed as a “box” that may be locally powered and that may communicate locally with other equipment via one or more interfaces. As an example, one or more pieces of equipment may include computational resources that may be akin to those of an AGORA gateway or more or less than those of an AGORA gateway. As an example, an AGORA gateway may be a network device with various networking capabilities.

As an example, a gateway may include one or more features of an AGORA gateway (e.g., v.202, v.402, etc.) and/or another gateway. For example, consider features such as an INTEL ATOM E3930 or E3950 dual core with DRAM and an eMMC and/or SSD. Such a gateway may include a trusted platform module (TPM), which may provide for secure and measured boot support (e.g., via hashes, etc.). A gateway may include one or more interfaces (e.g., Ethernet, RS485/422, RS232, etc.). As to power, a gateway may consume less than about 100 W (e.g., consider less than 10 W or less than 20 W). As an example, a gateway may include an operating system (e.g., consider LINUX DEBIAN LTS or another operating system). As an example, a gateway may include a cellular interface (e.g., 4G LTE with global modem/GPS, 5G, etc.). As an example, a gateway may include a WIFI interface (e.g., 802.11 a/b/g/n). As an example, a gateway may be operable using AC 100-240 V, 50/60 Hz or 24 VDC. As to dimensions, consider a gateway that has a protective box with dimensions of approximately 10 in×8 in×4 in (e.g., 25 cm×20.3 cm×10.1 cm).

As an example, a gateway may be part of a drone. For example, consider a mobile gateway that may take off and land where it may land to operatively couple with equipment to thereby provide for control of such equipment. In such an example, the equipment may include a landing pad. For example, a drone may be directed to a landing pad where it may interact with equipment to control the equipment. As an example, a wellhead may include a landing pad where the wellhead may include one or more sensors (e.g., temperature and pressure) and where a mobile gateway may include features for generating fluid flow values using information from the one or more sensors. In such an example, the mobile gateway may issue one or more control instructions (e.g., to a choke, a pump, etc.).

As an example, a gateway itself may include one or more cameras such that the gateway may record conditions. For example, consider a motion detection camera that may detect the presence of an object. In such an example, an image of the object and/or an analysis (e.g., image recognition) signal thereof may be transmitted (e.g., via a satellite communication link) such that a risk may be assessed at a site that is distant from the gateway.

As an example, a gateway may include one or more accelerometers, gyroscopes, etc. As an example, a gateway may include circuitry that may perform seismic sensing that indicates ground movements. Such circuitry may be suitable for detecting and recording equipment movements and/or movement of the gateway itself. As an example, a gateway may include one or more sensors that may detect local shock and/or vibration, which may be associated with equipment operation, movement of fluid, etc.

As explained, a gateway may include features that enhance its operation at a remote site that may be distant from a city, a town, etc., such that travel to the site and/or communication with equipment at the site is problematic and/or costly. As explained, a gateway may include an operating system and memory that may store one or more types of applications that may be executable in an operating system environment. Such applications may include one or more security applications, one or more control applications, one or more simulation applications, etc.

As an example, various types of data may be available, for example, consider real-time data from equipment and ad hoc data. In various examples, data from sources connected to a gateway may be real-time, ad hoc data, sporadic data, etc. As an example, lab test data may be available that may be used to fine tune one or more models (e.g., locally, etc.). As an example, data from a framework such as the AVOCET framework may be utilized where results and/or data thereof may be sent to the edge. As an example, one or more types of ad hoc data may be stored in a database and sent to the edge.

As to real-time data, it may include data that are acquired via one or more sensors at a site and then transmitted after acquisition, for example, to a framework, which may be local, remote or part local and part remote. Such transmissions may be as streams (e.g., streaming data) and/or as batches. As to batches, a buffer may be utilized where an amount of data may be stored and then transmitted as a batch. In various instances, real-time data may be characterized using a sampling rate or sampling frequency. For example, consider 1 Hz as a sampling frequency that is adequate to track various types of physical phenomena that may occur during well operations. As an example, data may be acquired according to a cyclical frequency of field equipment. For example, consider a cycle of a rod pump such as in the example of FIG. 4. As an example, a sensor and/or a framework may provide for adjustment of sampling (e.g., at the sensor and/or at the framework). In various instances, data from multiple sensors may be at the same sampling rate or at one or more sampling rates.

As explained, various systems may operate in a local manner, optionally without access to a network such as the Internet. For example, a site may be relatively remote where satellite communication exists as a main mode of communication, which may be costly and/or low bandwidth. In such scenarios, security may resort to local features rather than a remote feature such as a remote authentication server.

An authentication server may provide a network service that applications use to authenticate credentials, which may be or include account names and passwords of users (e.g., human and/or machine). When a client submits a valid credential or credentials to an authentication server, the authentication server may generate a cryptographic ticket that the client may subsequently use to access one or more services.

In the example of FIG. 5, the edge framework 544 may be an edge-enabled data processing framework. As an example, such a framework may include features to perform one or more of the followings tasks: real-time data cleansing to synchronize information from existing well metrology (e.g., wellhead, tubing, flow, pump, etc.); executing one or more machine learning (ML) (e.g., including self-learning) models in real-time (e.g., one or more ML models that may identify one or more issues, etc.); and conveying a control set point to a controller (e.g., an actuatable valve, etc.) and/or one or more other pieces of equipment. As mentioned, an edge framework may be deployable using downhole circuitry, which may be downhole circuitry operatively coupled to surface circuitry, etc.

The system 500 may be part of an infrastructure that serves as a secure gateway to transmit surveillance into an operator's surveillance station and/or its own surveillance platform. The presence of such a gateway may also support an operator for introduction of one or more additional IIOT (industrial internet of things) implementations.

As an example, one or more of the controllers of FIG. 3 and FIG. 4 may include or provide access to one or more frameworks, applications, etc. As an example, one or more of the controllers of FIG. 3 and FIG. 4 may include one or more features of the system 500 of FIG. 5. As an example, the system 250 of FIG. 2 may include one or more instances of the system 500 of FIG. 5.

As an example, a system may provide for automated monitoring of artificial intelligence (AI) model performance on a number of field devices. Such a system can, for example, identify model drift due to differences in data, which may include training and inference data, etc. In response, the system may automatically trigger model retraining with new available data, while tracking model versions and artifacts and automatically building, testing and deploying new retrained models to the field devices, which may be edge devices.

FIG. 6 shows an example of a workflow 600 that includes providing one or more models that may be utilized to assess one or more generated cards (e.g., images, which may be pixel images, 2D data structures, etc.). As explained, data may be streamed and utilized to generate representations of cards, which may be in a format suitable for input to one or more machine learning models, which may provide for inferring issues, conditions, etc. (e.g., as classes, categories, etc.). As an example, model output may include inference card results, which may be provided in a form suitable for performing queries (e.g., searches, etc.), which may be via one or more techniques (e.g., natural language, etc.), whether human interactive and/or automated. As shown, the workflow 600 may also provide output as to the streamed data, which may be processed data, which may be in a form suitable for performing queries. As an example, the outputs may be provided to a common platform where queries may be performed and results thereof presented via one or more GUIs and/or utilized for purposes of issuing one or more instructions (e.g., alerts, control instructions, etc.).

FIG. 7 shows an example of a workflow 700 that may be implemented in an integrated environment where, for example, data may be acquired from field equipment 704 and provided to one or more platforms 708 that may host and/or be operatively coupled to various components 710, 720, 730, and 740 for generation of output, which may be suitable for use in rendering one or more graphical user interfaces (GUIs) 780 and/or for triggering one or more control actions in the field (e.g., consider mitigation control, etc.). As an example, a framework may provide for implementation of field control to control field equipment to perform one or more actions in the field. In such an example, such actions may include pumping actions performed by pumping equipment that may pump fluid into and/or out of a subsurface environment via a well in fluid communication with a reservoir, etc.

As shown, the components may include a data ingestion component 710, a data pre-processing and card generation component 720, a model input component 730, and an inference output component 740, as may be generated using one or more models (e.g., one or more trained machine learning models, etc.).

As an example, various components of a framework may be instantiated by a data science platform (e.g., the DATAIKU platform, etc.) that may provide for ingestion of data, performance of pre-processing for card generation (e.g., images, etc.), and provide for model input for one or more machine learning models (e.g., as may be accessed via a cloud platform, etc.), where model output may be in the form of inferences. As an example, such inferences may be provided to a platform such as, for example, the SPOTFIRE platform, where one or more types of queries may be driven for generation of visualizations, control actions, optimizations, etc.

As an example, the SPOTFIRE platform may operate using one or more adapters. For example, consider A GOOGLE BIGQUERY adapter that enables read/write SQL-92 access to BIGQUERY tables in a GOOGLE account (e.g., cloud platform) and/or GOOGLE apps domain (e.g., applications). As an example, a complete aggregate and join syntax in BIGQUERY may be supported. Additionally, statements in the BIGQUERY syntax may be passed through. As an example, an adapter may use one or more versions of the BIGQUERY Web services API (e.g., consider enabling the API by creating a project in a developer console and authenticating to the API). The GOOGLE BIGQUERY platform is a serverless data warehouse that enables scalable analysis over petabytes of data, available as a Platform as a Service (PaaS) that supports querying using a dialect of SQL.

As an example, a container framework may provide for construction of a unit of software that packages up executable code and its dependencies such that an application may execute quickly and reliably from one computing environment to another. As an example, a container may be an image that is a lightweight, standalone, executable package of software that includes code, runtime, system tools, system libraries and settings. A container image becomes a “container” at runtime, for example, when run on a suitable engine (e.g., DOCKER engine for a DOCKER container image). As an example, an edge implementation may utilize a framework such as, for example, a lightweight machine learning framework such as the TENSORFLOW LITE (TFL) framework (GOOGLE LLC, Mountain View, California).

As an example, a model may utilize logistic regression. As an example, a model may include a convolution neural network (CNN). As an example, a model may include a deep CNN. As an example, a framework may utilize a logistic regression and a deep CNN. As an example, a framework may integrate deep CNN feature extraction with logistic regression (e.g., consider logistic regression as applied to multi-class classification, etc.). As an example, a framework may utilize one or more features of a VGG-16 deep CNN (Visual Geometry Group (VGG), University of Oxford), which may be modified, as appropriate, for one or more purposes to handle particular input and generate particular output.

The VGG-16 deep CNN may be characterized by a depth, which may include 16 layers, such as, for example, 13 convolutional layers and 3 fully connected layers. Such a model may be suitable for training to perform various classification and/or recognition tasks. As an example, a model may include an architecture that includes a stack of convolutional layers followed by max-pooling layers, for example, with progressively increasing depth. Such an approach may provide for a model that may learn relatively intricate hierarchical representations of features, for example, to provide robust and accurate predictions (e.g., inferences). As an example, a model may include softmax activation that may be applied to output of a last fully connected layer for purposes of performing classification.

As an example, the workflow 700 of FIG. 7 may be implemented using a model that includes features of a deep CNN, such as, for example, the VGG-16 deep CNN model. As an example, a workflow for model training may include importing libraries for a model, creating an object for training and testing data, initializing the model, passing the data to the dense layer, compiling the model, importing libraries to monitor and control training, visualizing training/validation data, and testing the model.

As an example, a framework may provide for a data-driven approach to identification of performance issues and control responses to address such performance issues. As an example, such a framework may operate without deterministic rules or may utilize one or more deterministic rules for purposes of implementing guardrails, for example, as to automated control. As an example, a framework may provide for identification of issues in a manner on par with a subject matter expert (SME) with experience in assessing pump characteristics, as may be represented using an image-based approach.

As an example, a framework may provide for assessing data with respect to time, for example, consider identification of changes from one card to another card with respect to time. In such an example, a framework may classify and/or otherwise characterize behavior of field equipment. In such an example, a framework may implement property scores that may provide for determining trending and/or changes from one or more classifications to one or more other classifications. As an example, a card may represent a mixed class (e.g., a mixture of classes, which may be in transition, etc.). As an example, output of a framework may include data indicative of transformation from one class to another. In such an example, a GUI may provide for rendering a cartoon with respect to time for assessment by a user, a machine, etc. As an example, over different time periods of pumps moving from normal to a particular problematic behavior, a framework may generate predictions (e.g., inferences) as to when the problematic behavior may become prominent as time progresses (e.g., from normal behavior to abnormal behavior). In such an approach, a framework may provide for triggering one or more control actions at an appropriate time to mitigate a trend and/or otherwise address a prospective abnormal behavior.

As an example, a ML model-based workflow may be implemented in an online manner that may receive data in real-time as to field operations for one or more sets of field equipment (e.g., one or more pumps, etc.). In such an example, the workflow may generate inferences that may be rendered to one or more displays, for example, as one or more GUIs. In such an example, a change in behavior may provide for triggering control action.

As an example, a GUI may provide for filtering sites, equipment, types of equipment, behavior, types of behavior, time spans, etc. As an example, a GUI may provide for comparing behavior of equipment at one or more sites. In such an example, where a type of behavior is exhibited at multiple sites, at approximately the same time, such a behavior may be related to one or more conditions common to the multiple sites. For example, consider a power supply issue, a reservoir pressure issue experienced at multiple sites, etc. Such types of issues may be unrelated to condition of field equipment, such as, wear and tear, etc., which may not directly impact longevity (e.g., remaining life, etc.) of the field equipment. Identification of a global issue amongst site may provide for issuance of one or more notifications, control signals, etc., that aim to address such a global issue (e.g., a power supply issue, etc.).

As an example, a framework may provide for conservation of resources, reduction in emissions, increased productivity of people, machines, fluid, etc. As an example, a framework may provide for identification of one or more types of behaviors in a relatively short amount of time (e.g., less than a few minutes, etc.). As explained, a framework may operate with a relatively high classification accuracy (e.g., consider an F1 score of approximately 0.95 F1).

FIG. 8 shows an example of a GUI 800 that may be part of the one or more GUIs 780 of FIG. 7. As shown, the GUI 800 includes various graphical controls that may provide for filtering sites, equipment, classifications, etc. As an example, the GUI 800 may provide for triggering control of field equipment, for example, automatically, semi-automatically, etc.

FIG. 9 shows an example of a GUI 900 that may be part of the one or more GUIs 780 of FIG. 7. As shown, the GUI 900 includes various graphics, which may include a graphic for surface conditions and a graphic for subsurface (e.g., downhole) conditions. In such an example, a comparison may be performed for surface and subsurface conditions, which may, for example, enhance identification of one or more behaviors and/or determination of one or more control actions. As an example, the GUI 900 may provide for triggering control of field equipment, for example, automatically, semi-automatically, etc.

FIG. 10 shows an example of a workflow 1000 that includes a start block 1010 for commencing the workflow 1000, a card collection and generation from raw data block 1014, a cards from field block 1018, a surface cards block 1022, and a train tagging model block 1022. As shown, the workflow 1000 may include a portion that provides for training a tagging model such that data may be appropriately tagged. As shown in the example of FIG. 10, the workflow 1000 may include another portion that includes a synthetically generated cards block 1040, a downhole cards block 1044, a preprocessed cards block 1048, an augmented cards block 1052 and a train general model block 1056.

In the example of FIG. 10, the workflow 1000 may provide for storing various models in a model store 1032. For example, trained tagging models and trained general models may be stored in the model store 1032. As shown, the workflow 1000 may include an inference and testing block 1060 for inference and testing of one or more models of the model store 1032. Upon inference and testing, one or more models may be validated for deployment and/or implementation. As shown, the workflow 1060 may terminate in an end block 1064.

As an example, the workflow 1000 may be performed in a dynamic manner whereby one or more portions of the workflow 1000 may proceed responsive to receipt of data, a signal, etc. For example, consider a portion of the workflow 1000 operating in response to receipt of an amount of field data, which may be from one or more pumps, equipment upstream and/or downstream from a pump or pumps, etc.

FIG. 11 shows an example of a workflow 1100 for assessing card data. As shown, an access block 1110 provides for accessing card data 1110 to be assessed by an assessment block 1120. In the example of FIG. 11, three example quality assessment classes are indicated, noting that one or more quality assessment classes may be utilized. As to a high quality block 1130, card data may be of a sufficient quality for utilization in detecting, labeling, training, classifying, etc., as to a number of types of issues. In the example of FIG. 11, such issues may include one or more of normal, fluid pound, gas interference, tagging, flatling, and one or more other issues. As to a medium quality block 1140, issues may include one or more of tagging, flatlining, and one or more other issues. As to a low quality block 1150, issues may include one or more of sensor issues (e.g., sensor error, etc.), and one or more other issues.

As to sensor issues, consider a sensing system that includes one or more Hall effect sensors (HES), which may exhibit HES error (HESE). Such issues may be discerned at least in part via an assessment of quality of card data, which may be low quality as indicia of pump-related issues may not be readily discernable due to sensor error. As shown in FIG. 11, card data subject to sensor error may be quite distorted, for example, with cross-over of data that forms two distinct closed bodies joined at a cross-over point. As explained, card data for normal and/or one or more other non-sensor issues may form a single closed body. For example, consider the card data examples for normal, fluid pound, gas interference, leaking standing valve, stuck pump, worn/split barrel, leaking traveling valve and flatlining as show in FIG. 11. With reference to quality, note that fluid pound and gas interference may exhibit card data that are more similar to normal than to flatlining. Hence, for detecting, training, etc., with respect to fluid pound and gas interference, a higher level of data quality may be beneficial; whereas, for flatlining, as the shape and size of card data (e.g., as plotted, as an image, etc.) differ substantially from normal such that a level of data quality less than that for fluid pound and gas interference may be utilized (e.g., consider medium quality rather than high quality).

Again, as explained, where some type of sensor-related, transmission related, etc., issue arises, such types of issues may be discerned in low quality data, which may be low quality due to one or more of such types of issues themselves. Where data are low quality, such data may be indicative of one or more types of issues that may not directly relate to pump operation (e.g., a pumping function for fluid) but rather a data acquisition system for sensor data, control data, etc.

FIG. 12 shows examples of synthetic and/or augmented card data 1200 and 1210. For example, for purposes of training one or more ML models, synthetic data may be generated and/or data may be augmented, whether real data and/or synthetic data. As an example, such types of data operations may provide for imparting characteristics that may improve ML model training, testing, performance, etc. For example, consider an approach that generates augmented data for gas interference where a particular portion of card data that tends to exhibit gas interference may be subjected to an augmentation process to generate additional data for one or more purposes.

In FIG. 12, the data 1200 shows creation of two data sets from a single parent data set. As shown, the parent data set may be subjected to an augmentation process that may provide for variants, such as, for example, genetic variants, which may be generated using one or more techniques that may be applied to the parent data set. Such an approach may provide for training an ML model that may become more robust to noise, variations, etc.

In FIG. 12, the data 1210 includes the two upper data sets exhibit relatively high quality (e.g., see the high quality block 1130 of FIG. 11), which makes these data sets suitable for use (e.g., smooth and well-formed). However, the two lower data sets exhibit lower quality, which may make them unsuitable for use for a particular type of performance issue. In the example of FIG. 12, these two lower data sets may be a result of an augmentation process, a synthetic generation process, etc. As an example, such data may be subject to an assessment process such as, for example, one or more actions of the workflow 1100 of FIG. 11, which may determine that these two lower data sets are not suitable for use in detection, training, labeling, etc. As an example, where one or both of the two lower data sets are actual data, these may be rejected as candidates for purposes of augmentation as augmentation may result in data that may be unrealistic and unlikely to occur in the field. As explained, a quality-based approach may be implemented for one or more purposes, whether to raw data, processed data, synthetic data, augmented data, etc.

As an example, an augmentation process may provide for generation of higher quality data sets through implementation of one or more techniques that aim to ensure some amount of smoothness, which may, for example, be characterized using one or more curvature criteria (e.g., definitions, etc.). For example, an augmentation process may involve a smooth interpolation stage which may smooth out jagged bumps, etc. For example, if a synthetic and/or augmented data set includes some discontinuities in a particular feature area of an image, these may be smoothed out using a smoothing process.

As an example, a card data contour may inherently be ordered and divided into four phases: downstroke, load, upstroke, unload. Due to the ordering, a process may treat these as four independent time series and augment one or more of these time series separately.

As an example, a process may provide for detecting separations between phases, for example, by looking for corners in an image (e.g., consider a find_corners_features( ) function in code). As an example, a process may involve defining a corner as a set of three 2D points, P1, P2, and P3, where an angle between vectors (P3−P2) and (P2−P1) is higher than some set threshold (e.g., to detect relatively large changes in direction). In such an example, a process may independently augment each phase using one or more actions. For example, consider an action that involves Gaussian noise injection and a subsequent action that involves interpolation. As an example, a process may stride over ordered contour points and iteratively perform such actions. As an example, contour points may be stored in a CSV format and/or one or more other formats (e.g., image, etc.).

As an example, an interpolation action may be at least in part physics-based, for example, accounting for one or more aspects of physics underlying card data characteristics. Such an approach may provide for preserving a particular amount of smoothness, which may be characterized using one or more metrics. As explained, card data tends to be relatively smooth such that introduction of non-smooth features may not advance or otherwise improve training and/or performance of one or more ML models. As to underlying physics, consider an SRP that may be subject to relatively random forces at random times, which tend to slightly alter loading and downstroke/upstroke paths (e.g., time series segments). As an example, a process may assume that forces (e.g., accelerations) may be a root cause of noise. In such an example, the process may apply one of the constant acceleration kinematic equations from physics: p(i+s)=p(i)+v_is+0.5as². In the foregoing equation, p(i+s) may be a noisy point one stride away and p(i) be a current point where v is a velocity at a time i. In such an example, at the point p(i), consider velocity v, as being: v=(p(i)−p(i−s))/s.

In such an approach, acceleration may be computed. For example, consider a=2(p(i+s)−p(i)−v_is)/s². In such an approach, consider using a closed form solution for interpolating points, p(i+1) p(i+s−1), inclusive: p(i+t)=p(i)+v_it+0.5at², for all t in {1,2, . . . s−1}. As explained, such an approach to interpolation, smoothing, etc., may be physics-based, which may help to generate and/or preserve features exhibited in actual data.

As an example, a workflow may include feature engineering to generate features. Such features may be portions of data, derived from data, based on metadata, etc. As an example, a feature may be a physics-informed feature where, for example, one or more underlying physical phenomena may be taken into account to engineer the feature. As an example, an engineered feature may be a static feature and/or a dynamic feature. For example, where time series data are utilized, a dynamic feature may depend on time. As to a physics-informed feature, consider knowledge that gas may rise (e.g., buoyant bubbles) in a column of liquid. In such an example, a dynamic feature may be engineered from raw data, cleaned data, synthetic data, etc., that characterizes the effect of gas rising, particularly in a pumping operation.

As an example, raw data, cleaned data, synthetic data, etc., may be a representation of time series data for a period of time. In such an example, a feature may be static as to the representation where the representation accounts for time. For example, card data may be presented visually as a cycle that occurs with respect to time. For that cycle, an engineered feature may be static; whereas, for an engineered feature that may span multiple cycles, that engineered feature may be dynamic. As an example, feature engineering may involve engineering features that may be static and/or dynamic. Such types of features may depend on type or types of ML models implemented and purpose or purposes thereof. As an example, features may be engineered to correspond to one or more types of operational conditions where, for example, one or more features may be indicative of a particular operational condition; whereas, one or more other features may be indicative of another particular operational condition. In various instances, a feature may be a useful indicator of one or more operational conditions.

In various instances, a feature may be a model feature. For example, a model feature may be an input to an ML model, which may be used, for example, during training and inference to make predictions. As an example, ML model accuracy may be improved through feature engineering. As an example, a feature may be a graphical, numerical, etc., feature. As an example, a feature may be a portion of data, which may correspond to a particular phase, stage, etc., of equipment operation. For example, an SRP may include various phases or stages where each of the phases or stages joins one or more other of the phases or stages. In such an example, a feature may be a junction, a region that includes a junction, a region proximate to a junction, etc. As an example, a feature may be computed using junction points, a line fit, a curve fit, etc. For example, consider card format data for an SRP that may provide for defining four junctions where, for example, one or more ratios, one or more areas, etc., may be features derived from the four junctions (e.g., as four individual data points, etc.). In general, a feature may be engineered based on raw data or cleaned data to improve learning and/or performance of an ML model. Feature engineering may involve extraction and transformation of variables from raw data, etc., to arrive at features for training and prediction. Appropriate feature engineering may be determinative of an ability to implement an ML model or ML models for purposes of monitoring, control, etc., as to one or more field operations. Appropriate feature engineering for ML models may make a framework more reliable, robust, accurate, and efficient, which may, in turn, allow for higher levels of automation of field equipment where such automation includes one or more ML models in the loop (e.g., in a control loop, etc.).

FIG. 13 shows an example of a workflow 1300 that includes a start block 1310, a card data block 1314, a workflow scenario block 1318, which may trigger automated workflow actions. For example, consider the workflow 1300 as including a portion whereby, responsive to receipt of card data, a workflow scenario is formulated, selected, etc., to trigger automatically an automated portion of the workflow 1300, which may provide for monitoring, control, etc.

As shown, a cards with labels block 1322 may be utilized to run inferences per a run block 1350, where the run block 1350 may operate utilizing one or more models retrieved from a model hub, per a model hub block 1340. As shown, models may include one or more of a primary model, a secondary model, and a supplemental model, per a primary block 1342, a secondary block 1344, and a supplemental block 1346. As shown, the run block 1350 may run inferences using one or more models to generate predictions per one or more operating conditions per a predictions block 1360. As an example, the workflow 1300 may provide for rendering a dashboard per a render block 1370, which may render information generated from one or more blocks such that a user may visualize performance of at least a portion of the workflow 1300. As explained, predictions may be utilized for monitoring and/or control of one or more pieces of field equipment, which may be related to power, fluid flow, fluid processing, etc. For example, consider controlling power to a pump, operation of a pump, treatment injection (e.g., chemical(s), etc.), gas injection (e.g., gas-lift, etc.), etc.

As shown, the workflow 1300 may be terminated in an end block 1380; noting that one or more instances of the workflow 1300 may be performed at one or more sites, which may be triggered responsive to receipt of data, which may be within a window or according to one or more other criteria. As explained, card data for a pump such as an SRP may be formed in a cyclical manner such that once a cycle or a number of cycles have been acquired, received, etc., a trigger action may occur that causes execution of various actions in an automated manner.

As an example, a framework may provide for a reduction in non-productive time (NPT) as to one or more types of field operations at one or more sites. As explained, a framework may provide a model-based approach to issue identification in a real-time manner. Such an approach may be performed at one or more levels of automation. For example, consider a fully automated manner whereby a framework may trigger a particular control action upon identification of a particular issue. As to a level of lesser automation, a human-in-the-loop (HITL) approach may be implemented, which may in accordance with one or more regulatory provisions. For example, local regulations for a site or sites may demand an HITL to assure that a framework adheres to particular standards as to what may be fully automated. As explained, a framework may generate output in a robust and accurate manner that may reduce demand on utilization of SMEs. In such an approach, a human may be responsible for affirming (e.g., confirming) that a particular control action is suitable for implementation to address an identified issue.

As an example, a system, a framework, a method, etc., may utilize one or more machine learning features, which may be implemented using one or more machine learning models. As to types of machine learning models, consider one or more of a support vector machine (SVM) model, a k-nearest neighbors (KNN) model, an ensemble classifier model, a neural network (NN) model, etc. As an example, a machine learning model may be a deep learning model (e.g., deep Boltzmann machine, deep belief network, convolutional neural network, stacked auto-encoder, etc.), an ensemble model (e.g., random forest, gradient boosting machine, bootstrapped aggregation, AdaBoost, stacked generalization, gradient boosted regression tree, etc.), a neural network model (e.g., radial basis function network, perceptron, back-propagation, Hopfield network, etc.), a regularization model (e.g., ridge regression, least absolute shrinkage and selection operator, elastic net, least angle regression), a rule system model (e.g., cubist, one rule, zero rule, repeated incremental pruning to produce error reduction), a regression model (e.g., linear regression, ordinary least squares regression, stepwise regression, multivariate adaptive regression splines, locally estimated scatterplot smoothing, logistic regression, etc.), a Bayesian model (e.g., naïve Bayes, average on-dependence estimators, Bayesian belief network, Gaussian naïve Bayes, multinomial naïve Bayes, Bayesian network), a decision tree model (e.g., classification and regression tree, iterative dichotomiser 3, C4.5, C5.0, chi-squared automatic interaction detection, decision stump, conditional decision tree, M5), a dimensionality reduction model (e.g., principal component analysis, partial least squares regression, Sammon mapping, multidimensional scaling, projection pursuit, principal component regression, partial least squares discriminant analysis, mixture discriminant analysis, quadratic discriminant analysis, regularized discriminant analysis, flexible discriminant analysis, linear discriminant analysis, etc.), an instance model (e.g., k-nearest neighbor, learning vector quantization, self-organizing map, locally weighted learning, etc.), a clustering model (e.g., k-means, k-medians, expectation maximization, hierarchical clustering, etc.), etc.

As an example, a machine model may be built using a computational framework with a library, a toolbox, etc., such as, for example, those of the MATLAB framework (MathWorks, Inc., Natick, Massachusetts). The MATLAB framework includes a toolbox that provides supervised and unsupervised machine learning algorithms, including support vector machines (SVMs), boosted and bagged decision trees, k-nearest neighbor (KNN), k-means, k-medoids, hierarchical clustering, Gaussian mixture models, and hidden Markov models. Another MATLAB framework toolbox is the Deep Learning Toolbox (DLT), which provides a framework for designing and implementing deep neural networks with algorithms, pretrained models, and apps. The DLT provides convolutional neural networks (ConvNets, CNNs) and long short-term memory (LSTM) networks to perform classification and regression on image, time-series, and text data. The DLT includes features to build network architectures such as generative adversarial networks (GANs) and Siamese networks using custom training loops, shared weights, and automatic differentiation. The DLT provides for model exchange various other frameworks.

As an example, a system may utilize one or more recurrent neural networks (RNNs). One type of RNN is referred to as long short-term memory (LSTM), which may be a unit or component (e.g., of one or more units) that may be in a layer or layers. A LSTM component may be a type of artificial neural network (ANN) designed to recognize patterns in sequences of data, such as time series data. When provided with time series data, LSTMs take time and sequence into account such that an LSTM may include a temporal dimension. For example, consider utilization of one or more RNNs for processing temporal data from one or more sources, optionally in combination with spatial data. Such an approach may recognize temporal patterns, which may be utilized for making predictions (e.g., as to a pattern or patterns for future times, etc.).

As an example, the TENSORFLOW framework (Google LLC, Mountain View, CA) may be implemented, which is an open-source software library for dataflow programming that includes a symbolic math library, which may be implemented for machine learning applications that may include neural networks. As an example, the CAFFE framework may be implemented, which is a DL framework developed by Berkeley AI Research (BAIR) (University of California, Berkeley, California). As another example, consider the SCIKIT platform (e.g., scikit-learn), which utilizes the PYTHON programming language. As an example, a framework such as the APOLLO AI framework may be utilized (APOLLO.AI GmbH, Germany). As an example, a framework such as the PYTORCH framework may be utilized (Facebook AI Research Lab (FAIR), Facebook, Inc., Menlo Park, California).

As an example, a training method may include various actions that may operate on a dataset to train a ML model. As an example, a dataset may be split into training data and test data where test data may provide for evaluation. A method may include cross-validation of parameters and best parameters, which may be provided for model training.

The TENSORFLOW framework may run on multiple CPUs and GPUs (with optional CUDA (NVIDIA Corp., Santa Clara, California) and SYCL (The Khronos Group Inc., Beaverton, Oregon) extensions for general-purpose computing on graphics processing units (GPUs)). TENSORFLOW is available on 64-bit LINUX, MACOS (Apple Inc., Cupertino, California), WINDOWS (Microsoft Corp., Redmond, Washington), and mobile computing platforms including ANDROID (Google LLC, Mountain View, California) and IOS (Apple Inc.) operating system-based platforms.

TENSORFLOW computations may be expressed as stateful dataflow graphs; noting that the name TENSORFLOW derives from the operations that such neural networks perform on multidimensional data arrays. Such arrays may be referred to as “tensors”.

As an example, a device and/or distributed devices may utilize TENSORFLOW LITE (TFL) or another type of lightweight framework. TFL is a set of tools that enables on-device machine learning where models may run on mobile, embedded, and IoT devices. TFL is optimized for on-device machine learning, by addressing latency (no round-trip to a server), privacy (no personal data leaves the device), connectivity (Internet connectivity is demanded), size (reduced model and binary size) and power consumption (e.g., efficient inference and a lack of network connections). TFL offers multiple platform support, covering ANDROID and iOS devices, embedded LINUX, and microcontrollers; diverse language support, which includes JAVA, SWIFT, Objective-C, C++, and PYTHON; and high performance, with hardware acceleration and model optimization. As an example, the system 500 of FIG. 5 may utilize one or more features of the TFL framework.

FIG. 14 shows an example of a method 1400 and an example of a system 1490. As shown, the method 1400 may include a reception block 1410 for receiving data from a pump system at a field site; a processing block 1420 for processing the data to generate card format data; a detection block 1430 for detecting an operational condition of the pump system using a machine learning model and the card format data; and a control block 1440 for, responsive to the detecting, controlling operation of the pump system at the field site.

The method 1400 is shown in FIG. 14 in association with various computer-readable media (CRM) blocks 1411, 1421, 1431, and 1441. Such blocks generally include instructions suitable for execution by one or more processors (or processor cores) to instruct a computing device or system to perform one or more actions. While various blocks are shown, a single medium may be configured with instructions to allow for, at least in part, performance of various actions of the method 1400. As an example, a computer-readable medium (CRM) may be a computer-readable storage medium that is non-transitory and that is not a carrier wave. As an example, one or more of the blocks 1411, 1421, 1431 and 1441 may be in the form processor-executable instructions.

In the example of FIG. 14, the system 1490, which may be a wellsite system, may include one or more information storage devices 1491, one or more computers 1492, one or more networks 1495 and instructions 1496. As to the one or more computers 1492, each computer may include one or more processors (e.g., or processing cores) 1493 and memory 1494 for storing the instructions 1496, for example, executable by at least one of the one or more processors 1493 (see, e.g., the blocks 1411, 1421, 1431 and 1441). As an example, a computer may include one or more network interfaces (e.g., wired or wireless), one or more graphics cards, a display interface (e.g., wired or wireless), etc.

As an example, a method may include receiving data from a pump system at a field site; processing the data to generate card format data; detecting an operational condition of the pump system using a machine learning model and the card format data; and, responsive to the detecting, controlling operation of the pump system at the field site. In such an example, the pump system may be or include a sucker rod pump system.

As an example, a card format data may be or include image data.

As an example, a machine learning model may be or include a convolution neural network (CNN). As mentioned, a deep CNN may be utilized. As an example, logistic regression may be utilized. As an example, a deep CNN may be utilized in combination with logistic regression.

As an example, a method may include detecting that includes using an inference generated by a machine learning model. In such an example, the detecting may include assessing the inference in combination with at least a portion of the data.

As an example, a method may include generating a graphical user interface that includes at least one card format image associated with the operational condition.

As an example, a method may include detecting that occurs in real-time. As an example, method may include controlling that occurs in real-time.

As an example, a method may include receiving data where the data include streaming data and processing that includes processing the streaming data according to one or more cycle criteria that correspond to a cycle of the pump system. In such an example, the cycle may include an up stroke and a down stroke. As an example, a cycle may include a cycle length determined by a pumping rate in strokes per minute. For example, consider a pumping rate may include a pumping rate greater than 0.1 strokes per minute and less than 50 strokes per minute. As an example, real-time performance may be on a cycle basis (e.g., detecting an operational condition within a cycle).

As an example, a method may include training a machine learning model. In such an example, training may include performing feature engineering to engineer features for the card format data. In such an example, features may correspond to one or more regions within card format data where, for example, one or more of the one or more regions may be indicative of one or more operational conditions. For example, consider a type of operational condition that may be indicated by a particular phase or stage region and/or by a phase or stage junction region. In such an example, a feature may be engineered that characterizes a region such that detection of an operational condition may be performed in an improved manner, for example, compared to an approach that does not include such a feature.

As an example, a method may include generating training data utilizing one or more data augmentation processes. For example, consider implementing an interpolation process for smoothing data, which may be, for example, a physics-informed interpolation process. As explained, such an approach may account for curvature such that one or more types of curvature, continuity, etc., may be assured, preserved, etc. As explained, data, whether real and/or synthetic, may be subject to one or more types of issues such as, for example, jaggedness. Underlying physics may be considered to determine whether an issue may be truthful of an operational condition or not. Where physics indicates that such an issue may be from a source other than pumping operation, such physics may be utilized to assure that a process may process such data such that processed data is more realistic, for example, adhering to underlying physics. As explained, for data jaggedness, underlying physics may be smooth such that a physics-informed smoothness approach may be implemented to smooth data in one or more regions, which may be one or more feature regions, etc.

As an example, a system may include a processor; memory accessible to the processor; and processor-executable instructions stored in the memory to instruct the system to: receive data from a pump system at a field site; process the data to generate card format data; detect an operational condition of the pump system using a machine learning model and the card format data; and, responsive to detection of the operational condition, controlling operation of the pump system at the field site.

As an example, one or more computer-readable storage media may include processor-executable instructions to instruct a wellsite computing system to: receive data from a pump system at a field site; process the data to generate card format data; detect an operational condition of the pump system using a machine learning model and the card format data; and, responsive to detection of the operational condition, controlling operation of the pump system at the field site.

As an example, a computer program product may include one or more computer-readable storage media that may include processor-executable instructions to instruct a computing system to perform one or more methods and/or one or more portions of a method. Various example methods may be performed in various combinations.

In some embodiments, a method or methods may be executed by a computing system. FIG. 15 shows an example of a system 1500 that may include one or more computing systems 1501-1, 1501-2, 1501-3 and 1501-4, which may be operatively coupled via one or more networks 1509, which may include wired and/or wireless networks. The system 1500 may include one or more other components, for example, consider one or more other components 1508.

As an example, a system may include an individual computer system or an arrangement of distributed computer systems. In the example of FIG. 15, the computer system 1501-1 may include one or more modules 1502, which may be or include processor-executable instructions, for example, executable to perform various tasks (e.g., receiving information, requesting information, processing information, simulation, outputting information, etc.).

As an example, a module may be executed independently, or in coordination with, one or more processors 1504, which is (or are) operatively coupled to one or more storage media 1506 (e.g., via wire, wirelessly, etc.). As an example, one or more of the one or more processors 1504 may be operatively coupled to at least one of one or more network interface 1507. In such an example, the computer system 1501-1 may transmit and/or receive information, for example, via the one or more networks 1509 (e.g., consider one or more of the Internet, a private network, a cellular network, a satellite network, etc.).

As an example, the computer system 1501-1 may receive from and/or transmit information to one or more other devices, which may be or include, for example, one or more of the computer systems 1501-2, etc. A device may be located in a physical location that differs from that of the computer system 1501-1. As an example, a location may be, for example, a processing facility location, a data center location (e.g., server farm, etc.), a rig location, a wellsite location, a downhole location, etc.

As an example, a processor may be or include a microprocessor, microcontroller, processor module or subsystem, programmable integrated circuit, programmable gate array, or another control or computing device.

As an example, the storage media 1506 may be implemented as one or more computer-readable or machine-readable storage media. As an example, storage may be distributed within and/or across multiple internal and/or external enclosures of a computing system and/or additional computing systems.

As an example, a storage medium or storage media may include one or more different forms of memory including semiconductor memory devices such as dynamic or static random access memories (DRAMs or SRAMs), erasable and programmable read-only memories (EPROMs), electrically erasable and programmable read-only memories (EEPROMs) and flash memories, magnetic disks such as fixed, floppy and removable disks, other magnetic media including tape, optical media such as compact disks (CDs) or digital video disks (DVDs), BLUERAY disks, or other types of optical storage, or other types of storage devices.

As an example, a storage medium or media may be located in a machine running machine-readable instructions, or located at a remote site from which machine-readable instructions may be downloaded over a network for execution.

As an example, various components of a system such as, for example, a computer system, may be implemented in hardware, software, or a combination of both hardware and software (e.g., including firmware), including one or more signal processing and/or application specific integrated circuits.

As an example, a system may include a processing apparatus that may be or include a general-purpose processors or application specific chips (e.g., or chipsets), such as ASICs, FPGAs, PLDs, or other appropriate devices.

As an example, a device may be a mobile device that includes one or more network interfaces for communication of information. For example, a mobile device may include a wireless network interface (e.g., operable via IEEE 802.11, ETSI GSM, BLUETOOTH, satellite, etc.). As an example, a mobile device may include components such as a main processor, memory, a display, display graphics circuitry (e.g., optionally including touch and gesture circuitry), a SIM slot, audio/video circuitry, motion processing circuitry (e.g., accelerometer, gyroscope), wireless LAN circuitry, smart card circuitry, transmitter circuitry, GPS circuitry, and a battery. As an example, a mobile device may be configured as a cell phone, a tablet, etc. As an example, a method may be implemented (e.g., wholly or in part) using a mobile device. As an example, a system may include one or more mobile devices.

As an example, a system may be a distributed environment, for example, a so-called “cloud” environment where various devices, components, etc. interact for purposes of data storage, communications, computing, etc. As an example, a device or a system may include one or more components for communication of information via one or more of the Internet (e.g., where communication occurs via one or more Internet protocols), a cellular network, a satellite network, etc. As an example, a method may be implemented in a distributed environment (e.g., wholly or in part as a cloud-based service).

Although only a few example embodiments have been described in detail above, those skilled in the art will readily appreciate that many modifications are possible in the example embodiments. Accordingly, all such modifications are intended to be included within the scope of this disclosure as defined in the following claims. In the claims, means-plus-function clauses are intended to cover the structures described herein as performing the recited function and not only structural equivalents, but also equivalent structures. Thus, although a nail and a screw may not be structural equivalents in that a nail employs a cylindrical surface to secure wooden parts together, whereas a screw employs a helical surface, in the environment of fastening wooden parts, a nail and a screw may be equivalent structures.