WO2016133850A1 - Determining downtime for a pump - Google Patents

Abstract

A method for determining a downtime of a pump includes receiving first and second data packets. The first data packet includes parameters relating to operation of the pump at a first time, and the second data packet includes parameters relating to operation of the pump at a second time that is after the first time. The first and second data packets are filtered. The parameters in the first and second data packets are compared to determine whether the pump was turned on, off, or both between the first time and the second time. The downtime of the pump is then determined based at least partially upon the determination whether the pump was turned on, off, or both between the first time and the second time.

Description

DETERMINING DOWNTIME FOR A PUMP

Cross-Reference to Related Applications

[0001] This application claims priority to U.S. Provisional Patent Application having Serial No. 62/116,787, filed on February 16, 2015. The entirety of this priority provisional patent application is incorporated by reference herein.

Background

[0002] More than 90% of producing oil wells may use some form of artificial lift. Most of these wells reside in mature fields where reservoirs do not have enough energy to naturally produce oil or gas to the surface at a desired economic rate. This energy shortfall may occur when the reservoir pressure has been depleted through production. One type of artificial lift uses electric submersible pumps ("ESPs"). Pump surveillance (e.g., monitoring, diagnosis, and control) has proven valuable in maximizing both the run life of the ESP and well performance. Surveillance throughout the operational life of the ESP may provide valuable information to identify the cause of failure should the system fail before its normal life expectancy. Real-time analysis may enable the operator to make changes to increase the run life of the pump without adding to well downtime.

Summary

[0003] A method for determining a downtime of a pump is disclosed. The method includes receiving first and second data packets. The first data packet includes parameters relating to operation of the pump at a first time, and the second data packet includes parameters relating to operation of the pump at a second time that is after the first time. The first and second data packets are filtered. It is then determined whether the first and second data packets include a sufficient set of parameters to perform a first determination of the downtime of the pump. In response to determining that the first and second data packets include the sufficient set of parameters to perform the first determination, the parameters in the first and second data packets are compared to determine whether the pump was turned on, off, or both between the first time and the second time. The downtime of the pump is then determined based at least partially upon the determination whether the pump was turned on, off, or both between the first time and the second time.

[0004] In another embodiment, the method includes receiving first, second, and third data packets. The first data packet includes parameters relating to operation of the pump at a first time, and second data packet includes parameters relating to operation of the pump at a second time that is after the first time, and the third data packet includes parameters relating to operation of the pump at a third time that is after the second time. The second data packet is discarded when a comparison of the first data packet and the second data packet indicates an inconsistency. It is determined whether the first and third data packets include a sufficient set of parameters to perform a determination of the downtime of the pump. In response to determining that the first and third data packets include the sufficient set of parameters to perform the determination, the parameters in the first and third data packets are compared to determine whether the pump was turned on, off, or both between the first time and the third time. The downtime of the pump is determined based at least partially upon the determination whether the pump was turned on, off, or both between the first time and the third time.

[0005] A computing system is also disclosed. The computing system includes a processor and a memory system. The memory system includes a non-transitory computer-readable medium storing instructions that, when executed by the processor, cause the computing system to perform operations. The operations include receiving a first data packet including parameters relating to operation of the pump at a first time and receiving a second data packet including parameters relating to operation of the pump at a second time that is after the first time. The first and second data packets are filtered. It is then determined whether the first and second data packets include a sufficient set of parameters to perform a first determination of the downtime of the pump. The sufficient set of parameters includes an electrical current supplied to the pump, a frequency of the pump, a number of times that the pump has started, an amount of time since the pump last started, and an amount of time since the pump last stopped. In response to determining that the first and second data packets include the sufficient set of parameters to perform the first determination, the method includes comparing the parameters in the first and second data packets to determine whether the pump was turned on, off, or both between the first time and the second time. The downtime of the pump is then determined based at least partially upon the determination whether the pump was turned on, off, or both between the first time and the second time.

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

Brief Description of the Drawings

[0007] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the present teachings and together with the description, serve to explain the principles of the present teachings. In the figures:

[0008] Figure 1 illustrates a schematic view of a wellsite, according to an embodiment.

[0009] Figure 2 illustrates a conceptual, schematic view of plurality of data packets from a pump, according to an embodiment.

[0010] Figure 3 illustrates the data packets from Figure 2 showing possible stop and start times for the pump, according to an embodiment.

[0011] Figure 4 illustrates a historical data chart including a plurality of parameters relating to the pump, according to an embodiment.

