Production systems can provide for transportation of fluids from well locations to processing facilities, from processing facilities to well locations, etc. Such fluid may be single or multiphase and include one or more hydrocarbon fluids (e.g., oil, natural gas, etc.) and may include one or more other fluids (e.g., water, etc.). As an example, a system may include a substantial number of flowlines and pieces of production equipment, for example, interconnected at junctions to form a network, which may be referred to as a fluid production network.
A method can include receiving real time data where the real time data include at least pressure sensor data from multiple pressure sensors of a hydrocarbon fluid production network for multiple locations in the hydrocarbon fluid production network; generating an expected operational region in a multidimensional domain using at least a portion of the real time data; operating a leak detection system using the expected operational region; tracking at least a portion of the real time data in the multidimensional domain; and issuing a leak detection signal responsive to the tracking indicating an excursion from the expected operational region, where the leak detection signal indicates the presence of a leak in the hydrocarbon fluid production network. A leak detection system can include a processor; memory accessible by the processor; and processor-executable instructions stored in the memory where the instructions include instructions to instruct the leak detection system to: receive real time data where the real time data include at least pressure sensor data from multiple pressure sensors of a hydrocarbon fluid production network for multiple locations in the hydrocarbon fluid production network; generate an expected operational region in a multidimensional domain using at least a portion of the real time data; operate a leak detection system using the expected operational region; track at least a portion of the real time data in the multidimensional domain; and issue a leak detection signal responsive to the tracking indicating an excursion from the expected operational region, where the leak detection signal indicates the presence of a leak in the hydrocarbon fluid production network. One or more computer-readable storage media can include computer-executable instructions executable by a computer, the instructions include instructions to: receive real time data where the real time data include at least pressure sensor data from multiple pressure sensors of a hydrocarbon fluid production network for multiple locations in the hydrocarbon fluid production network; generate an expected operational region in a multidimensional domain using at least a portion of the real time data; operate a leak detection system using the expected operational region; track at least a portion of the real time data in the multidimensional domain; and issue a leak detection signal responsive to the tracking indicating an excursion from the expected operational region, where the leak detection signal indicates the presence of a leak in the hydrocarbon fluid production network.
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.
Features and advantages of the described implementations can be more readily understood by reference to the following description taken in conjunction with the accompanying drawings.
The following description includes the best mode presently contemplated for practicing the described implementations. 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.
As an example, a model may be made that models a geologic environment in combination with equipment, wells, etc. For example, a model may be a flow simulation model for use by a simulator to simulate flow in an oil, gas or oil and gas production system. Such a flow simulation model may include equations, for example, to model multiphase flow from a reservoir to a wellhead, from a wellhead to a reservoir, etc. A flow simulation model may also include equations that account for flowline and surface facility performance, for example, to perform a comprehensive production system analysis.
As an example, a flow simulation model may be a network model that includes various sub-networks specified using nodes, segments, branches, etc. As an example, a flow simulation model may be specified in a manner that provides for modeling of branched segments, multilateral segments, complex completions, intelligent downhole controls, etc. As an example, one or more portions of a production network (e.g., optionally sub-networks, etc.) or a group of signal components and/or controllers may be modeled as sub-models.
As an example, a system may provide for transportation of oil and gas fluids from well locations to processing facilities and may represent a substantial investment in infrastructure with both economic and environmental impact. Simulation of such a system, which may include hundreds or thousands of flow lines and production equipment interconnected at junctions to form a network, can involve multiphase flow science and, for example, use of engineering and mathematical techniques for large systems of equations.
As an example, a flow simulation model may include equations for performing nodal analysis, pressure-volume-temperature (PVT) analysis, gas lift analysis, erosion analysis, corrosion analysis, production analysis, injection analysis, etc. In such an example, one or more analyses may be based, in part, on a simulation of flow in a modeled network.
As to nodal analysis, it may provide for evaluation of well performance, for making decisions as to completions, etc. A nodal analysis may provide for an understanding of behavior of a system and optionally sensitivity of a system (e.g., production, injection, production and injection). For example, a system variable may be selected for investigation and a sensitivity analysis performed. Such an analysis may include plotting inflow and outflow of fluid at a nodal point or nodal points in the system, which may indicate where certain opportunities exist (e.g., for injection, for production, etc.).
A modeling framework may include instructions (e.g., processor-executable instructions) to facilitate generation of a flow simulation model. For example, instructions may provide for modeling completions for vertical wells, completions for horizontal wells, completions for fractured wells, etc. A modeling framework may include instructions for particular types of equations, for example, black-oil equations, equation-of-state (EOS) equations, etc. A modeling framework may include instructions for artificial lift, for example, to model fluid injection, fluid pumping, etc. As an example, consider a set of instructions (e.g., a component) that includes features for modeling one or more electric submersible pumps (ESPs) (e.g., based in part on pump performance curves, motors, cables, etc.).
As an example, an analysis using a flow simulation model may be a network analysis to: identify production bottlenecks and constraints; assess benefits of new wells, additional pipelines, compression systems, etc.; calculate deliverability from field gathering systems; predict pressure and temperature profiles through flow paths; or plan full-field development.
As an example, a flow simulation model may provide for analyses with respect to future times, for example, to allow for optimization of production equipment, injection equipment, etc. As an example, consider an optimal time-based and conditional-event logic representation for daily field development operations that can be used to evaluate drilling of new developmental wells, installing additional processing facilities over time, choke-adjusted wells to meet production and operating limits, shutting in of depleting wells as reservoir conditions decline, etc.
As to equations, sets of conservation equations for mass momentum and energy describing single, two or three phase flow (e.g., according to one or more of a LEDAFLOW™ (Kongsberg Oil & Gas Technologies AS, Sandvika, Norway), OLGA™ model (Schlumberger Ltd, Houston, Texas), TUFFP unified mechanistic models (Tulsa University Fluid Flow Projects, Tulsa, Oklahoma), etc.).
As to the method 150 of
The method 150 is shown in
A production system can include equipment, for example, where a piece of equipment of the production system may be represented in a sub-network of a network model (e.g., optionally as a sub-model or sub-models, etc.) and, for example, assigned equations formulated to represent the piece of equipment. As an example, a piece of equipment may include an electric motor operatively coupled to a mechanism to move fluid (e.g., a pump, compressor, etc.). As an example, a piece of equipment may include a heater coupled to a power source, a fuel source, etc. (e.g., consider a steam generator). As an example, a piece of equipment may include a conduit for delivery of fluid where the fluid may be for delivery of heat energy (e.g., consider a steam injector). As an example, a piece of equipment may include a conduit for delivery of a substance (e.g., a chemical, a proppant, etc.).
As an example, a sub-network may be assigned equations formulated to represent fluid at or near a critical point, to represent heavy oil, to represent steam, to represent water or one or more other fluids (e.g., optionally subject to certain physical phenomena such as pressure, temperature, etc.).
As an example, a system can include a processor; a memory device having memory accessible by the processor; and processor-executable instructions stored in the memory of the memory device, the instructions executable to instruct the system to: build a network model that represents a production system for fluid, assign equations to sub-networks in the network model, provide data, transfer the data to the network model, and simulate physical phenomena associated with the production system using the network model to provide simulation results.
As an example, a system can include a sub-network assigned equations formulated for steam associated with equipment for an enhanced oil recovery (EOR) process (e.g., steam-assisted gravity drainage (SAGD) and/or other FOR process).
As an example, a system can include a sub-network that represents a piece of equipment of a production system by assigning that sub-network equations formulated to represent the piece of equipment. In such an example, the piece of equipment may include an electric motor operatively coupled to a mechanism to move fluid (e.g., a compressor, a pump, etc.).
As an example, one or more computer-readable media can include computer-executable instructions executable by a computer to instruct the computer to: receive simulation results for physical phenomena associated with a production system modeled by a network model; and analyze the simulation results.
In the example of
In the example of
In the example of
In the example of
To facilitate data analyses, one or more simulators may be implemented (e.g., optionally via the surface unit 216 or other unit, system, etc.). As an example, data fed into one or more simulators may be historical data, real time data or combinations thereof. As an example, simulation through one or more simulators may be repeated or adjusted based on the data received.
In the example of
In
The ternary diagram 250 of
The table 260 of
As an example, information as to flow of fluid may be illustrated as a flow regime map that identifies flow patterns occurring in various parts of a parameter space defined by component flow rates. For example, consider flow rates such as volume fluxes, mass fluxes, momentum fluxes, or one or more other quantities. Boundaries between various flow patterns in a flow regime map may occur where a regime becomes unstable and where growth of such instability causes transition to another flow pattern. As in laminar-to-turbulent transition in single phase flow, multiphase transitions may be rather unpredictable as they may depend on otherwise minor features of the flow, such as the roughness of the walls or the entrainment and entrance conditions. Thus, as indicated in the ternary diagram 250, flow pattern boundaries may lack distinctiveness and exhibit transition zones.
As to properties, where fluid is single phase (e.g., water, oil, or gas), a single value of viscosity may suffice for given conditions. However, where fluid is multiphase, two or more concurrent phases may occupy a flow space within a conduit (e.g., a pipe). In such an example, a single value of viscosity (e.g., or density) may not properly characterize the fluid in that flow space. Accordingly, as an example, a value or values of mixture viscosities may be used, for example, where a mixture value is a function of phase fraction(s) for fluid in a multiphase flow space.
As to surface tension (e.g., a), it may be defined for gas and liquid, for example, where the liquid may be oil or water. Where two-phase liquid-liquid flow exists (e.g., water and oil), then a may reflect the interfacial tension between oil and water (see, e.g., the slug flow regime and the bubble flow regime).
As an example, a choke may include an orifice that is used to control fluid flow rate or downstream system pressure. As an example, a choke may be provided in any of a variety of configurations (e.g., for fixed and/or adjustable modes of operation). As an example, an adjustable choke may enable fluid flow and pressure parameters to be changed to suit process or production requirements. As an example, a fixed choke may be configured for resistance to erosion under prolonged operation or production of abrasive fluids.
The oilfield network 302 may be a gathering network and/or an injection network. A gathering network may be an oilfield network used to obtain hydrocarbons from a wellsite (e.g., the wellsite 1312, the wellsite n 314, etc.). In a gathering network, hydrocarbons may flow from the wellsites to the processing facility 320. An injection network may be an oilfield network used to inject the wellsites with injection substances, such as water, carbon dioxide, and other chemicals that may be injected into the wellsites. In an injection network, the flow of the injection substance may flow towards the wellsite (e.g., toward the wellsite 1312, the wellsite n 314, etc.).
The oilfield network 302 may also include one or more surface units (e.g., a surface unit 1316, a surface unit n 318, etc.), for example, a surface unit for each wellsite. Such surface units may include functionality to collect data from sensors (see, e.g., the surface unit 216 of
As an example, the oilfield production tool 304 may be connected to the oilfield network 302. The oilfield production tool 304 may be a simulator (e.g., a simulation framework) or a plug-in for a simulator (e.g., or other application(s)). The oilfield production tool 304 may include one or more transceivers 322, a report generator 324, an oilfield modeler 326, and an oilfield analyzer 328. As an example, the one or more transceivers 322 may be configured to receive information, to transmit information, to receive information and transmit information, etc. As an example, information may be received and/or transmitted via wire and/or wirelessly. As an example, information may be received and/or transmitted via a communications network such as, for example, the Internet, the Cloud, a cellular network, a satellite network, etc.
As an example, one or more of the one or more transceivers 322 may include functionality to collect oilfield data. The oilfield data may be data from sensors, historical data, or any other such data. One or more of the one or more transceivers 322 may also include functionality to interact with a user and display data such as a production result.
As an example, the report generator 324 can include functionality to produce graphical and textual reports. Such reports may show historical oilfield data, production models, production results, sensor data, aggregated oilfield data, or any other such type of data.
As an example, the data repository 352 may be a storage unit and/or device (e.g., a file system, database, collection of tables, or any other storage mechanism) for storing data, such as the production results, sensor data, aggregated oilfield data, or any other such type of data. As an example, the data repository 352 may include multiple different storage units and/or hardware devices. Such multiple different storage units and/or devices may or may not be of the same type or located at the same physical site. As an example, the data repository 352, or a portion thereof, may be secured via one or more security protocols, whether physical, algorithmic or a combination thereof (e.g., data encryption, secure device access, secure communication, etc.).
In the example of
As to the network modeler 332, it may allow a user to create a graphical network model that combines wellbore models and/or single branch models. As an example, the network modeler 328 and/or wellbore modeler 360 may model pipes in the oilfield network 302 as branches of the oilfield network 302 (e.g., optionally as one or more segments, optionally with one or more nodes, etc.). In such an example, each branch may be connected to a wellsite or a junction. A junction may be defined as a group of two or more pipes that intersect at a particular location (e.g., a junction may be a node or a type of node).
As an example, a modeled oilfield network may be formed as a combination of sub-networks. In such an example, a sub-network may be defined as a portion of an oilfield network. For example, a sub-network may be connected to the oilfield network 302 using at least one branch. Sub-networks may be a group of connected wellsites, branches, and junctions. As an example, sub-networks may be disjoint (e.g., branches and wellsites in one sub-network may not exist in another sub-network).
As an example, the oilfield analyzer 328 can include functionality to analyze the oilfield network 302 and generate a production result for the oilfield network 302. As shown in the example of
As an example, the production analyzer 334 can include functionality to receive a workflow request and interact with the single branch solver 342 and/or the network solver 344 based on particular aspects of the workflow. For example, the workflow may include a nodal analysis to analyze a wellsite or junction of branches, pressure and temperature profile, model calibration, gas lift design, gas lift optimization, network analysis, and other such workflows.
As an example, the fluid modeler 336 can include functionality to calculate fluid properties (e.g., phases present, densities, viscosities, etc.) using one or more compositional and/or black-oil fluid models. The fluid modeler 336 may include functionality to model oil, gas, water, hydrate, wax, and asphaltene phases. As an example, the flow modeler 338 can include functionality to calculate pressure drop in pipes (e.g., pipes, tubing, etc.) using industry standard multiphase flow correlations. As an example, the equipment modeler 340 can include functionality to calculate pressure changes in equipment pieces (e.g., chokes, pumps, compressors, etc.). As an example, one or more substances may be introduced via a network for purposes of managing asphaltenes, waxes, etc. As an example, a modeler may include functionality to model interaction between one or more substances and fluid (e.g., including material present in the fluid).
As an example, the single branch solver 342 may include functionality to calculate the flow and pressure drop in a wellbore or a single flowline branch given various inputs.
As an example, the network solver 344 can include functionality to calculate a flow rate and pressure drop throughout the oilfield network 302. The network solver 344 may be configured to connect to the offline tool 346, the Wegstein solver 348, and the Newton solver 350. As an example, alternatively or additionally, one or more other solvers may be provided, for example, consider a sequential linear programming solver (SLP), a sequential quadratic programming solver (SQP), etc. As an example, a solver may be part of the production tool 304, part of the analyzer 328 of the production tool 304, part of a system to which the production tool 304 may be operatively coupled, etc.
As an example, the offline tool 346 may include a wells offline tool and a branches offline tool. A wells offline tool may include functionality to generate a production model using the single branch solver 342 for a wellsite or branch. A branches offline tool may include functionality to generate a production model for a sub-network using the production model for a wellsite, a single branch, or a sub-network of the sub-network.
As an example, a production model may be capable of providing a description of a wellsite with respect to various operational conditions. A production model may include one or more production functions that may be combined, for example, where each production function may be a function of variables related to the production of hydrocarbons. For example, a production function may be a function of flow rate and/or pressure. Further, a production function may account for environmental conditions related to a sub-network of the oilfield network 302, such as changes in elevation (e.g., for gravity head, pressure, etc.), diameters of pipes, combination of pipes, and changes in pressure resulting from joining pipes. A production model may provide estimates of flow rate for a wellsite or sub-network of an oilfield network.
As an example, one or more separate production functions may exist that can account for changes in one or more values of an operational condition. An operational condition may identify a property of hydrocarbons or injection substance. For example, an operational condition may include a watercut (WC), reservoir pressure, gas lift rate, etc. Other operational conditions, variables, environmental conditions may be considered.
As to the network solver 344, in the example of
An oilfield network may be solved by identifying pressure drop (e.g., pressure differential), for example, through use of momentum equations. As an example, an equation for pressure differential may account for factors such as fluid potential energy (e.g., hydrostatic pressure), friction (e.g., shear stress between conduit wall and fluid), and acceleration (e.g., change in fluid velocity). As an example, an equation may be expressed in terms of static reservoir pressure, a flowing bottom hole pressure and flowrate. As an example, equations may account for vertical, horizontal or angled arrangements of equipment. Various examples of equations may be found in a dynamic multiphase flow simulator such as the simulator of the OLGA™ simulation framework (Schlumberger Limited, Houston, TX), which may be implemented for design and diagnostic analysis of oil and gas production systems. As an example, a simulation framework may include one or more sets of instructions for building a model; for fluid and multiphase flow modeling; for reservoir, well and completion modeling; for field equipment modeling; and for operations (e.g., artificial lift, gas lift, wax prediction, nodal analysis, network analysis, field planning, multi-well analysis, etc.).
As an example, a system may implement equations that include dynamic conservation equations for momentum, mass and energy. As an example, pressure and momentum can be solved implicitly and simultaneously and, for example, conservation of mass and energy (e.g., temperature) may be solved in succeeding separate stages.
As an example, an equation for pressure differential can account for factors such as fluid potential energy (e.g., hydrostatic pressure), friction (e.g., shear stress between conduit wall and fluid), and acceleration (e.g., change in fluid velocity). In addition, as mentioned, equations can be used to consider dynamic aspects. For example, equations can account for time and forces to accelerate and decelerate fluid (e.g., and objects) inserted into multiphase flow (e.g., consider pigs, etc.). As an example, an approach may consider the time it takes to conserve mass and energy (e.g., an amount of time it takes to drain a system, pipeline, or vessel). As an example, an approach may consider ramp-up time for production, for example, from one production rate to another production rate, etc. As an example, an approach may consider time it takes before a first condensate appears at an outlet of a production network during startup, etc.
As an example, an equation for a pressure differential (e.g., ΔP) may be rearranged to solve for flow rate (e.g., Q), where the equation may include the Reynolds number (e.g., Re, a dimensionless ratio of inertial to viscous forces), one or more friction factors (e.g., which may depend on flow regime), etc.
Through use of equations for flow into and out of a branch and equating to zero, a linear matrix in unknown pressures may be obtained. As an example, fixed flow branches (i.e., branches in which the flow does not change) may be solved directly for the node pressures.
As an example, a method can include defining variables and residual equations as well as branches in an oilfield network that may include a number of equipment items. As an example, a branch may be divided into sub-branches with each sub-branch containing a single equipment item. As an example, a new node may be used to join each pair of sub-branches. In this example, primary Newton-Raphson variables can include a flow (Qib) in each sub-branch in the network and a pressure Pin at each node in the network. In this example, temperature (or enthalpy) and composition may be treated as secondary variables.
As an example, residual equations may include a branch residual, an internal node residual, and a boundary condition. In such an example, a branch residual for a sub-branch relates the branch flow to the pressure at the branch inlet node and the pressure at the outlet node. As an example, internal node residuals can define where total flow into a node is equal to total flow out of the node.
As an example, determining an initial solution may be performed using a production model where for each subsequent iteration, a Jacobian matrix is calculated. The values of the Jacobian matrix may be used to solve a Jacobian equation for the Newton-Raphson update. To solve the Jacobian equation, one or more types of matrix solvers may be used.
In the example of
In the example of
While the example of
Various types of numerical solution schemes may be characterized as being explicit or implicit. For example, when a direct computation of dependent variables can be made in terms of known quantities, a scheme may be characterized as explicit. Whereas, when dependent variables are defined by coupled sets of equations, and either a matrix or iterative technique is implemented to obtain a solution, a scheme may be characterized as implicit.
As an example, a scheme may be characterized as adaptive implicit (“AIM”). An AIM scheme may adapt, for example, based on one or more gradients as to one or more variables, properties, etc. of a model. For example, where a model of a subterranean environment includes a region where porosity varies rapidly with respect to one or more physical dimensions (e.g., x, y, or z), a solution for one or more variables in that region may be modeled using an implicit scheme while an overall solution for the model also includes an explicit scheme (e.g., for one or more other regions for the same one or more variables).
As an example, a scheme may be implemented as part of the ECLIPSE™ 300 reservoir simulator marketed by Schlumberger Ltd. (Houston, Texas). As an example, the aforementioned OLGA™ simulator may include an interface that allows for interoperability with an ECLIPSE™ simulator. The ECLIPSE™ 300 reservoir simulator may implement a fully implicit scheme or an implicit-explicit scheme that is implicit in pressure and explicit in saturation, known as IMPES. In the fully implicit scheme, values for both pressure and saturation are provided at the end of each simulation time-step; whereas the IMPES scheme uses saturation values from the beginning of the time-step to solve for pressure values at the end of the time-step. In such examples, a reservoir simulator iterates until pressures values in grid blocks of a model of the reservoir being simulated have reached some internally consistent solution. However, a solution may be difficult to find if saturation (which the IMPES scheme assumes is constant within a time-step) changes rapidly during that time-step (e.g., a large percentage change in grid block values for saturation). The IMPES scheme may be able to cope with such an issue by decreasing “length” (e.g., duration) of the time-step but at the cost of more time-steps (e.g., in an effort to achieve a more stable solution).
The aforementioned fully implicit scheme may be a more stable option with saturation and pressure being obtained simultaneously so as any difference between their values for one time-step and a next time-step will not disturb a solution process as much as when compared to the IMPES scheme. Thus, in a fully implicit scheme, the “length” (e.g., duration) of a time-step may be larger but it also means that the fully implicit scheme may take additional processing time to achieve solutions (e.g., in comparison with an IMPES scheme). However, in a reservoir where properties change rapidly, a fully implicit scheme may provide a solution in less computational time than an IMPES scheme, even though an iteration of the fully implicit scheme may take longer to complete when compared to an iteration of the IMPES scheme.
The aforementioned ECLIPSE™ 300 reservoir simulator may also implement one or more components such as a black-oil simulator component, a compositional simulator component, or a thermal simulator component (e.g., for simulating thermodynamics, etc.). As an example, a black-oil simulator component may include equations to model three fluid phases (e.g., oil, water, and gas, with gas dissolving in oil and oil vaporizing in gas); as an example, a compositional simulator component may include equations to model phase behavior and compositional changes; and, as an example, a thermal simulator component may include instructions (e.g., for equations, etc.) to model a thermal recovery processes such as steam-assisted gravity drainage (SAGD), cyclic stream operations, in-situ combustion, heater, and cold heavy oil production with sand. As an example, one or more thermal components may provide instructions for modeling and simulating multiple hydrocarbon components in both oil and gas phases, a single nonvolatile component in an oil phase, oil, gas, water, and solids behaviors (e.g., optionally with chemical reactions), well production rates based on factors such as well temperature, low-temperature thermal scenarios (e.g., experiments or cold heavy oil production with sand), toe-to-heel air injection scenarios, foamy oil (e.g., as to effect on gas production, gas drive, oil production, etc.), multi-segmented well models (e.g., optionally including dual-tubing, horizontal wells, multiphase flow effects in a wellbore, etc.).
As to network models, as an example, a method can include simulation of dynamic and/or steady state operation of an oil and gas production system over various ranges of operating conditions and configurations. In such an example, the method may include an implicit evaluation of conservation of energy equations in addition to mass and momentum as an effective technique for efficiently and robustly simulating the production system where, for example, the production system includes fluid such as heavy oil, steam, or other fluids at or near critical pressures or temperatures. The term “critical point” is sometimes used herein to specifically denote a vapor-liquid critical point of a material, above which distinct liquid and gas phases do not exist.
As mentioned, a production system can provide for transportation of oil and gas fluids from well locations along flowlines which are interconnected at junctions to combine fluids from many wells for delivery to a processing facility. Along these flowlines (including at one or more ends of a flowline), production equipment may be inserted to modify the flowing characteristics like flow rate, pressure, composition, and temperature. As an example, a boundary condition may depend on a type of equipment, operation of a piece of equipment, etc.
As an example, a simulation may be performed using one type of equipment along a flowline and another simulation may be performed using another type of equipment along the same flowline, for example, to determine which type of equipment may be selected for installation in a production system.
As an example, a simulation may be performed using one type of equipment at a position (e.g., with respect to a flowline) and another simulation may be performed using another type of equipment at a different position (e.g., with respect to the same flowline or a different flowline), for example, to determine which type of equipment may be selected for installation in a production system as well as to determine where a type of equipment may be installed. As an example, a simulation may be performed using one type of equipment at a position (e.g., with respect to a flowline) and another simulation may be performed using that type of equipment at a different position (e.g., with respect to the same flowline or a different flowline), for example, to determine where that type of equipment may be installed.
In the example of
As an example, given information of operating condition(s) at boundary nodes (e.g., where fluid enters and exists the system) and the physical environment between them (e.g., geographical location, elevation, ambient temperature, etc.), a production engineer may aim to design a production system that meets business and regulatory requirements constrained to operating limits of available equipment.
As an example, a method can include implementing one or more components to simulate steady state operation of a production system, for example, as including a network (e.g., as a sub-network, etc.) as in the example of
As explained, a production system may provide for transportation of oil and gas fluids from well locations to a processing facility and can represent a substantial investment in infrastructure with both economic and environmental impact. Simulation of such a system, which may include hundreds or thousands of flow lines and production equipment interconnected at junctions to form a network, can be complex and involve multiphase flow science and engineering and mathematical methods to provide solutions (e.g., by solving large systems of non-linear equations). Factors associated with solid formation, corrosion and erosion, and environmental impact may increase complexity and cost.
As an example, a method can include formulating a proxy (e.g., or surrogate) model that may be suitable for expediting network analysis. Such a method may, for example, be implemented via a computing system.
As shown in
As an example, the instructions 470 can include instructions (e.g., stored in the memory 458) executable by at least one of the one or more processors 456 to instruct the system 450 to perform various actions. As an example, the system 450 may be configured such that the instructions 470 provide for establishing a framework, for example, that can perform network 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 470 of
As an example, a component can include instructions to instruct a system to render terrain and equipment locations to a display (e.g., via the GUI component 471, the map component 472, the equipment component 473, etc.); receive data for at least a portion of a network (e.g., via the data component 474); analyze the data with respect to a model associated with the terrain and the equipment locations (e.g., via the modeling component 475); and render information to the display based at least in part on an analysis (e.g., via the GUI component 471, a report component, etc.).
As an example, a framework may be implemented using various features of a system such as, for example, the system 450 of
Production systems for oil and gas often cover multiple wells tied back to a manifold, platform or onshore, etc. (e.g., consider a sub-sea manifold, a wellhead platform, a land-based manifold, etc.). At a manifold or wellhead platform, production from different wells may be co-mingled (e.g., merged, mixed, etc.) and fed to one or more multiphase pipelines that can transport fluid, for example, to topside or central processing facilities. As an example, multiple manifolds and wellhead platforms may feed one topside/central processing facility. As an example, produced fluid from a topside/central processing facility may again be fed to export pipelines for gas and/or oil to feed a market or a chemical processing plant.
As an example, a fluid production network can include a substantially vertical conduit and a substantially horizontal conduit and/or a substantially vertical conduit and/or a conduit that is neither substantially horizontal nor substantially vertical. As an example, a substantially vertical conduit can be oriented at an angle with respect to horizontal that is greater than about 50 degrees. As an example, a substantially horizontal conduit can be oriented at an angle with respect to horizontal that is less than about 40 degrees (e.g., between −40 degrees and +40 degrees depending on whether sloping down or up with respect to a direction, which may be a flow direction). As an example, a model or models can account for orientation, for example, as one or more parameters of a model or models.
As an example, a fluid production network can be or include a multiphase fluid production network. As an example, values output via a model-based framework can include values for fluid flow variables at a plurality of different times (e.g., single phase, multiphase, etc.).
As an example, a system and/or a method may optionally implement one or more Object Linking and Embedding (OLE) for Process Control (OPC) features (e.g., components, standards, etc.). For example, an OPC server may operate in conjunction with one or more OPC clients for transfer of information. OLE for Process Control (OPC) can include one or more types of data transportation technologies, which may include one or more technologies other than OLE (e.g., .NET™ framework, XML, binary-encoded TCP format, etc.).
As an example, one or more industrial information technology (IT) platforms that may include OPC Data Access (DA) functionality can be used to connect to one or more sensors or pieces of equipment, for example, through OPC and/or OPC UA as well as one or more standards such as, for example, MODBUS, WITSML, etc.
As an example, a framework may be optionally coupled to one or more data transmission systems, which may include, for example, a supervisory control and data acquisition (SCADA) system. For example, a framework may provide for monitoring a production system using one or more models where, responsive to model-based results, one or more notifications (e.g., instructions, commands, alarms, etc.) may be communicated via one or more data transmission systems. As an example, a SCADA system can include equipment for monitoring and control, which may operate, for example, with coded signals over communication channels (e.g., a communication channel per remote station, etc.).
As an example, a scheduler and associated components may be run with respect to a framework or frameworks. For example, consider a modeling framework that allows for building of models. As an example, information may be exchanged between frameworks, between components, etc.
In the example of
In the example of
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 PETREL framework can be part of the DELFI cognitive E&P environment (Schlumberger Limited, Houston, Texas) for utilization in geosciences and geoengineering, for example, to analyze subsurface data from exploration to production of fluid from a reservoir.
The TECHLOG framework can handle and process field and laboratory data for a variety of geologic environments (e.g., deepwater exploration, shale, etc.). The TECHLOG framework can structure wellbore data for analyses, planning, etc.
The PETROMOD framework provides petroleum systems modeling capabilities that can combine one or more of seismic, well, and geological information to model the evolution of a sedimentary basin. The PETROMOD framework can 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 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 can 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 can acquire data during one or more types of field operations, etc.). The INTERSECT framework can provide completion configurations for complex wells where such configurations can be built in the field, can provide detailed chemical-enhanced-oil-recovery (EOR) formulations where such formulations can be implemented in the field, can analyze application of steam injection and other thermal FOR 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 510. As shown in
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. Examples of such software packages include the PETREL framework. As an example, a system or systems may utilize a framework such as the DELFI framework (Schlumberger Limited, Houston, Texas). Such a framework may operatively couple various other frameworks to provide for a multi-framework workspace. As an example, the GUI 520 of
In the example of
As an example, a visualization process can implement one or more of various features that can 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 example, one or more frameworks, APIs, sets of instructions may be utilized (e.g., via appropriate conversion, etc.).
As an example, visualization features can provide for visualization of various earth models, properties, etc., in one or more dimensions. As an example, visualization features can 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 can include, for example, field equipment that can perform one or more field operations. As an example, a workflow may utilize one or more frameworks to generate information that can be utilized to control one or more types of field equipment (e.g., drilling equipment, wireline equipment, fracturing equipment, etc.).
As to a reservoir model that may be suitable for utilization by a simulator, consider acquisition of seismic data as acquired via reflection seismology, which finds use in geophysics, for example, to estimate properties of subsurface formations. As an example, reflection seismology may provide seismic data representing waves of elastic energy (e.g., as transmitted by P-waves and S-waves, in a frequency range of approximately 1 Hz to approximately 100 Hz). Seismic data may be processed and interpreted, for example, to understand better composition, fluid content, extent, and geometry of subsurface rocks. Such interpretation results can be utilized to plan, simulate, perform, etc., one or more operations for production of fluid from a reservoir (e.g., reservoir rock, etc.).
Field acquisition equipment may be utilized to acquire seismic data, which may be in the form of traces where a trace can include values organized with respect to time and/or depth (e.g., consider 1D, 2D, 3D or 4D seismic data). For example, consider acquisition equipment that acquires digital samples at a rate of one sample per approximately 4 ms. Given a speed of sound in a medium or media, a sample rate may be converted to an approximate distance. For example, the speed of sound in rock may be on the order of around 5 km per second. Thus, a sample time spacing of approximately 4 ms would correspond to a sample “depth” spacing of about 10 meters (e.g., assuming a path length from source to boundary and boundary to sensor). As an example, a trace may be about 4 seconds in duration; thus, for a sampling rate of one sample at about 4 ms intervals, such a trace would include about 1000 samples where later acquired samples correspond to deeper reflection boundaries. If the 4 second trace duration of the foregoing example is divided by two (e.g., to account for reflection), for a vertically aligned source and sensor, a deepest boundary depth may be estimated to be about 10 km (e.g., assuming a speed of sound of about 5 km per second).
As an example, a model may be a simulated version of a geologic environment. As an example, a simulator may include features for simulating physical phenomena in a geologic environment based at least in part on a model or models. A simulator, such as a reservoir simulator, can simulate fluid flow in a geologic environment based at least in part on a model that can be generated via a framework that receives seismic data. A simulator can be a computerized system (e.g., a computing system) that can execute instructions using one or more processors to solve a system of equations that describe physical phenomena subject to various constraints. In such an example, the system of equations may be spatially defined (e.g., numerically discretized) according to a spatial model that includes layers of rock, geobodies, etc., that have corresponding positions that can be based on interpretation of seismic and/or other data. A spatial model may be a cell-based model where cells are defined by a grid (e.g., a mesh). A cell in a cell-based model can represent a physical area or volume in a geologic environment where the cell can be assigned physical properties (e.g., permeability, fluid properties, etc.) that may be germane to one or more physical phenomena (e.g., fluid volume, fluid flow, pressure, etc.). A reservoir simulation model can be a spatial model that may be cell-based.
A simulator can be utilized to simulate the exploitation of a real reservoir, for example, to examine different production scenarios to find an optimal one before production or further production occurs. A reservoir simulator does not provide an exact replica of flow in and production from a reservoir at least in part because the description of the reservoir and the boundary conditions for the equations for flow in a porous rock are generally known with an amount of uncertainty. Certain types of physical phenomena occur at a spatial scale that can be relatively small compared to size of a field. A balance can be struck between model scale and computational resources that results in model cell sizes being of the order of meters; rather than a lesser size (e.g., a level of detail of pores). A modeling and simulation workflow for multiphase flow in porous media (e.g., reservoir rock, etc.) can include generalizing real micro-scale data from macro scale observations (e.g., seismic data and well data) and upscaling to a manageable scale and problem size. Uncertainties can exist in input data and solution procedure such that simulation results too are to some extent uncertain. A process known as history matching can involve comparing simulation results to actual field data acquired during production of fluid from a field. Information gleaned from history matching, can provide for adjustments to a model, data, etc., which can help to increase accuracy of simulation.
As an example, a simulator may utilize various types of constructs, which may be referred to as entities. Entities may include earth entities or geological objects such as wells, surfaces, reservoirs, etc. Entities can include virtual representations of actual physical entities that may be reconstructed for purposes of simulation. Entities may include entities based on data acquired via sensing, observation, etc. (e.g., consider entities based at least in part on seismic data and/or other information). As an example, an entity may be characterized by one or more properties (e.g., a geometrical pillar grid entity of an earth model may be characterized by a porosity property, etc.). Such properties may represent one or more measurements (e.g., acquired data), calculations, etc.
As an example, a simulator may utilize an object-based software framework, which may include entities based on pre-defined classes to facilitate modeling and simulation. As an example, an object class can encapsulate reusable code and associated data structures. Object classes can be used to instantiate object instances for use by a program, script, etc. For example, borehole classes may define objects for representing boreholes based on well data. A model of a basin, a reservoir, etc. may include one or more boreholes where a borehole may be, for example, for measurements, injection, production, etc. As an example, a borehole may be a wellbore of a well, which may be a completed well (e.g., for production of a resource from a reservoir, for injection of material, etc.).
While several simulators are illustrated in the example of
The PETREL framework provides components that allow for optimization of exploration and development operations. The PETREL framework includes seismic to simulation software components that can output information for use in increasing reservoir performance, for example, by improving asset team productivity. Through use of such a framework, various professionals (e.g., geophysicists, geologists, and reservoir engineers) can develop collaborative workflows and integrate operations to streamline processes (e.g., with respect to one or more geologic environments, etc.). Such a framework may be considered an application (e.g., executable using one or more devices) and may be considered a data-driven application (e.g., where data is input for purposes of modeling, simulating, etc.).
As mentioned, a framework may be implemented within or in a manner operatively coupled to the DELFI cognitive exploration and production (E&P) environment (Schlumberger, Houston, Texas), which is a secure, cognitive, cloud-based collaborative environment that integrates data and workflows with digital technologies, such as artificial intelligence and machine learning. As an example, such an environment can 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 framework can include various other frameworks, which can include, for example, one or more types of models (e.g., simulation models, etc.).
The method 600 is shown in
As an example, the method 600 may include generating an expected operational region using a simulator or simulators and, for example, updating the expected operational region dynamically using at least a portion of the real time data.
As an example, a method can include analyzing one or more changes to a system such as, for example, a change that is responsive to introduction of a chemical, water, etc. For example, consider a change due to introduction of an emulsifier, which may reduce viscosity of fluid in a system. As an example, a change in viscosity may cause a change in pressure drop (e.g., frictional forces, etc.), which may be trackable using pressure sensor data.
As an example, due to one or more factors, a production network may leak. As a production network may span some distance, which may be remote from people, a leak may not be readily detectable. As an example, a framework can provide for leak detection using various data and, for example, one or more models. Data can include, for example, pressure, flow, temperature, etc. As an example, upon detection of a leak or some probability of a leak, one or more actions may be taken to mitigate leakage of fluid or fluids. Such action can depend on locating a source of the leak or sources of leaks. Humans may use, for example, sight, smell, and sound. For example, discolored vegetation that is otherwise green along a pipeline right-of-way, or a pool of fluid along a pipeline right-of-way, or a cloud of vapor or mist along a pipeline right-of-way may be indications of leaks.
As an example, a framework may optionally issue one or more commands, instructions, alarms, etc., based at least in part on execution of a leak detection method. As an example, a command may be for a person to travel to a site, a drone to travel to a site (e.g., for data gathering, image gathering, etc.), etc. As an example, a drone may be an air-borne drone, a land drone, a sea drone, etc. As an example, a system can include a user interface for control of a drone and/or for data acquisition by one or more sensors of a drone (e.g., a camera, a microphone, etc.).
As an example, a Leak Detection System (LDS) may be based at least in part on a flow simulator. For example, consider an LDS based on the OLGA multiphase dynamic flow simulator and hosted in the OLGA online real-time architecture (e.g., OLGA framework, etc.).
An LDS can help to provide operational support by detecting a pipeline leak and estimating the location of a leak. As an example, an LDS may support operators in various activities.
As an example, an LDS may run one or more OLGA models which are first principles mathematical representations of the physical production system installation. As an example, an LDS may utilize field-measured values of pressure and flow and compare them to OLGA model-calculated values to determine the existence of pipeline leaks. As an example, once a leak has been detected, an LDS may provide estimates of the leak location.
As an example, an LDS may provide for detection of leaks as to one or more types of pipelines (e.g., consider a scenario of an Oil Pipeline and a Gas Pipeline from Station X to a Resource Processing Facility (RPF) and a Fuel Gas Pipeline from the RPF to Station X).
As to leak detection, one or more leak detection models may be utilized per pipeline for an LDS. For example, consider the following two models as examples: Flow—Pressure (FP) and Pressure—Flow (PF). Such detection models, FP and PF, can utilize simulator models (e.g., OLGA models) where the models can differ as to boundary conditions that are applied. For example, a simulator model may be adaptable to different boundary conditions where one set of boundary conditions is provided for an FP detection model and another set of boundary conditions is provided for a PF detection model. As an example, more than one model may be implemented for a pipeline. As an example, a single model may be selected for a pipeline.
As an example, a method can include receiving equipment information where the equipment information may include operational data for at least one piece of equipment of a hydrocarbon fluid production network. For example, consider a pump as a piece of equipment where operational data for the pump can include pump speed data, pump power data, pump temperature data, pump pressure data, pump operational state data, pump vibration data, etc. In such an example, detection of a leak, information about a leak, information about the fluid production network, information about one or more environmental conditions, information about one or more supply conditions (e.g., power supply, etc.) may be determined at least in part based on the equipment information. For example, where a pump speed is fluctuating or otherwise changing, such fluctuations may be due to an increase presence of gas in liquid (e.g., gas fraction), may be due to an unstable power supply (e.g., whether electrical from a utility, from a gas turbine electrical generator, etc.) and/or due to one or more effects of a leak or leaks (e.g., consider a leak at or proximate to a pump). A model-based framework can include one or more model equipment parameters that may couple equipment information with pressure, flow and/or temperature information about fluid in a fluid production network.
As an example, a method can include outputting a location of a fluid leak in a hydrocarbon fluid production network via a network interface of a computing system. In such an example, the method can include receiving the location via a network interface of a device where the device may be, for example, a mobile device (e.g., a smartphone, a GPS device, a drone, a vehicle, etc.). For example, consider a method that transmits a location of a fluid leak of a fluid production network to a drone or a drone controller such that the drone can travel to the location. In such an example, once underway to the location, the drone may receive a refined location as a leak detection system progresses in its leak location determination accuracy with respect to time (e.g., where the fluid production network stabilizes to a new steady state, etc.).
As an example, a framework may provide for one or more automatic shutdown actions. For example, a framework may be configured in the field as part of a Process Control System (PCS) that can respond at least in part to leak alarms generated by one or more LDSs.
As an example, a framework can include input data validation. For example, field measured data, such as pressures, temperatures, and flow rates, can be subjected to a data validation process where integrity of the data is determined (e.g., according to one or more integrity metrics). As an example, a data validation process or processes can perform one or more of the following health checks: OPC Quality, as a check of the health of a connection to field data (e.g., a connection to a SCADA OPC server, DCS OPC server, Process Information (PI) Historian (OSIsoft, LLC, San Leandro, California, USA), etc.); watchdog, as a check to determine whether updated values are coming through (e.g., if a value is static for too long, an alarm can be raised); range, as a check to determine if a value from the field is within a defined minimum range and/or a defined maximum range; and rate of change, as a check for rapid changes (e.g., and/or spikes) in field measured data.
In the example of
As an example, an LDS may provide for leak detection in a fuel gas pipeline (fuel gas pipeline operating in single phase); an oil pipeline (e.g., oil flowing through the oil pipeline being semi-stabilized where small amounts of gas can evaporate during shutdowns, but during flowing conditions, no gas evaporation may be expected; hence, it can be expected that an assumption as to the approach illustrated in
As an example, flow rates, in terms of fluid velocity, may be of the order of meters per second (e.g., for a pipeline of about 28 inches in diameter or, for example, about 24 inches to about 30 inches in diameter (e.g., 61 cm to 76 cm); noting that other size pipelines may be considered). As an example, consider the following fluid velocities in pipelines as examples: gas: <8 m/s and oil: <2.5 m/s (e.g., about a 28-inch diameter pipeline (e.g., 71 cm), etc.).
As an example, one or more LDS models can retrieve real-time data from a SCADA/Distributed Control System (DCS)/Process Control System (PCS) via an Object Linking and Embedding (OLE) for Process Control (OPC) Data Access (DA) component (see, e.g., the field data component 810). In such an example, the SCADA/DCS/PCS system can provide information to an OPC server and the LDS can connect to the SCADA/DCS/PCS system using an OPC client. OLE for Process Control (OPC) can include one or more types of data transportation technologies, which can include those other than OLE (e.g., .NET™ framework, XML, binary-encoded TCP format, etc.).
As to leak detection warnings, alarms and/or identified leak locations, one or more of these can be made available for presentation in a SCADA/DCS/PCS system and/or one or more other systems, etc. As an example, one or more automatic shutdown actions may be configured in a field DCS, for example, based at least in part on one or more leak alarms generated by an LDS.
As an example, a real-time framework can receive and transmit data between an LDS and a SCADA/DCS/PCS system. For example, a RT framework may provide data marshalling between various system components (e.g., a data historian, OLGA, or other simulator, one or more visualization frameworks, etc.).
As an example, an LDS can include a data historian component that can provide for storing results generated by the LDS. As an example, a sampling frequency can optionally be configured (e.g., consider a range of approximately 5 second or more (e.g., 15 seconds or more)). As an example, data may be stored for a determined period of time (e.g., a number of years and/or as limited by disk space, etc.). As an example, one or more historical trends may be determined by analysis of data and may be accessible via one or more Graphical User Interfaces (GUIs), for example, as implemented by a browser and/or other application(s).
OASE is a PYTHON® scripting engine and can be, for example, utilized for execution of one or more leak detection and/or location estimation algorithms. Dyno may be utilized as part of a visualization framework (see, e.g., the visualization framework 878), which may be part of a web user interface system. As an example, a server can host various LDS features and, for example, a web server running one or more user interface applications. As an example, a user interface may be accessed via a web browser application (e.g., INTERNET EXPLORER®, FIREFOX®, SAFARI®, etc.), which can allow one or more users to log in remotely (e.g., depending on IT security policies, etc.).
Various figures show various graphical user interfaces (GUIs) where such GUIs may be rendered to a display or a display surface (e.g., via projection, etc.) via execution of instructions by one or more processors. For example, a framework that provides for leak detection can include instructions executable to render one or more of the GUIs, for example, as part of a method, a workflow, etc.
As an example, a SCADA may provide for user input that can instruct an LDS. For example, where a graphic includes a feature or features that may indicate a location of a leak or a possible leak, user input may instruct the LDS to further assess one or more portions of a fluid production network and/or to take one or more other actions (e.g., model revision, etc.).
As an example, where a vehicle (e.g., truck, drone, submarine, etc.) is deployed to a leak location, the location of the vehicle may be tracked and rendered to a graphical user interface (e.g., as a moving graphic en route to a leak location). As an example, where more than one leak occurs, multiple leak graphics and/or locations may be rendered to a display (e.g., as part of one or more GUIs, etc.).
As explained, pipelines and networks of pipelines can be on-shore, off-shore and combined on- and off-shore and fluid can be single- or multi-phase.
As explained, transport pipelines and pipeline networks can experience one or more leaks, which may be of a particular size, sizes, etc. In various instances, an offshore production network can include “weak connectors” that have been installed for deliberate breakage if an external force on the pipeline becomes excessive. For example, consider external force as a consequence of an iceberg dragging along a seabed and contacting a pipeline, a fisherman's net being hooked up on a pipeline, etc. In such scenarios, overall damage may be reduced through pipeline rupture at one or more of a set of fixed controlled positions, which may be possible to close off. In contrast, consider external force that causes an uncontrollable rupture at a wellhead or wellheads.
As an example, connectors, bends, and pipeline welding joints at and around wellheads and manifolds can be exposed to higher risks for leaks than in factory fabricated pipeline segments.
As an example, a leak detection system can operate without a priori knowledge of fixed leak positions and/or fixed leak sizes. For example, consider a leak detection system that relies expressly on prior knowledge of leak positions and/or leak sizes. Such a system may acquire data from a dedicated leak detection sensor positioned on a pipeline where a signal from that sensor indicates a leak has occurred at a portion of the pipeline within the sensing range of that sensor. In such an example, the dedicated leak detection sensor can be programmed, built, or calibrated such that a signal from the dedicated leak detection sensor is directly related to a leak size. In such an approach, the dedicated leak detection sensor can generate a signal that relates, via prior knowledge, to leak location (e.g., via installation location) and leak size (e.g., via programming, building or calibration).
As to a leak detection system that can operate without prior knowledge as associated with dedicated leak detection sensors, consider an example where non-dedicated sensors are utilized. Such non-dedicated sensors can include one or more of temperature sensors, pressure sensors, phase sensors, density sensors, emulsion sensors, etc.
As an example, a leak detection system can provide for detection of leaks where a leak can be an outward leak or an inward leak. For example, where a hole exists that provides for fluid communication between an interior volume and an exterior volume, depending on various conditions, flow may be from the interior volume to the exterior volume or flow may be from the exterior volume to the interior volume. For example, consider a pressure differential between interior and exterior volumes that can, based on sign, cause an outward leak or an inward leak.
As to an inward leak, consider a seabed pipeline in salt water where salt water may flow into the seabed pipeline. In such an example, one or more properties of the salt water can, depending on types of sensor or sensors, help in determining leak location, leak size, etc. For example, consider mixing of salt water and oil where one or more electrical properties, one or more densities, etc., may change due to presence of the salt water.
As an example, a leak detection system that does not rely on fixed leak positions and/or fixed sizes, may be suitable for application to one or more different types of transport pipelines or networked systems, for example, without a demand for pre-application assumptions on leak position and/or size. However, where such information is available, such a leak detection system may be augmented (e.g., supplemented) using such knowledge.
As an example, when a leak (e.g., consider fluid flowing out of the production pipeline or pipeline network) occurs, a production system can be exposed to ambient conditions. Such exposure can affect measurements and the values of measured data points in the production system.
In various instances, a transportation pipeline and/or a network is defined without consideration of a wellhead or wellheads. In such instances, instrumentation (e.g., sensors, etc.) at or associated with a wellhead or wellheads may not be considered. As explained, one approach can be to use dedicated leak detection sensors, which can be without utilization of one or more other types of sensors. In such an approach, the number of measurements available may be limited to those of the dedicated leak detection sensors. In a wellhead inclusion approach, however, signals from one or more of multiple pressure sensors, temperature sensors, etc., may be available. For example, consider a wellhead that is equipped with a flow meter, which may be a multiphase flow meter. In such an example, a leak detection system may utilize one or more signals from such a multiphase flow meter.
As an example, if pre-assumptions on leak positions are applied, these positions can be in the production network at some distance away from wellhead instrumentation. Furthermore, such positions can be isolated from one or more of the wellheads due to valves being in a closed position. Thus, there can be a demand for a way to infer measurements and variables in the production pipelines and network.
As an example, a leak detection system (LDS) can include some amount of redundancy. For example, consider an LDS that provides for receipt and analysis of signals from wellhead sensors, which can be from multiple wellheads. As a reservoir can be in fluid communication with multiple wells via, for example, wellbore perforations, etc., a leak may impact conditions at multiple wellheads. For example, consider two neighboring wells where each of the wells is in fluid communication with a common reservoir. In such an example, flow in the wells can be driven by a first fluid pressure differential for a first one of the wells and a second fluid pressure differential for a second one of the wells. In such an example, there may be some amount of pressure being balanced as the wells, via at least the reservoir, are in fluid communication. For example, consider a situation where a leak occurs in a portion of a pipeline network of the first well, which may cause an increase in the first pressure differential (e.g., lower downstream pressure) such that there is an increase in fluid flow from the reservoir to the first well. In such an example, flow may decrease to the second well, which may be indicated via a flow meter sensor of a wellhead of the second well. As an example, an LDS can understand a leak better through use of signals from multiple sensors, where one or more of those sensors may be remote from a leak and/or in fluid communication with the leak via one or more intermediate structures, which can include, for example, a reservoir (e.g., porous rock filled at least in part with one or more fluids, etc.).
As an example, a simulator or simulation may include reservoir simulation where a reservoir is in fluid communication with one or more conduits (e.g., wells, etc.). For example, consider the ECLIPSE simulator, the INTERSECT simulator, etc., as to reservoir simulation which may be operatively coupled to an OLGA framework, a PIPESIM framework, etc.
As explained, multiple wellheads may be in fluid communication with a common manifold. For example, consider three wells, each with its own wellhead, including pipes that extend from each of the wellheads to a common manifold, which may provide for directing three flow streams into a single flow stream, which may be directed to one or more pieces of processing equipment (e.g., a separator, etc.).
As an example, an LDS can provide for acquiring and analyzing measurements for wellheads connected to a manifold, which can thereby provide some amount of redundancy. As to how large this redundancy is, may also be dependent on a number of transport pipelines connected to the manifold. At the same time, at other manifolds, other wells might be connected to the same production flowline. Thus, an inferred measurement or variable in a production flowline may depend on number of wellhead measurements at different manifolds. To infer measurements some distance away from the actual measurement positions, an LDS can include a model or models (e.g., relational model, physical model, etc.). As an example, an LDS can utilize relationships between different flow lines for purposes of real-time leak detection.
As an example, an LDS can include features for real-time leak detection where leak detection signals evolve over time, which can be due to one or more types of real-world physical phenomena. As mentioned, where flow lines are in fluid communication via a common reservoir, a leak in one flow line may, over time, cause a change in one or more of the other flow lines. Where such one or more other flow lines include one or more sensors, sensor signals may be acquired and analyzed in real time, for example, in a multi-dimensional parameter space. Such an approach can help to locate a leak, determine a leak size and/or determine a type of leak (e.g., outward, or inward, etc.). As an example, an LDS can include a real time model (RTM) that provides for real time leak detection and analysis.
As an example, an RTM approach can consider redundancy in a measurement of a certain type (e.g., pressure, temperature, flow, etc.) in a spatial multivariable system. As an example, an LDS may include utilization of redundancy in measurements and variables one-by-one at a common location where, for example, the LDS can perform transform combinations of reconciled measurements into a single scalar signature. As explained, an LDS can be distributed in a manner with redundancy that is distributed where, for example, the LDS can consider multivariable signatures and utilize redundancy in measurements appearing from different measurement positions in a production pipelines and network of pipelines.
As explained, an LDS can be a model-based LDS in that it utilizes an on-line real time model (RTM). In such an example, the RTM can accurately describe and simulate behavior of a production network by applying operational changes as occurring in the real production system to the real-time model. As an example, such a model can be utilized to characterize responses to one or more different leaks in an off-line or semi on-line manner. As an example, a model may be used on-line to infer measurements at positions where there are no measurements.
As an example, an LDS can utilize multivariable leak signatures. For example, consider an approach that utilizes dynamic signature movement in an n-dimensional space, where n is the number of applied leak signatures, as may be constrained by one or more of physical laws, layout of the system, sensor location, mode of operation, etc. As an example, constraints can be “as accurate as possible” described by an RTM.
As an example, an LDS can characterize several expected normal operation regions in terms of multivariable leak signatures. As an example, a union of expected normal operational regions can define an operational envelope. As an example, a leak detection algorithm can characterize, a priori, various leak regions through simulated data (e.g., executing one or more pipeline and/or reservoir simulators, etc.). As an example, an LDS can characterize, a priori, region(s) of transition(s) from an expected normal operational region or regions, which can be specific to a leak region.
As an example, an LDS can operate such that confidence to a leak is gradually built up as the current operation moves from normal operation towards the transition region, inside the transition region towards the leak regions and finally ends inside a leak region. In such an example, a last identified leak region can provide an indication of expected leak position and size. In such an example, if the operation is intervened by an operator before it enters the leak region, a last transition region can provide a most likely leak position.
As an example, an LDS can be operatively coupled to one or more vehicles such as subsea, land and/or air vehicles. For example, consider an LDS that can instruct a drone to a particular location where coordinates can be changed in real time as confidence as to an expected leak location increase. As an example, a subsea vessel (e.g., underwater drone, etc.) may be following a particular inspection pattern where the pattern may be interrupted by a call by an LDS to direct the subsea vessel to a particular location.
As an example, sometimes for small leaks, a leak region and a normal operation region can overlap such that statistical tests in terms of probability ratio of the probability of a leak divided by the probability of no leak (e.g., operation is inside expected operation region) can be utilized to determine if there is a leak or not (e.g., whether or not to issue a leak signal, notification, control action, etc.). As an example, a most likely leak can be a leak region closest to and covering a current operating point.
As to analyses in multidimensional space, consider one or more types of convex hulls. In geometry, the convex hull or convex envelope or convex closure of a shape can be the smallest convex set that contains it. A convex hull may be defined either as the intersection of the convex sets containing a given subset of a Euclidean space, or as the set of the convex combinations of points in the subset. For a bounded subset of a plane, a convex hull may be visualized as a shape enclosed by a rubber band stretched around the subset.
As an example, convex hulls of open sets can be open, and convex hulls of compact sets can be compact. As an example, an algorithmic problem of finding a convex hull of a finite set of points in a plane or other low-dimensional Euclidean space, and its dual problem of intersecting half-spaces, can be fundamental problems of computational geometry. As an example, a space may be more than two or three dimensions.
As an example, convex hulls may be simple polygons, encapsulate Brownian motion, space curves, and epigraphs of functions. As an example, one or more of orthogonal convex hulls, convex layers, Delaunay triangulation and Voronoi diagrams, convex skulls, etc., may be utilized.
As an example, an LDS can utilize one or more types of convex geometrical shapes. For example, consider one or more of n-dimensional boxes/n-orthotopes, parallelotopes and ellipsoids to describe one or more regions. As an example, one type of region may be of one type of n-dimensional shape and another type of region may be of another type of n-dimensional shape. As an example, choice of geometrical shape can affect test criteria for testing inside or outside a region. As an example, where statistical probability ratio is used, ellipsoids may be utilized for geometric shapes. A compact ellipsoid can be the minimum volume ellipsoid; noting that ellipsoids based on covariance matrices may introduce some conditions as various signatures cannot necessarily be assumed to be independent and normally distributed in an expected region. On the contrary, if they were independent and normally distributed, then the minimum volume ellipsoid will coincide with the ellipsoid described by the mean values of the samples and covariance matrix if the entire region is spanned by the samples.
As an example, an LDS can utilize minimum volume ellipsoids, which may be of suitable dimensionality. Such minimum volume ellipsoids can be of lesser volume than n-orthotopes. An orthotope can be a parallelotope whose edges are mutually perpendicular (e.g., an orthotope is a generalization of a rectangle and a cuboid).
In normal production such a system can be often operated with the crossover valves XO-2, XO-3 and XO-4 closed and each well routed to either flowline (FL-A or FL-B). In such normal production operation, the system 900 can be considered as two independent production systems. In
As an example, a signature or signatures may be utilized to detect a leak in the system 900. In such an example, the signature or signatures can provide for robust leak detection with reduced incidences of false alarms. As an example, an LDS can provide for detection of leaks that may be greater than a particular size as may be determined by a sensitivity analysis of the LDS where incidences of false alarms can be reduced. Incidences of false alarms can cause an operator to lose confidence in an LDS. As to a small leak, consider a flow rate of a small leak being less than 1 percent of a total flow rate in a single-phase pipeline. For a multiphase pipeline, a small leak may be slightly greater in terms of percent, for example, given uncertainties that can exist in multiphase flow (e.g., multiphase that includes gas and liquid). In various instances, field sensor type, quality, proper operation, etc., can impact an ability to detect low levels of leakage (e.g., less than 10 percent).
As an example, an LDS may provide capabilities for detection of one or more sensor related issues. For example, a signature or signatures may be indicative of a sensor related issue without being indicative of a leak. In such an example, a multidimensional space may be defined with normal operations representing no leakage and normal operations as to one or more sensors. In such an example, a signature or signatures can be compared to one or more regions, envelopes, etc., which may indicate: no leak, sensor OK; leak, sensor OK; no leak, sensor not OK; and leak, sensor not OK. As to the no leak, sensor not OK, real time tracking may be utilized to help determine if measurements from the sensor may be driving one or more signatures toward a leak region, which may result in a false alarm where the region is entered due to a sensor issue and not a leak. Such an approach can help to reduce incidence of false alarms due to one or more sensor related issues (e.g., sensor operational issues, data transmission, etc.).
As an example, a method can include generating one or more regions for one or more sensors where data and/or one or more signatures can be tracked to determine if sensor operation is as expected and within a region or regions.
As an example, a method can include utilizing a hierarchical approach to signatures. For example, a leak may be considered to be detected where more than one signature exceeds a boundary (e.g., consider two signatures, three signatures, etc., as being sufficient). As an example, different types of signatures may be at different levels of a hierarchy where one signature is at a level that demands at least one other signature exceeding a boundary and where another signature is at a level that does not demand another signature exceeding a boundary for triggering an alarm. As an example, signatures may be utilized in combination with logic rules along with boundaries (e.g., region boundaries) for purposes of leak detection, sensor issue detection, etc.
As shown in
When there is a potential for flow assurance issues like hydrate, wax or asphaltene formation, one or more special modes of operation of a production system can exist. For instance, to reduce risk of hydrate formation during (e.g., long period) shutdown, operation can involve circulation of dead (e.g., stabilized) oil from topside/shore through the production loop with one or more crossover valves open.
In various examples, there can be normal production scenarios with converging network; however, an LDS or LDS may be applicable to network configurations including more specialized operational scenarios such as, for example, as dead oil and hot water circulation.
As an example, when a production system is operated as a converging network as in
V
1j
=[v
11
v
12
v
13]
Now, let Δ{tilde over (p)}1j represent the pressure drop from measurement p1j to the inferred variable P where column vectors are:
P
1j
=[p
11
p
12
p
13]T
Δ{tilde over (P)}1j=[Δ{tilde over (p)}11Δ{tilde over (p)}13Δ{tilde over (p)}13]T
Then, consider:
Above, while Δ{tilde over (P)}1j is unknown, an estimate can be given by the RTM:
∥V1j∥1=Σj=13|v1j|.
The equation for
and obtain a new estimate
Note, if the RTM includes a model of the manifold, an LDS can reconcile Δp2j towards Δ{tilde over (p)}2j for a given valve opening v2j. In such an example, the approach can give an alternative estimated {tilde over (p)}1j that may be worth consideration for inclusion in the equation for
In the foregoing example, flowline FL-B has been considered; however, as explained, flowline FL-A can be considered along with FL-B. For example, consider the following equation:
The foregoing approach can operate utilizing an assumption that
As an example, an LDS can perform model-based leak detection using an on-line real time model. As explained, an LDS can be model based where an on-line dynamic model can be run in real-time in parallel with the plant (e.g., production pipelines or network of pipelines subject to potential leaks). In such an approach, the RTM can be utilized to model and simulate behavior of the production network by applying operational changes as occurring in the real production system to the RTM. The model scope and model boundary conditions can be tailored such that the model covers the normal operating envelope and the modes of operation where leak detection is to be applied. In addition, particular values of inlet and outlet boundary conditions can be exposed to reconciled measurements. For example, such model boundaries can be specified in accordance with reconciled measurements. Furthermore, an RTM can be subject to (e.g., batch-wise) tuning so that, for example, pressure and temperature drops in an RTM matches reconciled measurements from the system.
As an example, an LDS can utilize an RTM that is a reference for no leak events (e.g., normal operation without leaks). In such an approach, a leak can then be observed as a deviation from the RTM using one or more criteria (e.g., probability, statistical, etc.). In various instances, a deviation does not necessarily mean that a leak can be immediately observed. For example, for small leaks it can take some time for a deviation or deviations to meet one or more criteria (e.g., region-based criteria, etc.) to be distinguished from, for example, one or more of model errors and measurement noise. As an example, a criterion can be specified in the form of a “footprint” or other type of shape. As explained, a region may be a normal operational region where an excursion or excursions from the normal operational region are indicative of a leak. As explained, in a real time system, data can be streamed where multiple data points are acquired and processed for comparison to one or more regions and/or other region-based analysis. For example, consider transient analysis, which may include utilization of forward projections as to trends, which may be within some zone of uncertainty to help assess whether or not a trend is indicative of a leak transient that is likely to eventually breakout of a normal operational region.
As an example, various types of LD algorithms can be model based in the sense that the responses to potential leaks can be simulated a priori using the model off-line or semi on-line. In this context semi on-line means that the most recent tuned on-line model is used to simulate the response to the leaks and off-line means the model used to simulate responses to the leaks does not have connection to the real time on-line model. A model can be an advanced engineering model, which may be a best possible representation of the real system; noting that the parameters in a model do not demand adjustment such that the model response fit measured data. Thus, off-line can mean before commissioning and tuning of the on-line real time model to measured data.
As explained, an LDS can utilize leak signatures. A leak signature can be a strong indicator of a deviation (e.g., a potential leak) such that a leak signature is a measure for a potential leak. One or more of various types of signatures may be utilized for leak analysis and/or leak detection. As an example, an LDS can utilize multivariable leak signatures that are or include a combination or combinations of multiple leak signatures. As an example, leak signatures of different types can be combined by an LDS.
As to some examples, consider one or more of the following types of leak signatures: (a) measured variables; (b) difference between estimated and measured data; (c) normalized difference between estimated and measured data; (d) distance to ambient/target; (e) derived variables, which can include one or more of (i) difference (pressure ΔPj,i=Pj−Pi), (ii) gradient (pressure) along pipeline, (iii) ratio (pressure
and (iv) estimator for inventory; and (f) multivariable (e.g., leak signatures dependent on more than one set of measured and corresponding estimated variable).
As an example, a leak signature can be defined using one or more properties. As an example, a leak signature based on measured variables alone does not necessarily demand an on-line RTM to the degree as another leak signature. For example, leak signatures based on derived variables can be combined with difference between estimated measured variables (b) or normalized differences (c).
By combining variables an LDS can amplify different properties in the system. For instance, taking pressure difference along the pipeline can be good for a pipeline system with stable operation with little elevation and single-phase applications. As an example, pressure difference may be well correlated with flow and when a leak occurs between the pressure measurements the changed flow can propagate through the pipeline network and affect the pressure drop. However, in multiphase leak detection where one may expect to operate the production system in the region of slug flow, pressure drop over a segment can be impacted by the slug flow and it can be harder to distinguish a leak from a flow variation due to slug flow.
As an example, an LDS can utilize various signatures that have different properties where the LDS can make one or more selections dependent on the application. As an example, combining variables can introduce more combinations than considering the individual variables independently. For instance, having four pressure measurements then six pressure differences or pressure ratios can be formed and if the measurements are connected, they can be interpreted in a physical sense.
As an example, if two measurements are strongly correlated in normal operation and if the correlation changes due to the influence of a leak, then taking the ratio can introduce a strong signature since the leak can break the correlation (e.g., according to one or more criteria as to correlation, correlations, etc.). In such an example, consideration of pressure ratios can improve signal to noise ratio.
As explained above, a signature can be a distance-based signature such as distance to ambient and/or target (see, e.g., (d), above). In such an example, a signature can be dependent on an ambient/target condition. This is in a way peculiar, as in an LDS, a leak can now be cast as, or otherwise represent, a new additional boundary condition in the modelling sense. In such an example, the new additional boundary condition can affect principal directions of the system. For example, if the leak is big then a dynamic transition considering the added boundary condition can be rapid with respect to time and can first be visible in an individual signatures close to the leak position (leak location) and over time propagate to the signatures further away. Whereas, if the leak is small, the transients will be smaller and the path in the n-dimensional space (where n is the number of signatures applied) taken by a small leak will be different than for a large leak. As an example, an LDS can consider that a small leak is bounded by the physical system in a different way than a large leak. In such an approach, a large leak can represent a larger disturbance to normal operation than a small leak.
In various instances, dynamics of a system can depend on various types of physical phenomena. For example, consider elevation where gravity can act upon fluid, whether ambient or pipeline fluid. Gravity may make a portion or portions of a system directional with respect to one or more phenomena. For example, consider gravity related pressure head or elevation head, as may be due to fluid weight (e.g., the gravitational force acting on a column of fluid, etc.). As an example, a pressure head can be due to static pressure, the internal molecular motion of a fluid that exerts a force on its container. As to ambient, the deeper a pipeline is below an air/water surface, the greater the fluid head can be, which may impact leak dynamics (e.g., pressure differential for an inward leak or an outward leak). Additionally, if fluid is compressible, gravity can impact such a fluid, which may be germane for multiphase flow. As an example, dynamics of a system can be directional in a manner as to one or more types of phenomena (e.g., pressure, temperature gradients, etc.), which may result in a directionality or directionalities as to how a leak may dynamically affect readings at one or more sensors (e.g., wellhead and/or other sensors, etc.).
As to a leak signature for distance to ambient/target, consider a leak signature Xi for position i depending on measurement or inferred measurement Mi, on-line model estimates Ei corresponding to measurement Mi and ambient/target value Ai is given by:
Above, Xi≈0 when there is no leak and Xi=0 when there is no leak and a perfect model exists. Furthermore, as Xi approaches 1, there can be a strong indication that there is a rather large leak near measurement position i (see also, e.g.,
As to a revised version of the distance to ambient/target:
Note, {tilde over (X)}i∈[−1, 1], that is {tilde over (X)}i is in the range −1 to 1. Thus, {tilde over (X)}i≈0 when there is no leak and Xi=0 when there is no leak and a perfect model exists (see also, e.g.,
Above, as {tilde over (X)}i approaches −1, there is a strong indication that there is a leak of fluid from the surroundings (e.g., saltwater in an offshore subsea system) of the pipeline near measurement position i. To realize this, again set Mi=Ai to get:
From the foregoing example, it follows that this revised distance to ambient signature has the possibility to distinguish between leaks of process fluid from the pipelines to the surroundings and leaks of surrounding fluid into the pipeline.
As an example, an LDS can operate in terms of pressure in considering Xi and {tilde over (X)}i, where Ei is the estimated pressure and Mi is measured pressure at position i. However, an LDS may operate in terms of one or more other measures, etc. (e.g., additionally or alternatively).
As an example, consider a pipeline where flow rate is measured both at inlet and outlet. Also assume that the scope of the real time model includes reservoir condition(s). In such an example, measured flowrate at the inlet of the pipeline is not applied to the real time model as an inlet model boundary condition. Now assume that a moderate to large leak emerges of y % between the two flow measurements and that the leak is to the surroundings. In such an example, consider using the signatures Xi and {tilde over (X)}1 to the flow measurement at the outlet. In such an approach, set Ai=0, because a fully developed leak to the surroundings in a pipeline will give zero flowrate at the outlet. Such an approach can get
In the foregoing example, if y is small then
whereas, if the leak is large then
Now, for example, consider the inlet. At the point of the leak the pipeline pressure will decrease towards the ambient pressure. The inlet flowrate will increase due to decreasing wellhead pressure. In such an example, set Ai=0 and assume that wellhead flowrate increases with z %, then
In such an example, if z is small then
whereas, if the leak is large then
As an example, an LDS may alternatively consider (see also, e.g.,
As to multiple measurements and multivariable signatures, consider multiple measurements making the signature become a vector X in an n-dimensional space. In such an example, a footprint of the transitions in this n-dimensional space can be utilized as they can be different for the different leak sizes and positions.
As an example, an LDS can make use of multiple leak signatures to characterize a multivariable (n-dimensions) pattern that can be used as a footprint for leaks rather than single scalar signature. As explained, logic (e.g., logic rules, etc.) may be utilized for multiple signatures (e.g., as to leak detection, sensor issue detection, etc.).
As to regions, as mentioned, one or more types of regions may be defined, which can include normal, transient, leak, etc. As an example, a region may be dynamic and may change according to a schedule. For example, consider operational conditions that change according to a normal operational schedule. In such an example, a normal operational region may be dynamic with respect to time and, as mentioned, a transient leak can provide for a region, which may be dynamic with respect to time. Thus, in various instances, dynamic regions with different underlying drivers (e.g., operation, leak, normal, abnormal, etc.) may be utilized.
As an example, an LDS may include one or more of the following regions, which may be or include envelopes in a multidimensional space: (1) expected operational regions/envelope; (2) leak regions/envelope; and (3) transient to leak regions/envelope. In such an example, multiple regions may exist in each of the three categories.
As to classifying a region, consider utilization of geometrical shapes (e.g., rectangular right-angled box, ellipsoid, etc.) that can be used to describe a region. As mentioned, a shape may be a geometrical shape that is convex. As an example, principal directions of a geometrical shape can be aligned with axes of signatures. Such an approach can make it somewhat easier to compute the regions (e.g., consider right-angled bounding boxes); however, a resulting region may not necessarily be the most compact (minimum volume) region. In other words, it may include substantial void space. As an example, if the principal axes of a geometrical shape can be dis-aligned with the signature's axes (e.g., where rotation is allowed) then an LDS can provide the most compact (minimum volume) representation of the region for the given geometrical shape.
As an example, an LDS may operate to find a region (for a given geometrical shape) that contains the samples (points) and minimizes the volume that is best suited (e.g., unique, and compact). As an example, principal directions of the geometrical shapes may then not be aligned with the axes of the signatures. Thus, an LDS can operate to find the orientation of the region.
As an example, for ellipsoids there exists a unique minimum volume ellipsoid that contains m-points in the n-dimensional space n (e.g., assume that the m-points span the n-dimensional space). Various types of efficient numerical algorithms exist to compute such an ellipsoid.
As mentioned, it may be relatively straightforward to compute the right-angled box aligned with the axes of the signatures; however, in the n-dimensional space n, where n>3 it can be harder to compute the minimum volume right-angled bounding box of m-points in
n with an orientation different than the signature axes.
In such an example, by applying the relation for a specific signature, the data points can be transformed from (M2, M2, E2, E4) to (X2, X4).
for i=2 and 4 plotted versus time. Such a GUI may be rendered in color or one or more other manners to distinguish various points.
for i=2 and 4 plotted against each other.
In
Specifically,
Specifically,
In the examples of
This is a rectangle aligned with the original axes X2 and X4. Note, in this case the smaller rectangle can be found by also considering a rotation (noting that this rotated rectangle is not shown).
As to the outer rectangle, it is characterized by standard deviation for the variable Xi and number of standard deviation required to cover the range from X̆i to {circumflex over (X)}i, i.e.
As to the ellipsoid labelled E1, it is characterized by vector mean μX=[μ1 . . . μi . . . μn], vector of standard deviations σX=[σ1 . . . σi . . . σn] and the scalar n (not the dimension of the signature vector X). The scalar n is such that one point lies on the boundary of the ellipsoid and the other points lie inside the ellipsoid. In other words, the scaler n is given by the point furthest away from mean μX.
As to the second ellipsoid labeled E2, it is characterized by vector mean μX=[μ1 . . . μi . . . μn], covariance matrix Σ=ΣX and same scaler n given above. The multivariable probability density function for n-normal distributed variables is also described by mean μX and covariance matrix Σ. Contour plots of the normal distribution is ellipsoid characterized by μX and ΣX. The shape of the ellipsoid is given the covariance matrix ΣX. In such an example, the variables Xi cannot be assumed to be independent and normal distributed, which can be readily seen as the entire ellipsoid is not spanned out by the points. There are regions in E2 that do not contain points (e.g., void or voids).
As to the third ellipsoid E3, it is named the minimum volume ellipsoid and it is characterized by the geometrical center c and a positive semidefinite matrix A. Note that the center c=cX=[c1 . . . ci . . . cn] is not equal to the mean values of the variable. The minimum volume ellipsoid can be found by solving the following minimization problem:
Note, in the foregoing example, that the center vector c and the positive definite matrix A are free variables in the minimization. The determinant of the matrix det(A)=|A|=Πi=1nλi, where λi is the ith eigenvalue of the matrix A. Note that λi≥0, since A≥0 (positive semidefinite). The constraint (x−c)TA(x−c)≤1 makes sure that points are positioned inside or at the border of the ellipsoid. In domain 2 the area covered by the ellipse is minimized. In domain
or
1 is the distance from the geometrical center that is minimized, the scalar matrix is the inverse of the radius from the center and c is in the middle of minimum value and maximum value of the variable. In domain
n where n≥3, it generalizes to the minimum volume of the n-dimensional ellipsoid.
As to some examples of techniques for minimum volume ellipsoids, consider one or more of the following: Leonid G. Khachiyan, (1996) Rounding of Polytopes in the Real Number Model of Computation. Mathematics of Operations Research 21(2):307-320. https://doi.org/10.1287/moor.21.2.307; Todd, Michael J. (2016) Minimum-Volume Ellipsoids: Theory and Algorithms. MOS-SIAM Series on Optimization. https://my.siam.org/Store/Product/viewproduct/?ProductId=27790110; and Nima Moshtagh (2020) Minimum Volume Enclosing Ellipsoid. MATLAB Central File Exchange, ttps://www.mathworks.com/matlabcentral/fileexchange/9542-minimum-volume-enclosing-ellipsoid, which are incorporated by reference herein.
As an example, a technique as in Geismann et al., The Convex Hull of Ellipsoids, Proceedings of the Annual Symposium on Computational Geometry, 10.1145/378583.378717, SCG'01, Jun. 3-5, 2001, Medford, Massachusetts, USA, ACM 1-58113-357-X/01/0006, may be utilized; noting that Geismann et al. is incorporated by reference herein. The foregoing article describes computation of the convex hull of a set of ellipsoids using an algorithm.
As an example, an LDS may utilize one or more techniques, which may be for an appropriate corresponding shape or shapes. As explained, an LDS may utilize the minimum volume ellipsoids to give compact descriptions of regions; noting that one or more other shapes may be utilized additionally or alternatively (e.g., consider minimum volume right-angled boxes, etc.). As to boxes, algorithms to compute minimum volume right-angled boxes can be complex or unavailable for n>3.
As to expected operational regions and production envelope, as mentioned, an LDS can utilize one or more expected operational regions, which may be steady state, dynamic, etc. As an example, a union of expected operational regions can cover a production envelop.
As an example, an LDS can be dynamic where the production envelope and expected operational regions can be updated on-line with new reconciled on-line measurements. As an example, expected operational regions can be complemented with offline and/or semi-offline simulations. As mentioned, an operational schedule may be utilized for dynamic generation of one or more regions.
As explained, an LDS may operate using various types of information, sensor data, etc. For example, based on valve positions and mode of operation (normal production, fluid circulation, shutdown etc.), an LDS can determine an appropriate expected operational region.
As an example, an LDS can utilize one or more leak regions and, for example, a leak envelope. As an example, a leak region may be mimicked but not necessarily replicated in a system as damaging the system to generate a leak can be unacceptable. As to mimicking a leak, where a valve is available that can be coupled to a vessel, a pipeline, etc., to accept fluid, that valve may be utilized, however, it is a fixed valve at a fixed location. Thus, in general, at best it may be possible to update via reconciled on-line measurements for a fixed location mimicked leak; and not an actual leak as to characterizing a leak region. However, by using a rigorous multi- (or single-, depending on the application) phase simulator, an LDS can classify a leak region for a specific position and size. For example, by varying the leak size and taking the union of data for different sizes, an LDS can classify a leak region for a given position. In such an example, the union of data for leak positions (and sizes) can be generated to represent an expected leak region or envelope for a given system. As an example, leak regions of different discrete sizes at a given position can relate to each other in the sense that larger leak sizes can appear further away from the expected normal operation region than smaller leaks. For example, for small leaks, the leak region and the normal expected operational region can/will overlap as the leak size approaches zero (e.g., a limit-based approach). As an example, the area (when number of signatures is two) or volume (when the number of signatures >2) of a leak region will also vary. As an example, smaller leaks (1% to 10% of area) will in most cases have larger sizes (areas/volumes in multidimensional space) than large leaks like 60%, 80% or 100% of pipe area.
As an example, an LDS can utilize leak transient regions bridging the expected operational region to the leak region. For example, when simulating the leaks of different size for a given position, an LDS can see how operation goes out of the normal expected operational region and approaches the leak region. Due to constraints imposed, the movement from the expected operational region to leak region can go in one or more of certain directions. These directions can be collected in terms of the simulated data and characterized in regions for the transient from expected normal operation to the leak region. As an example, the leak transient regions can overlap with both the expected operational region and the leak region for the given position. In such an example, a GUI can render a graphic that represents a bridge between the expected operational region to the leak region.
Specifically, in
As an example, an LDS can assess the transition from expected operational region to the leak region. For example, prior to a leak, the system will be inside the expected normal operation region. Thus, the operation during a leak will start in the normal operation region, move into the overlap between the transient region and the normal expected region, go out of the normal expected region but still being inside the transient region. It can move in a transient region with a major component (principal axis) towards the leak region. It can then enter the leak region. On its way it can pass through one or more other leak regions (different size and/or position).
The plots in the GUIs 2600, 2700, and 2800 correspond to the possible combinations of two signatures and three different leak positions.
As an example, an LDS can include testing for memberships in one or more different regions to provide an indication if a leak is present or in development and, for example, the most likely leak position and/or size. As mentioned, logic (e.g., logic rules, etc.) may be utilized for leak detection, sensor issue detection, etc.
As an example, multivariable patterns described when a leak occurs can be sufficiently clear and differ depending on the leak position and size. As explained, small leaks tend to move in the directions of the principle axes of the leak regions. These directions can be dominated by the model and the closure of the model boundaries. As to the latter, consider the expected operational regions where one of the signatures is X1. In such plots, the ellipsoid of the expected operational region has the smaller radius in the direction of X1. This means that, in normal operation there is less room for variations in the direction of X1. This is due to the model boundary applied to the real time model at the outlet of the system; noting that leak regions can still be oriented in the main direction imposed by a model. The outlet model boundary condition can still apply; however, a bit upstream of the outlet boundary there may be a check valve. When a leak of a certain size appears due to one or more controller actions, this check valve can be instructed to close via an actuator, thereby causing a deviation in measurement position 1. For example, consider details of the plots with signature X1 where the main axis of the leak regions of larger sizes are more oriented in the direction of X1 than the main axis of the leak region describing the smallest size. This is due to the impact of the check valve closing and prohibiting the outlet boundary to propagate upstream of the check valve for the larger leaks.
As an example, for a signature combination of X3 and X4, model relations can impose that there is almost a one-to-one relation (e.g., ellipsoids are long and narrow oriented in almost 45 degrees) between X3 and X4 in normal operation as well as when leaks appear (e.g., independent of size and position of the leak).
As to various test criteria, an LDS may, for example, assume a vector of signatures x∈n with center or mean (depending on context)
n, radius r∈
n Let A be a positive definite matrix A∈
n×n such that vAv>0 for all v∈
n. Let X∈
m×n be a matrix of m row vectors of signatures xi∈
n and xji∈
,
In such an example, a LDS can compute the vector of mean
standard deviation
In such an example, the radius is given relative to the signature axes.
As explained, the center of minimum volume ellipsoid can be a geometrical center where it is not equal to the mean
As an example, an LDS may operate using one or more of the following multivariable test criteria: 1—region based test criteria based on ellipsoids; 2—region based test criteria based on boxes (“sum of individual criteria”); and 3—region based test criteria based on parallelohedron.
As an example, consider vector-based ellipsoid described by center
As an example, consider vector-based ellipsoid described center
√{square root over ((x−
Inside Region
√{square root over ((x−
As an example, consider region-based test criteria based on boxes (“sum of individual criteria”) mean
Strictly outside k, partly outside
n
Strictly inside k, partly inside
n
As an example, consider region-based test criteria based on parallelohedron (“linear with mean
As an example, an LDS can operate using a leak detection algorithm based on expected normal operation region, transient regions, and leak regions. As explained, an LDS can characterize a leak situation in terms of movement in and between the following three regions: expected operational regions/envelope; leak regions/envelope; and transient to leak regions/envelope.
As an example, an LDS can perform testing if a current operation point is inside or outside these regions, which can give rise to eight (23) cases. In such an example, at least six out of these cases might happen, as set forth in Table 1 below.
As to case #8, assume that a small leak appears. The leak size is so small that leak region for that leak position and size overlap the expected operational envelope. Then there exists at least one possible path so that transient path “from E.O to the specific LR” is completely inside E.O. In this case operational point can exist in all three regions at the same time.
As to case #1, the three region/envelopes might not cover the complete n. For case #1 and case #6 in the table above, if those occur an LDS may consider updating some of the regions.
As an example, leak detection in some cases can be determined using one or more of: (1) everything outside normal operation (with a safety factor) is a leak; (2) outside normal operation (with a safety factor) and inside TR or inside LR is a leak; and (3) demand that a process goes form normal operation (E.O) into TR and then into LR as sequence from case #2 to case #4 to case #3 to case #7 which ends in case #5, raising warnings and alarms at different levels.
Note that in
As an example, a bounded right-angled box aligned with the signature axes will describe such (A and B) regions well because the trajectories for large leaks will be aligned with the axes of the signatures close to the leak positions (due to the physics).
As an example, an LDS can utilize one or more components that can provide for tailored operation with respect to a system (e.g., a plant) or a portion thereof. For example, consider an approach that aims to balance the complexity with detection specifications, along with, for example, usefulness and potential failures of the algorithms/logic. As an example, instead of making one fixed leak detection algorithm, an LDS may provide for tailoring one or more leak detection algorithms to the specific project requirements, desires, etc.
As an example, a signature vector X can be a vector in n. In such an example, an LDS can consider combinations of two signatures or more to uncover behaviors, for example, using graphics, graphical techniques, geometry, probability, statistics, etc. As an example, an LDS may use as many signatures as possible to take advantage of redundancy. However, when designing a leak detection algorithm, an LDS can consider if each of the signatures are likely to be applied or not. As an example, if one or more measurements are too un-reliable, causing a signature to trigger a false alarm, then an LDS might exclude that signature (e.g., if the remaining number of signatures is sufficient). In other words, sensitivity to measurement failure and error can be a reason to reduce the number of signatures used from maximum (e.g., by one or two, etc.).
As explained, an LDS can utilize a region-based approach that utilizes an RTM where multivariable signatures can exist within multidimensional regions.
As an example, an LDS can utilize multivariable signatures X∈n of possible different types and convex geometrical shapes to describe regions of expected operation, regions of transition to leak and regions of leak. As an example, an LDS can utilize a signature distance to ambient/target that considers the ambient condition at the measurement position. As an example, an LDS can provide for combining multiple signatures to make leak detection systems more precise in terms of detecting leaks and avoiding false alarms. As an example, an LDS can include issuing one or more control instructions to equipment, which can be local and/or remote. For example, consider issuing a flow instruction to one or more pieces of a plant, issuing a control instruction to a vehicle (e.g., a drone, etc.), issuing a control instruction for acquiring sensor data, issuing a control instruction to one or more vessels (e.g., fishing, etc.) that may be navigating waters proximate to a plant or a portion thereof, etc.
As an example, an LDS can be a model-based pattern recognition and classification system that utilizes convex regions applied to leak detection in production systems.
As an example, an LDS can be implemented in an advisor framework (e.g., consider an OASE framework BASF SE, Ludwigshafen am Rhein, DE, etc.). In such an example, various sensor measurements may be provided, for example, via one or more interfaces.
As an example, an LDS can be a multivariable pattern-based leak detection system where signatures based on pressure measurements may be considered as to leaks to the surroundings.
As an example, an LDS can be described from basic building blocks, the signatures, to the main leak detector measure. As an example, in a production system with multiple subsea templates and transport pipelines, an LDS can be implemented in a hierarchical manner starting with the well instrumentation to form a well leak detector continuing with the pipelines to form pipeline leak detector and aggregating the different pipelines into sub-systems.
For example, consider an LDS divided into two sub-systems S12 and S34. Then again S12 consist of flowlines one and two (F1 and F2) and S34 consist of flowlines three and four (F3 and F4). In such an example, flowlines F1 and F2 interconnect three sub-sea manifolds (M1, M2 and M3) to the topside. In such an example, there were no transmitters on the sub-sea flowlines. That is, the sub-sea transmitters are located on the wellhead upstream the well isolation valves (PIV's). In such a system, there are topside pressure and temperature transmitter on the flowlines. Flowlines F3 and F4 interconnect a fourth subsea manifold (M4) to the topside.
In the example LDS, leak detector measures on the individual flowlines F1 to F4, leak detector measures for systems S12 and S34 were acquired and an overall leak detector measure. The system (plant) did not include well leak detectors.
As an example, an LDS can include (i) an interface to acquire on-line measurements in a relatively continuous manner where (ii) an on-line real time estimator model can provide for simulating the plant as if there were no leaks. In such an example, the LDS can include (iii) signatures to detect if there is particular difference between measured and estimated values can be utilized. As an example, an LDS may operate using (i) without (ii) and/or (iii). For example, consider a real time analysis LDS where regions are formed and utilized for comparisons with real time data for purposes of leak detection, which can include location and/or size estimation.
As an example, an LDS can include an ability to generate reconciled on-line measurements, a real time estimator calculating the behavior of the system as if there were no leaks, leak signatures, algorithms to combine the signatures into a leak detector measure and, for example, some extra functionality to make leak detectors robust against false alarms. As an example, a single signature can by itself be a leak detection measure; however, it may not be as robust as multivariable leak detectors with respect to measurement accuracy and false alarms.
As to signatures, a signature can be based on one or more of the following: (i) a single measurement, (ii) a combination of a single measurement and the corresponding simulated (e.g., OLGA estimated) value, or (iii) multiple measurements and the corresponding estimated values. As explained, an LDS may operate using a combination of a single measurement and a corresponding OLGA estimated value.
As an example, as to signature dependency on pipeline valves, an LDS can consider instances where on-line measurements behind a signature may become unavailable. For example, consider a transmission mode (wired and/or wireless), power, and/or sensor problem(s). As an example, a measurement may become inactive (not available) or fall out. Thus, signatures can have an activation signal. As an example, consider a well that can be routed to either of two transport flowlines F1 or F2 by proper setting of pipeline isolation valves (PIV's). If PIV1 (pipeline isolation valve towards F1) is open and PIV2 is closed (pipeline isolation valve towards F2), then the wellhead instrumentation can contribute towards signatures for flowline F1. If PIV1 is closed, then the wellhead instrumentation cannot contribute towards signatures for F1 since the wellhead is isolated from F1. The signature for F2 depends on PIV2 in a similar manner.
As to leak detection signatures with single measurement and an OLGA estimated value, consider a leak detection signature xi that includes the following inputs:
Consider, for example, two different formulas for the signature:
As to scaling the signature, consider the following two inputs that can be used to described expected behavior of the signature xl:
Then the scaled/normalized signature is given by:
As to activation/deactivation of signatures, consider the following activation signals:
Activation/deactivation signal values may be, for example: value 1 (one) signal/indicate active, value 0 (zero) signal indicate inactive. A signature active signal then becomes:
actiaacti·macti·gact
The active signature is:
{circumflex over (x)}
i
actx
As to binary output, zero/one output of {circumflex over (x)}i:
{tilde over (x)}
i
({circumflex over (x)}i>1)+({circumflex over (x)}i<−1)
As an example, a signature alarm item can be connected to GUI. For example, a signature alarm item based on {tilde over (x)}i and acti can be suited for the dynamical GUI element:
sa
i
(acti<0.5)*3+(acti≥0.5)·(({tilde over (x)}i≥0.5)·0+({tilde over (x)}i<0.5)·2)
Such output can be utilized by a computing device, a computing system, etc., to render an appropriate GUI to one or more displays.
As to signature inputs to populate, consider inputs to populate for each signature are:
As to signature outputs to populate, consider outputs to populate for each signature are:
As to signature properties/attributes, consider, for example, properties/attributes of a signature:
As an example, an LDS can include multiple leak detectors. In the example below, a single leak detector ldj is described.
A leak detector can make use of signatures xi as inputs. For an LDS, it can include at least one signature. As explained, a signature may become inactive. When the number of active signatures is less than a minimum then the leak detector may become inactive.
As an example, an LDS can include various types of leak detectors (LDs). For example, consider three types where the difference between the types comes from how they combine multiple signatures into a leak detection measure. As an example, a single signature can be used in multiple leak detectors.
As an example, an LDS can provide a leak detector for each well, production pipeline, sub-network of pipelines (sub-systems) and an overall leak detector for a field consisting of wells and multiphase pipelines.
As an example, a hierarchical leak detection system can make it easier to traverse a tree structure to narrow down the position of the leak.
As an example, networks of production wells, manifolds and pipelines interconnected can be cast as a leak detection problem that is a multivariable problem. By making use of multiple signatures, considering vectors of signatures and the directionality of leaks, the system can become more robust (e.g., less sensitive to) with respect to measurement noise, measurement malfunction, model errors and assumptions etc.
As an example, a leak detector sum can be the sum of the available signatures:
As an example, a leak detector can be active if sum of signature activation signals ld_act_sumj=Σi=1n acti is greater than a minimum number of signatures multiplied with the manual activation signal for the leak detector:
ld_actj(ldact
where
ld_act_minj
As an example, a leak can be identified if a sum is greater than a leak detection limit, multiplied with the active signal:
ld
j
(ldsum
As an example, a leak detector alarm item can be connected to a dynamic GUI element, which may be interactive through one or more human input devices (HIDs), one or more signals, one or more instructions, etc.
As an example, a leak detector alarm item may be based on ldj and ld_actj:
lda
j=(ld_actj<0.5)*3+(ld_actj≥0.5)·((ldj≥0.5)·0+(ldj<0.5)·2)
As an example, such output can be used by one or more dynamic GUI elements.
As an example, differences between three types of leak detectors can be based on what goes into the signature sum.
As an example, a leak detector can be based on minimum volume ellipsoids where, for example, axis aligned ellipsoids fit in the leak detector description of an LDS.
As to a point leak detector, consider a point leak detector sum defined as:
Note, the signatures x; are zero if they are inactive so inactive signatures do not contribute, thus an LDS can sum over the configured signatures.
Also, {tilde over (x)}i can be a zero/one value defined to be one if {tilde over (x)}i>1 or {tilde over (x)}i<−1 and zero if −1≤{tilde over (x)}i≤1. In other words, a point leak detector sum is the sum of the signatures identifying a leak.
As an example, a leak can be signaled by an LDS if the point leak detector sum ld_sumj is greater than a limit ld_limj.
As to a linear leak detector, consider a linear leak detector sum defined as:
Above, the sum is of the scaled signatures, so the non-zero signatures contribute. Note, the signatures {circumflex over (x)}i can be zero if they are inactive so inactive signatures do not contribute.
As an example, consider axes aligned ellipse for leak detection. In such an example, an axes aligned ellipse leak detector sum can be defined as:
Above, the sum is of the scaled signatures, so the non-zero signatures contribute. Note, the signatures {circumflex over (x)}i can be zero if they are inactive so inactive signatures do not contribute.
As an example, leak detector inputs to populate can include:
As an example, leak detector outputs to populate can include:
As an example, leak detector properties/attributes can include:
As to combining leak detectors, consider one or more of the following: (a) demand that one or more leak detector measures ldj to become one; and (b) sum multiple leak detector sums ld_sumj in the same way as a leak detector sum signatures and apply the same logic as for a leak detector.
As an example, an LDS may implement one or more time filtering techniques and/or other time processing techniques. For example, consider a time filtering (delay) approach on leak detection measure. As an example, an LDS may synchronize data acquisition, may interpolate data between measured times (e.g., sensor timestamps, etc.), etc.
As an example, an LDS can include time filtering that aims to reduce number and/or risk of false positives (e.g., false alarms), which may occur due to high frequency (e.g., with enough amplitude) changes in one or more measured variables. As an example, a filter can demand that a leak detector signal is true (e.g., binary value one) for at least 1 to 3 minutes for the measure to become active. As an example, an LDS may have a start-up period during which various checks are made to assure that measurements are being acquired and that the measurements make sense. In such an example, the LDS may generate noise assessments as to one or more channels. As an example, an LDS may operate using one or more noise assessments that may be for one or more measurements, measurement channels, etc. As an example, one or more approaches to leak detection may consider noise.
As an example, a GUI may render at least a portion of a network, which may be, for example, subsea loop. Consider as an example a loop with 8 wells, pairwise wells (CP4, CP8) can be routed to either FL3 or FL4 using. In such an example, pipeline isolation valves may be utilized. As an example, wells CP4 and CP8 may be routed to FL4.
As to wellhead instrumentation, each well can include three pressure and three temperature transmitters and a multiphase flow meter (MPFM) for measuring gas, oil, and water rate, which can contribute to signature on inlet of FL4. In such an example, four leak detection signatures may be generated, two subsea at inlet of FL3 and FL4 and two topside at outlet of FL3 and FL4. As an example, one or more complex loops may be tracked with three manifolds, 17 wells, 8 subsea LD signatures and two topside for a total of 10 LD signatures.
As explained, one or more signatures may be visualized in one or more multidimensional spaces, which may include one or more regions that can demarcate behaviors as to operation (e.g., leak/no leak, sensor OK, sensor NOK, etc.).
In
In
In
As an example, no leak operation can be represented by a surface between planes such that as long as operation is between the two planes then there is no leak for a corresponding signature. As an example, an operator may be able to adjust one or more boundaries and/or provide for automatic adjustment of one or more boundaries (e.g., responsive to one or more conditions, etc.). For example, where a sensor may be experiencing an issue, a boundary may be adjusted to account for the sensor related issue. As an example, one or more of the GUIs 3200, 3300 and 3400 may be customizable as to color, axes, number of planes or other boundaries, etc. As shown, projections may be made from a 3D surface onto a plane, which may be a base plane. As data are acquired in real time, one or more signatures may change, which may be projected and/or otherwise visualized. As an example, an LDS may provide for user interaction with a GUI or GUIs to insert one or more boundaries, move one or more boundaries, etc. (e.g., alarm boundaries, etc.).
As explained, an LDS may be implemented in one or more types of environments for one or more types of systems. As explained,
As an example, a method can include receiving real time data where the real time data include at least pressure sensor data from multiple pressure sensors of a hydrocarbon fluid production network for multiple locations in the hydrocarbon fluid production network; generating an expected operational region in a multidimensional domain using at least a portion of the real time data; operating a leak detection system using the expected operational region; tracking at least a portion of the real time data in the multidimensional domain; and issuing a leak detection signal responsive to the tracking indicating an excursion from the expected operational region, where the leak detection signal indicates the presence of a leak in the hydrocarbon fluid production network. In such an example, the tracking at least a portion of the real time data in the multidimensional domain can include tracking real time data for at least two of the multiple locations. For example, consider multiple locations that can include wellhead locations. As an example, wellhead locations can include corresponding wells that are in fluid communication with a common reservoir. In such an example, behavior at one wellhead may result in corresponding behavior at one or more other wellheads.
As an example, a hydrocarbon fluid production network can include at least one portion without a leak sensor. For example, consider an LDS that operates using sensor data from equipment sensors that are not expressly for leak sensing. In such an example, the equipment sensors may be part of wellhead equipment where such equipment sensors generate pressure and/or other data at or proximate to a wellhead. Such equipment sensors may be part of a wellhead assembly (e.g., a Christmas tree, etc.).
As an example, an expected operational region can be a convex hull. For example, consider an ellipsoid as a convex hull or, for example, a convex hull of ellipsoids.
As an example, tracking can generate a transient region in a multidimensional space where, for example, the transient region can be a convex hull. As an example, a transient region may be provided via simulation and may be revised using real time data.
As an example, a method can include refining at least one of an estimated leak location in real time and an estimated leak size in real time. As an example, a method can include transmitting instructions to dynamically render at least one graphic to a display that indicates at least one of an estimated leak location in real time and an estimated leak size in real time.
As an example, an expected operational region can characterize fluid communication between at least two of the multiple locations. For example, consider an expected operational region that characterizes fluid communication between at least two of multiple locations of a hydrocarbon fluid production network via a reservoir.
As an example, a leak can be an outward leak or an inward leak.
As an example, a leak can exhibit directionality in a multidimensional space. For example, consider directionality that corresponds to location where the directionality may point to one of two locations where a leak is between the two locations. As an example, tracking can include assessing one or more-time related aspects. For example, a large leak may move more rapidly in a multidimensional space than a smaller leak. As an example, it may take a longer time (real time) for a small leak transient to have an excursion outside of an expected operational region. As mentioned, a leak can also exhibit directionality. As an example, tracking can include assessing leak size and leak location dynamically using real time data.
As an example, an LDS can acquire pressure sensor data from multiple pressure sensors of a hydrocarbon fluid production network for multiple locations in the hydrocarbon fluid production network to impart redundancy that increases confidence of the LDS.
As an example, a method may alter, adjust, revise, etc., an operational region responsive to one or more operational changes. For example, consider using an operational schedule where a scheduled event can result in a change in operational region (e.g., an expected operational region, etc.).
As an example, a method can include utilizing a real time model to generate simulated data during operation of a hydrocarbon fluid production network and comparing at least a portion of the real time data to at least a portion of the simulated data.
As an example, a method can include receiving real time data that can include at least one of multiphase flow sensor data, temperature sensor data, salinity sensor data, viscosity sensor data, water break sensor data, emulsion sensor data, and density sensor data.
As an example, a method can include using an expected operational region that is a no leak region. In such a method, tracking within the expected operational region can be characterized as normal behavior unless the tracking fits within a leak transient region that includes a region that is outside of the expected operational region. As an example, a method can include testing a real time data against one or more transient regions as associated with evolution of leaks. For example, a testing approach can help to identify a type of leak while in a transient stage.
As an example, a method can include performing leak detection in a hydrocarbon fluid production network with a manifold where multiple pipelines join the manifold.
As an example, an LDS can operate using characterization. As an example, an LDS can operate using characterization and classification. As an example, an LDS can operate using classification. As an example, an LDS can operate using real time characterization and/or real time classification. As an example, an LDS can operate using model-based pattern recognition and classification based on convex regions applied to leak detection in one or more production systems.
As an example, a leak detection system can include a processor; memory accessible by the processor; and processor-executable instructions stored in the memory where the instructions include instructions to instruct the leak detection system to: receive real time data where the real time data include at least pressure sensor data from multiple pressure sensors of a hydrocarbon fluid production network for multiple locations in the hydrocarbon fluid production network; generate an expected operational region in a multidimensional domain using at least a portion of the real time data; operate a leak detection system using the expected operational region; track at least a portion of the real time data in the multidimensional domain; and issue a leak detection signal responsive to the tracking indicating an excursion from the expected operational region, where the leak detection signal indicates the presence of a leak in the hydrocarbon fluid production network.
As an example, one or more computer-readable storage media can include computer-executable instructions executable by a computer, the instructions include instructions to: receive real time data where the real time data include at least pressure sensor data from multiple pressure sensors of a hydrocarbon fluid production network for multiple locations in the hydrocarbon fluid production network; generate an expected operational region in a multidimensional domain using at least a portion of the real time data; operate a leak detection system using the expected operational region; track at least a portion of the real time data in the multidimensional domain; and issue a leak detection signal responsive to the tracking indicating an excursion from the expected operational region, where the leak detection signal indicates the presence of a leak in the hydrocarbon fluid production network.
In some embodiments, the methods of the present disclosure may be executed by a computing system.
A processor may include a microprocessor, microcontroller, processor module or subsystem, programmable integrated circuit, programmable gate array, or another control or computing device.
The storage media 3506 may be implemented as one or more computer-readable or machine-readable storage media. Note that while in the example embodiment of
It may be appreciated that computing system 3500 is an example of a computing system, and that computing system 3500 may have more or fewer components than shown, may combine additional components not depicted in the example embodiment of
Further, the steps in the processing methods described herein may be implemented by running one or more functional components in information processing apparatus such as general-purpose processors or application specific chips, such as ASICs, FPGAs, PLDs, or other appropriate devices. Such components, combinations of these components, and/or their combination with general hardware may be utilized as part of a system and/or to implement one or more methods.
Geologic interpretations, models, and/or other interpretation aids may be refined in an iterative fashion; this concept is applicable to the methods discussed herein. This may include use of feedback loops executed on an algorithmic basis, such as at a computing device (e.g., computing system 3500,
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).
In an example embodiment, components may be distributed, such as in the network system 3610. The network system 3610 includes components 3622-1, 3622-2, 3622-3, . . . 3622-N. For example, the components 3622-1 may include the processor(s) 3602 while the component(s) 3622-3 may include memory accessible by the processor(s) 3602. Further, the component(s) 3622 may include an I/O device for display and optionally interaction with a method. The network may be or include the Internet, an intranet, a cellular network, a satellite network, etc.
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.
This application claims priority to and the benefit of a US Provisional application having Ser. No. 63/122,346, filed 7 Dec. 2020, which is incorporated by reference herein.
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/US2021/072769 | 12/7/2021 | WO |
Number | Date | Country | |
---|---|---|---|
63122346 | Dec 2020 | US |