[0012] Figure 5 illustrates a flowchart of a method for determining a downtime of a pump, according to an embodiment.

[0013] Figure 6 illustrates a schematic view of a computing system for performing at least a portion of the method, according to an embodiment.

Detailed Description

[0014] Reference will now be made in detail to specific embodiments illustrated in the accompanying drawings and figures. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be apparent to one of ordinary skill in the art that embodiments may be practiced without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure aspects of the embodiments. [0015] It will also be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used to distinguish one element from another. For example, a first object could be termed a second object, and, similarly, a second object could be termed a first object, without departing from the scope of the present disclosure.

[0016] The terminology used in the description of the invention herein is for the purpose of describing particular embodiments and is not intended to be limiting. As used in the description of the invention and the appended claims, the singular forms "a," "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms "includes," "including," "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. Further, as used herein, the term "if may be construed to mean "when" or "upon" or "in response to determining" or "in response to detecting," depending on the context.

[0017] Figure 1 illustrates a schematic view of a wellsite 100, according to an embodiment. The wellsite 100 may include a wellbore 110. A casing 112 may be coupled to the wall of the wellbore 110 by a layer of cement. A tubing string (e.g., a production string) 114 may be positioned radially-inward from the casing 112. An annulus 116 may be defined between the casing 112 and the tubing string 114.

[0018] The wellsite 100 may also include an artificial-lift system 120. The artificial-lift system 120 may add energy to the fluid column in the wellbore 1 10 with the objective of initiating and improving production from the wellbore 1 10. The artificial-lift system 120 may use a range of operating principles, including rod pumping, gas lift, and electric submersible pumps. As shown, the artificial-lift system 120 may include a pump (e.g., an electric submersible pump) 122. The pump 122 may be positioned within the wellbore 110. The pump 122 may include several staged centrifugal pump sections that may be configured to suit the production and wellbore characteristics of a given application. [0019] The artificial-lift system 120 may also include a discharge head 124, a discharge- pressure assembly 126, one or more seals 128, a driver (e.g., an electric motor) 130, a pressure- transfer line 132, a multi-sensor unit 134, or a combination thereof. The multi-sensor unit 134 may include one or more sensors that are configured to measure one or more parameters relating to the artificial-lift system 120. The parameters may include any of those listed below. A stringer assembly 136, a polished-bore receptacle 138, and a sump packer 140 may be positioned in the wellbore 110, below the artificial-lift system 120.

[0020] Figure 2 illustrates a conceptual, schematic view of a plurality of data packets 201-205 from the artificial-lift system 120 (e.g., the pump 122), according to an embodiment. As shown, the data packets 201-205 are transmitted and/or received every ten minutes. In other embodiments, the time interval between consecutive data packets 201-205 may be greater or smaller. In addition, the time interval between each pair of consecutive data packets 201-205 is shown to be constant (e.g., ten minutes); however, in other embodiments, the time intervals may vary in duration.

[0021] As shown, each data packet 201-205 may include one or more parameters. As shown, the parameters include the run status of the pump 122 (e.g., running or off), the frequency of the pump 122, the current supplied to the pump 122, and the number of times the pump 122 has started. Although four parameters are shown, in other embodiments, the number of parameters may be greater or fewer, as described below.

[0022] Figure 3 illustrates the data packets 201-205 from Figure 2 showing possible stop and start times for the artificial-lift system 120 (e.g., the pump 122), according to an embodiment. The data packets 201-205 indicate that the pump 122 was running at 10:40 am, and the pump 122 was not running at 10:50 am. From this information, it may be concluded that the pump 122 stopped (at least once) during the time interval between these two data packets 201, 202. Similarly, the data packets 201-205 indicate that the pump 122 was off at 11 :00 am, and the pump 122 was running at 1 1 : 10 am. From this information, it may be concluded that the pump 122 started during the time interval between these two data packets 204, 205.

[0023] As discussed in more detail below, a downtime calculation module may be implemented on a computing device to determine downtime and uptime information from the data packets 201-205. As used herein, "downtime" refers to the period from a pump stop to the following start, and "uptime" refers to the period from a pump start to the following stop. The downtime calculation module may include a calculation engine that uses the data packets 201- 205 to determine when the pump 122 starts and stops. The downtime calculation module may thus calculate downtime, uptime, number of starts and stops for a given period of time.

[0024] Figure 4 illustrates a data chart 400 including a plurality of parameters relating to the pump 122, according to an embodiment. In one embodiment, a user may look at a plurality of parameters to determine the performance of the pump 122. For example, a surveillance engineer may look at data from the pump 122 for the past 3-7 days for certain parameters (e.g., drive frequency, current, intake pressure, temperature, etc.) and may also look at field performance indicators.

[0025] The field performance indicators may enable the user to view detailed information relating to uptime and downtime of the wells in the field. The field performance indicators may include: the number of wells online and offline (may be displayed in a bar chart); the average field uptime (may be displayed as a pie chart of percentage uptime and downtime); and the average field downtime for the current and previous month, with an indicator to show if the trend is going up or down.

[0026] Well-level performance indicators may be calculated for specified time periods. The time period may be, for example, one month. The well-level performance indicators may include: uptime duration; downtime duration; uptime percentage; downtime percentage; number of starts; number of stops; shutdown cause; downtime distribution; shutdown cause; and stop count distribution.

[0027] Weekly, monthly, quarterly, or other time period reports may be generated that include performance indicators. As a result, many performance indicators include determining the times of starts and stops of the pump 122. This data may not be present in the raw runtime data of a device, such as the pump 122. As such, it may be deduced from other parameters.

[0028] Returning to the example in Figure 1, the pump 122 stopped between 10:40 am and 10:50 am and was started again between 11 :00 am and 11 : 10 am. The start and stop times may not be reported directly and, thus, may be deduced from the other parameters. In one embodiment, the downtime module may consider: the number of times the pump 122 has been started since it was commissioned; the number of hours the pump 122 has run since the latest start; the number of hours the pump 122 has been off since the last stop; a cumulative of the aggregate run time since the pump 122 was commissioned; whether the pump 122 is currently running or not; or a combination thereof.

[0029] Another data quality issue may arise with a race condition between the pump's starting up or shutting down and the data reporting. The pump's operational parameters may be reported so, for example, the run time status may be reported before the number of starts. If the pump 122 turns on after the first one but before the second one is reported, the data packets 201-205 may be inconsistent, with half of the data referring to the conditions before the start, and the other half referring to the conditions after the start. Inconsistent records may lead to incorrect conclusions. The approach may involve identifying inconsistent packets and ignoring them.

[0030] Certain devices may have lesser capabilities. For example, the pump 122 may be controlled by less sophisticated drives that do not provide a detailed snapshot of the pump's operational parameters. In this case, it may not be possible to calculate with precision the exact times of the pump start and stop. However, even in such cases, the downtime calculation module may provide an approximation by determining when the pump's running time status changes. If a current data packet (e.g., packet 202) reports that the pump 122 is running and the previous data packet (e.g., packet 201) reports that the pump 122 is not running, the downtime calculation module may deduce that the pump 122 started between the time the two data packets 201, 202 were sent. Stops may be treated similarly.

[0031] Figure 5 illustrates a flowchart of a method 500 for determining a downtime of a pump 122, according to an embodiment. Although the method 500 is described with reference to a pump, it will be appreciated that the method 500 may also be used to determine the downtime of other devices that have two states (e.g., running and not running) and for which runtime may be a performance indicator. For example, in other embodiments, the device may be a motor, a variable speed drive, a horizontal pumping system ("HPS"), a progressing cavity pump ("PCP"), a sucker rod pump ("SRP"), a multiphase booster, a gas lift system, or the like.

[0032] The method 500 may include measuring one or more parameters relating to operation of a pump 122 using one or more sensors 134, as at 502. The parameters may include the electrical current supplied to the pump 122, a frequency or speed of the pump 122, a total number of times that the pump 122 has started, an amount of time since the last time the pump 122 started, an amount of time since the last time the pump 122 stopped, a contactor output, the amount of time the pump 122 has been running since it was commissioned, or a combination thereof. As used herein, the "contactor output" refers to an indicator whether the mechanism (e.g., switch) that turns the pump 122 on and off is open or closed.

[0033] The method 500 may also include receiving data packets 201-205 (e.g., at the computing system 600) from the sensors 134, each data packet 201-205 including one or more of the parameters, as at 504. As shown in Figure 2, a first data packet 201 may be received at 10:30 am, a second data packet 202 may be received at 10:40 am, a third data packet 203 may be received at 10:50 am, and so on. Thus, the time interval between each data packet 201-205 may be constant. In other embodiments, however, the time intervals may vary. For example, a user may request a data packet at 10:34 am. When a user requests a data packet, the user may also request a specific subset of parameters. As such, the requested data packet may not include some of the parameters that are transmitted at the scheduled times (e.g., 10:30 am, 10:40 am, etc.).

[0034] The method 500 may also include cleaning or filtering the data packets 201-205 after the data packets 201-205 are received, as at 506. Cleaning may include identifying the data packets 201-205 that do not contain enough information (e.g., parameters) to determine when the pump 122 is started or stopped. In another embodiment, cleaning may also include identifying two (or more) data packets 201-205 that include incompatible or inconsistent data. For example, the first data packet 201 may indicate that the pump 122 is off and the total number of starts is 17, and the second data packet 202 may indicate that the pump 122 is on and the total number of starts is still 17. When this occurs, one or both of the packets 201, 202 may be flagged as containing incorrect parameters and not used in the following portion of the method 500. Cleaning/filtering the data is described in more detail below.

[0035] The method 500 may also include determining whether the data packets 201-205 include a sufficient set of parameters to perform a first (e.g., high-quality determination) or a second (e.g., low-quality determination) of the downtime of the pump 122, as at 508. The high- quality determination may be more precise than the low-quality determination. More particularly, the high-quality determination may be able to determine more precisely when the pump 122 starts and stops, and to determine more precisely the pump downtime. In one embodiment, the data includes a sufficient set of parameters to perform the high-quality determination when the data includes at least the following five parameters: (1), the electrical current supplied to the pump 122 (2) the speed or frequency of the pump 122, (3) the total number of times that the pump 122 has started, (4) the amount of time since the last time the pump 122 started, and (5) the amount of time since the last time the pump 122 stopped. In another embodiment, the data includes a sufficient set of parameters to perform the high-quality determination when the data includes the five parameters above plus a sixth parameter: total time that the pump 122 has been running since it was commissioned. This may allow for a more precise approximation of the starting and stopping of the pump 122 (e.g., when the number of starts jumps by two or more). In one embodiment, the data includes a sufficient set of parameters to perform the low-quality determination when the data includes at least the following three parameters: (1) the electrical current supplied to the pump 122, (2), the speed or frequency of the pump 122, and (3) the contactor output.

[0036] If the data packets 201-205 include a sufficient set of parameters to perform the high- quality determination, the method 500 may include comparing the parameters in two of the data packets (e.g., data packets 201, 202) to determine whether the pump 122 was turned on, off, or both in a time interval between the two data packets 201-202, as at 510. In at least one embodiment, the two data packets 201, 202 that are compared may be consecutive data packets (e.g., the data packets at 10:30 am and 10:40 am). The comparison may be performed for a plurality of pairs of data packets 201-205. For example, it may also be determined whether (and when) the pump 122 started and/or stopped between 10:40 am and 10:50 am using the data packets 202, 203 at 10:40 am and 10:50 am, whether (and when) the pump 122 started and/or stopped between 10:50 am and 11 :00 am using the data packets 203, 204 at 10:50 am and 1 1 :00 am, and so on. In at least one embodiment, the parameters may be compared in a fixed/predetermined order. For example, the electrical current supplied to the pump 122 may be compared in the two data packets 201, 202. If the electrical current information is not available, the speed or frequency of the pump 122 may be compared in the two data packets 201, 202. If the speed or frequency information is not available, the total number of times that the pump 122 has started may be compared in the two data packets 201, 202. If the total number of times that the pump 122 has started is not available, the amount of time since the last time the pump 122 started may be compared in the two data packets 201, 202. If the amount of time since the last time the pump 122 started is not available, the amount of time since the last time the pump 122 stopped may be compared in the two data packets 201, 202.

[0037] The method 500 may then include determining the downtime of the pump 122 over a predetermined period of time using the determination whether the pump 122 was turned on, off or both, as at 512. The predetermined time period may be a day, a week, a month, a quarter, a year, the lifespan of the pump 122, or any other time period selected by the user. For example, the user may want to determine the amount of time that the pump 122 has been off over the previous 24 hours. The time(s) that the pump 122 has been turned on and/or off has/have been determined above (e.g., at 514). Based on this information, the aggregate time that the pump 122 has been off (i.e., the downtime) may be determined over the previous 24 hours.

[0038] If the data packets 201-205 include a sufficient set of parameters to perform the low- quality determination, but not a sufficient set to perform the high-quality determination, the method 500 may include comparing the parameters in two of the data packets (e.g., data packets 201, 202) to determine whether the pump 122 was turned on, off, or both in a time interval between the two data packets 201, 202, as at 514. In at least one embodiment, the two data packets 201, 202 that are compared may be consecutive data packets (e.g., the data packets at 10:30 am and 10:40 am). The comparison may be performed for a plurality of pairs of data packets 201-205. For example, it may also be determined whether (and when) the pump 122 started and/or stopped between 10:40 am and 10:50 am using the data packets 202, 203 at 10:40 am and 10:50 am, whether (and when) the pump 122 started and/or stopped between 10:50 am and 11 :00 am using the data packets 203, 204 at 10:50 am and 11 :00 am, and so on. In at least one embodiment, the parameters may be compared in a fixed order. For example, the electrical current supplied to the pump 122 may be compared in the two data packets 201, 202. If the electrical current information is not available, the speed or frequency of the pump 122 may be compared in the two data packets 201, 202. If the speed or frequency information is not available, the contactor output may be compared in the two data packets 201, 202.

[0039] The method 500 may then include determining the downtime of the pump 122 over a predetermined period of time using the determination whether the pump 122 was turned on, off or both, as at 516. The predetermined time period may be a day, a week, a month, a quarter, a year, the lifespan of the pump 122, or any other period of time selected by the user. For example, the user may want to determine the amount of time that the pump 122 has been off over the previous 24 hours. The time(s) that the pump 122 has been turned on and/or off has/have been determined above (e.g., at 510). Based on this information, the aggregate time that the pump 122 has been off (i.e., the downtime) may be determined over the previous 24 hours. [0040] The method 500 may also include taking the pump 122 offline to repair or replace the pump 122 in response to the calculated downtime, as at 518. For example, the user may determine that the well produces too much gas, or the pump is not the appropriate size (e.g., well flowrate is not within a predetermined range). In response to this, the user may replace the pump 122 with a different pump that will run a different percentage of the time. In another embodiment, the user may vary the pressure and/or flowrate of the fluid flowing out of the pump 122 in response to the calculated downtime. In another embodiment, the user may see that the pump 122 is off less than a predetermined percentage of the time from the calculated downtime. In response to this, the user may decide to no longer request real-time surveillance of the pump 122. In contrast, if the user sees that the pump 122 is off more than the predetermined percentage of the time, the user may select to have real-time surveillance.

[0041] In one embodiment, the data includes a sufficient set of parameters to perform the high- quality determination when the data includes the following five parameters: (1), drive run status S, (2) the drive run hours ¾, (3) the drive off hours Hd₀, (4) the number of starts N, and (5) the total run hours H_tr. The drive run status S has two possible values: 1 for running and 0 for off. The drive run hours Hdr represents the number hours elapsed since the last pump start. It may remain constant when the pump 122 is off, and it may increase when the pump 122 is running. It may be reset each time the pump 122 starts. The drive off hours Hd₀ represents the number of hours elapsed since the last pump stop. It may remain constant when the pump 122 is running, and it may increase when the pump 122 is off. It may be reset each time the pump 122 stops. The number of starts N may increase by one for each single pump start. The value may increase over time, unless there is a pump change event. The total run hours ¾ represents the total run time hours for the life of the pump 122.

[0042] A primary pump event timestamp T_p may be a pump start event if S is 1 or a pump stop event if S is 0. Equations (1) and (2) below describe T_p:

T_p = T- H_dr (ifS = 1) (1)

T_p = T- H_do (ifS = 0) (2)

[0043] A secondary pump event timestamp T_s may be a pump start event if S is 0 or a pump stop event if S is 1. The primary and secondary pump events are the reverse of one another. Equation (3) below describes T_s:

[0044] The time elapsed T_e may be the time difference between the timestamps of two data packets. As such:

T_e = T² - T¹ (4)

[0045] The superscript text represents the index of data packets in the time series. As such, T¹ represents the timestamp of the first data packet, and T² represents the timestamp for the second data packet.

[0046] The filtering process (e.g., at 506 above) may analyze two consecutive data packets. After comparing two such data packets, the downtime calculation module may determine that no pump event has occurred, meaning that the pump 122 remains off or continues running between the time stamps of the two data packets. The downtime calculation module may also determine that a single pump event has occurred, meaning that the pump 122 has started or stopped between the time stamps of the two data packets T¹, T². The downtime calculation module may also determine that multiple pump events have occurred.

[0047] When S¹ = 0 and S² = 1, meaning that the pump 122 was stopped and then started, which should increase the number of starts by 1, but the number of starts remains constant (i.e., N²=N¹), the second data packet may be discarded. When S¹ = 1 and S² = 1, meaning that the pump keeps running, but Hdr² < Hdr¹ or Hdo² > Hdo¹, the second data packet may be discarded. When S¹ = 0 and S² = 0, meaning that the pump stays off, but Hdr²≠ /^ (drive run hours changed) or Hdo² ≤ Hdo¹ (drive off hours didn't increase), the second data packet may be discarded. When S¹ = 1 and S² = 0, meaning that the pump was on and then stopped, but Hdr²≤ Hdr¹, the second data packet may be discarded.

[0048] When T_p < T¹ , meaning that the primary pump event (e.g., pump stop event) happened before the first data packet timestamp, but the number of starts remains constant (i.e., N²=N^X), the second data packet may be discarded. The event is supposed to happen between data packets. When T_s > T¹, meaning that the secondary event (e.g., pump start event) happened after the first data packet timestamp, but the number of starts remains constant (i.e., N²=N^X), the second data packet may be discarded. In this scenario, a primary pump event has occurred between the data packets, and there is supposed to be a single pump event (otherwise the number of starts will increase) in between data packets.

[0049] When T_p < T¹ , meaning that the primary event happened before the first data packet timestamp, but the number of starts increased by one (i.e., N² = N¹ + 1), the second data packet may be discarded. In this scenario, the primary event is supposed to happen between data packets. When S¹ = 0, S² = 1, and T_s > T¹, but the number of starts increased by one (i.e., N² = N¹ + 1), the second data packet may be discarded. S¹ = 0, S² = 1 means that the pump was stopped and then started, which increases the number of starts by 1. T_s > T¹ means that the secondary event timestamp sits in between the timestamps of the two data packets, and this indicates multiple pump events, which is not true in this case. For other scenarios that are not from stop to start, multiple events occurred. Thus, the secondary downtime module should account for the secondary event. When T_s < T¹, the second data packet may be discarded.

[0050] When T_p < T¹, meaning that the primary event happened before the first data packet timestamp, but the number of starts increased by more than one (i.e., N² > N¹ + 1), the second data packet may be discarded. The primary event is supposed to happen between the data packets. When T_s < T¹, meaning that the secondary event happened before the first data packet timestamp, but the number of starts increased by more than one (i.e., N² > N¹ + 1), the second data packet may be discarded. The secondary event is supposed to happen between the data packets. When H_tr ² - H_tr ^l < Hd ², meaning that the total run hour difference is less than the drive run hours of the second package, but the number of starts increased by more than one (i.e., N² > N¹ + 1), the second data packet may be discarded.

[0051] When T_p = T_s, second data packet may be discarded. After the second packet is discarded, the process may advance to the third data packet, consider this packet to be the second packet, and perform the analysis again.

[0052] There may be no events when N and S are unchanged. When N is unchanged, and S changes from 1 to 0, it may be determined that a single event (e.g., pump stop) has occurred. When N increases by 1 and S changes from 0 to 1, it may be determined that a single event (e.g., pump start) has occurred. For other scenarios, it may be determined that multiple events have occurred. More particularly, starting from the second data packet timestamp and going backwards, a primary event occurs and then a secondary event occurs. So, by default, two events have been accounted for. Between the timestamp for the first data packet T¹ and the timestamp for the secondary event T_s, other events may have occurred. The gap T_g may be represented by equation (5):

[0053] The unallocated drive run hours may be represented by equation (6):

[0054] The unaccounted for N difference is represented by equation (7):

N² - N⁷ - l (7)

[0055] Starting from the secondary event timestamp and going backwards, pairs of events may be inserted, beginning with a start event (if S² = 1) and then stop event, or a stop event and then a start event (if S² = 0) in a loop. The number of loops may be represented by equation (7) or (8) if ^ = 0 and S² =l .

tf - N¹ - ! (8)

[0056] When S¹≠ S² (i.e., the run status has changed), a single event is inserted after the timestamp of first data packet to pair up (or pair down) the event. Event pairs may be inserted in the loop without changing the pump status. To account for the change in status, the pump start may be inserted (if the first data packet indicates that the pump 122 is off), or the pump stop may be inserted (if the first data packet indicates that the pump 122 is on). As the pump start increments N, the number of loops may be represented by equation (9) if S¹ = 0 and S² =1.

tf - N¹ - ! (9)

[0057] This may indicate that there is one pump start outside the loop. The step length (used for the event calculation inside the loop) for unallocated pump start duration may be represented by equation (10).

(Htr¹ - H_tr ^l - Hd ²)l( N² - N¹ - 1 ) (10)

[0058] Figure 6 illustrates a schematic view of a computing system 600 for performing at least a portion of the method, according to an embodiment. The computing system 600 may include a computer or computer system 601A, which may be an individual computer system 601A or an arrangement of distributed computer systems. The computer system 601 A includes one or more analysis modules 602 that are configured to perform various tasks according to some embodiments, such as one or more methods disclosed herein. To perform these various tasks, the analysis module 602 executes independently, or in coordination with, one or more processors 604, which is (or are) connected to one or more storage media 606. The processor(s) 604 is (or are) also connected to a network interface 607 to allow the computer system 601 A to communicate over a data network 609 with one or more additional computer systems and/or computing systems, such as 601B, 601C, and/or 601D (note that computer systems 601B, 601C and/or 601D may or may not share the same architecture as computer system 601A, and may be located in different physical locations, e.g., computer systems 601A and 601B may be located in a processing facility, while in communication with one or more computer systems such as 1601C and/or 60 ID that are located in one or more data centers, and/or located in varying countries on different continents).

[0059] A processor may include a microprocessor, microcontroller, processor module or subsystem, programmable integrated circuit, programmable gate array, or another control or computing device.

[0060] The storage media 606 may be implemented as one or more computer-readable or machine-readable storage media. Note that while in the example embodiment of Figure 6 storage media 606 is depicted as within computer system 601A, in some embodiments, storage media 606 may be distributed within and/or across multiple internal and/or external enclosures of computing system 601 A and/or additional computing systems. Storage media 606 may include one or more different forms of memory including semiconductor memory devices such as dynamic or static random access memories (DRAMs or SRAMs), erasable and programmable read-only memories (EPROMs), electrically erasable and programmable read-only memories (EEPROMs) and flash memories, magnetic disks such as fixed, floppy and removable disks, other magnetic media including tape, optical media such as compact disks (CDs) or digital video disks (DVDs), BLURAY^® disks, or other types of optical storage, or other types of storage devices. Note that the instructions discussed above may be provided on one computer-readable or machine-readable storage medium, or alternatively, may be provided on multiple computer- readable or machine-readable storage media distributed in a large system having possibly plural nodes. Such computer-readable or machine-readable storage medium or media is (are) considered to be part of an article (or article of manufacture). An article or article of manufacture may refer to any manufactured single component or multiple components. The storage medium or media may be located either in the machine running the machine-readable instructions, or located at a remote site from which machine-readable instructions may be downloaded over a network for execution.

[0061] In some embodiments, the computing system 600 contains one or more downtime calculation module(s) 608. The downtime calculation module(s) 608 may be configured to determine the downtime of the pump 122, as described in greater detail above. [0062] It should be appreciated that computing system 600 is but one example of a computing system, and that computing system 600 may have more or fewer components than shown, may combine additional components not depicted in the example embodiment of Figure 6, and/or computing system 600 may have a different configuration or arrangement of the components depicted in Figure 6. The various components shown in Figure 6 may be implemented in hardware, software, or a combination of both hardware and software, including one or more signal processing and/or application specific integrated circuits.

[0063] Further, the steps in the processing methods described herein may be implemented by running one or more functional modules in information processing apparatus such as general purpose processors or application specific chips, such as ASICs, FPGAs, PLDs, or other appropriate devices. These modules, combinations of these modules, and/or their combination with general hardware are all included within the scope of protection of the invention.

[0064] The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. Moreover, the order in which the elements of the methods described herein are illustrate and described may be re-arranged, and/or two or more elements may occur simultaneously. The embodiments were chosen and described in order to best explain the principals of the invention and its practical applications, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated.

Claims

CLAIMS What is claimed is:

1. A method for determining a downtime of a pump, comprising:

receiving a first data packet including a plurality of parameters relating to operation of the pump at a first time;

receiving a second data packet including a plurality of parameters relating to operation of the pump at a second time that is after the first time;

filtering the first and second data packets;

determining whether the first and second data packets include a sufficient set of parameters to perform a first determination of the downtime of the pump;

in response to determining that the first and second data packets include the sufficient set of parameters to perform the first determination, comparing the parameters in the first and second data packets to determine whether the pump was turned on, off, or both between the first time and the second time; and

determining the downtime of the pump based at least partially upon the determination whether the pump was turned on, off, or both between the first time and the second time.

2. The method of claim 1, wherein filtering the first and second data packets comprises determining whether the parameters in the first and second data packets are inconsistent or incompatible.

3. The method of claim 1, wherein the sufficient set of parameters to perform the first determination comprises:

an electrical current supplied to the pump;

a frequency of the pump;

a number of times that the pump has started;

an amount of time since the pump last started; and

an amount of time since the pump last stopped.

4. The method of claim 1, wherein the first and second data packets are consecutive data packets.

5. The method of claim 1, further comprising:

receiving a third data packet including a plurality of parameters relating to operation of the pump at a third time, wherein the third time is between the first and second times;

filtering the third data packet; and

discarding the third data packet in response to filtering the third data packet.

6. The method of claim 1, further comprising determining whether the first and second data packets include a sufficient set of parameters to perform a second determination of the downtime of the pump when the first and second data packets do not include the sufficient set of parameters to perform the first determination of the downtime of the pump.

7. The method of claim 6, wherein the first determination is more precise than the second determination.

8. The method of claim 6, wherein the sufficient set of parameters to perform the second determination comprises:

an electrical current supplied to the pump;

a frequency of the pump; and

a contactor output.

9. The method of claim 6, wherein the parameters are compared in a predetermined order.

10. The method of claim 1, further comprising taking the pump offline and repairing the pump or replacing the pump with a different pump.

11. A method for determining a downtime of a pump, comprising:

receiving a first data packet including a plurality of parameters relating to operation of the pump at a first time; receiving a second data packet including a plurality of parameters relating to operation of the pump at a second time that is after the first time;

receiving a third data packet including a plurality of parameters relating to operation of the pump at a third time that is after the second time;

discarding the second data packet when a comparison of the first data packet and the second data packet indicates an inconsistency;

determining whether the first and third data packets include a sufficient set of parameters to perform a determination of the downtime of the pump;

in response to determining that the first and third data packets include the sufficient set of parameters to perform the determination, comparing the parameters in the first and third data packets to determine whether the pump was turned on, off, or both between the first time and the third time; and

determining the downtime of the pump based at least partially upon the determination whether the pump was turned on, off, or both between the first time and the third time.

12. The method of claim 11, wherein the sufficient set of parameters comprises:

a drive run status of the pump;

a number of drive run hours of the pump;

a number of drive off hours of the pump;

a number of times the pump has started; and

a total run hours of the pump;

13. The method of claim 1 1, wherein the inconsistency comprises the pump stopping and then starting, but the number of times the pump has started remaining constant.

14. The method of claim 11, wherein the inconsistency comprises the pump continuing to run, but either the number of drive run hours at the second time is less than or equal to the number of drive run hours at the first time or the number of drive off hours at the second time is greater than the number of drive off hours at the first time.

15. The method of claim 1 1, wherein the inconsistency comprises the pump remaining off, but either the number of drive run hours at the second time is not equal to the number of drive run hours at the first time or the number of drive off hours at the second time is less than or equal to the number of drive off hours at the first time.

16. The method of claim 11, wherein the inconsistency comprises a primary pump event occurring before the first time, but the number of times the pump has started remaining constant.

17. The method of claim 1 1, wherein the inconsistency comprises the pump starting after the first time, but the number of times the pump has started remaining constant.

18. The method of claim 11, wherein the inconsistency comprises a primary pump event occurring before the first time, but the number of times the pump has started increasing by one.

19. The method of claim 11, wherein the inconsistency comprises the drive run status being off at the first time, the drive run status being on at the second time, and a secondary event timestamp sitting in between the first time and the second time, but the number of times the pump has started increasing by one.

20. A computing system, comprising:

one or more processors; and

a memory system comprising one or more non-transitory computer-readable media storing instructions that, when executed by at least one of the one or more processors, cause the computing system to perform operations, the operations comprising:

receiving a first data packet including a plurality of parameters relating to operation of the pump at a first time;

receiving a second data packet including a plurality of parameters relating to operation of the pump at a second time that is after the first time;

filtering the first and second data packets; determining whether the first and second data packets include a sufficient set of parameters to perform a first determination of the downtime of the pump, wherein the sufficient set of parameters to perform the first determination comprises:

an electrical current supplied to the pump;

a frequency of the pump;

a number of times that the pump has started;

an amount of time since the pump last started; and

an amount of time since the pump last stopped;

in response to determining that the first and second data packets include the sufficient set of parameters to perform the first determination, comparing the parameters in the first and second data packets to determine whether the pump was turned on, off, or both between the first time and the second time; and

determining the downtime of the pump based at least partially upon the determination whether the pump was turned on, off, or both between the first time and the second time.