Method and System for Anomaly Detection for a Pumped Pipeline

Abstract

A method and system for detecting an anomaly in a pumped pipeline is disclosed. A data stream is received over time on operation of the pump and pump start and pump stop event data is obtained from the data stream. For each pair in time of a pump start event and preceding pump stop event in the data stream flow is calculated and compared to expected flow. Variation between calculated flow and expected flow is recorded as an exception and an alarm is triggered in dependence on the exception.

Claims

1. A method of detecting an anomaly in a pumped pipeline, the pipeline having a fluid to be pumped from a sump by a pumping system having a predetermined high and low level setpoint, the pumping system having a pump configured to start pumping when fluid in the sump is at the high level and stop pumping when the fluid is at the low level, the method comprising: receiving a data stream over time on operation of the pump; obtaining pump start and pump stop event data from the data stream; for each pair in time of a pump start event and preceding pump stop event in the data stream: determining from the pump start and pump stop event data a duration of time that the pump is off, D.sub.off; determining from the start and stop event data a duration of time that the pump is on, D.sub.on; calculating flow from D.sub.off and D.sub.on; storing the calculated flow in a data repository; comparing the calculated flow to an expected flow; recording in the data repository an exception upon the variation between calculated flow and expected flow exceeding a predetermined threshold; and triggering an alarm in dependence on the exception.

2. The method of claim 1, further comprising triggering an alarm upon a predetermined number of exceptions being recorded within a predetermined time period.

3. The method of claim 1, further comprising triggering an alarm upon a predetermined number of exceptions being recorded with a similar variation.

4. The method of claim 1, further comprising receiving a plurality of data streams, each from a different pump, method further comprising joining the data streams together and obtaining a time ordered sequence of start and stop event data from the joined data streams.

5. The method of claim 1, wherein the expected duration of time that pump is on and off is predetermined.

6. The method of claim 1, wherein the expected duration of time that pump is on and off is obtained from a machine learning system.

7. The method of claim 1, wherein the expected duration of time that pump is on and off is learnt from data stream over time.

8. The method of claim 1, further comprising plotting each pair on a scatter plot, the steps of comparing comprising identifying a point on the scatter plot outside normal operating range.

9. The method of claim 1, further comprising registering a pipeline burst exception upon the calculated flow being exceeding expected flow by greater than or equal to a predetermined amount.

10. The method of claim 1, further comprising receiving an anomaly decision from a pressure monitoring system monitoring the pipeline and generating an alarm upon the anomaly decision agreeing with the exception.

11. An anomaly detection system for a pumped pipeline, the pipeline having a fluid to be pumped from a sump by a pumping system having a predetermined high and low level setpoint, the pumping system having a pump configured to start pumping when fluid in the sump is at the high level and stop pumping when the fluid is at the low level, the anomaly detection system comprising: a pipeline flow data repository; an input interface configured to receive a data stream over time on operation of the pump; a processor configured to execute computer program code for detecting anomalies from the data stream, the computer program code including: computer program code configured to obtain pump start and pump stop event data from the data stream; computer program code configured, for each pair in time of a pump start event and preceding pump stop event in the data stream, to: determine from the pump start and pump stop event data a duration of time that the pump is off, D.sub.off; determine from the start and stop event data a duration of time that the pump is on, D.sub.on; calculate flow from D.sub.off and D.sub.on; store the calculated flow in the data repository; compare the calculated flow to an expected flow; record in the data repository an exception upon the variation between calculated flow and expected flow exceeding a predetermined threshold; and an output interface configured to trigger an alarm in dependence on the exception.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Embodiments of the present invention will now be described, by way of example only and with reference to the accompanying drawings in which:

[0047] FIG. 1 is a schematic diagram of a rising main pipeline for which embodiments of the present invention may be used.

[0048] FIG. 2 is a plot showing a pump system curve and flow within a pipeline;

[0049] FIG. 3 is a flow diagram of a method according to an embodiment;

[0050] FIG. 3A is a schematic diagram of an anomaly detection system for a pumped pipeline;

[0051] FIG. 4 is a plot showing pump operation; and,

[0052] FIG. 5 is a plot showing pump run and off duration.

DETAILED DESCRIPTION

[0053] FIG. 1 is a schematic diagram of a rising main pipeline for which embodiments of the present invention may be used.

[0054] Such pipelines include an inflow from a collection system (not shown in the drawings), a sump, well or similar fluid holding vessel (which may be enclosed or open), a pumping system having a pump that may be submersible or dry and arranged to pump from the sump into the pipes of the pipeline.

[0055] Typical pumping systems include a pump control system with a sump level sensor that has a predetermined high and low level setpoint, the pumping system is configured to start the pump when fluid in the sump is at the high level and stop the pump when the fluid is at the low level. Often, there is more than one pump in the pumping system and these may be operated sequentially or in parallel. Where there is more than one pump, all of them operate on the same sump and with reference to the same high and low level setpoints of the sump.

[0056] While other features may be implementation dependent, a pipeline may also optionally include a non-return valve on each pump, a manifold joining together the output from each pump, air valves in the pipeline and a delivery point at the outfall, the destination end of the pipeline, (typically the treatment works or another sump).

[0057] Existing pump control systems are typically configured to: [0058] Turn one or more pumps on at the sump “high” level (a pump start event in the SCADA data) [0059] Turn the pumps off at the sump low level (a pump stop event in the SCADA data) [0060] Run a different pump each time to level the pump wear [0061] On some occasions, upon higher inflow to the sump for example, turn on more than one pump

[0062] Assuming the collection sump has a cross-sectional area A. The pump is turned on at the sump high-level setting and is turned off at the sump low-level setting. The fluid height difference between the high and low settings is h and hence the volume pumped out is hA.

[0063] Embodiments of the present invention utilise the knowledge that the volume in the sump between the high (start) and low (stop) levels is fixed with a drop in sump level of h between high and low level. hA can be expressed as a percentage (i.e. start pumping at 60% full, stop at 40% full), in which case the calculated flow will be expressed as % per second. If on the other hand, hA is known or can be calculated, for example in litres, then resulting flow (Q.sub.p) will be in litres/sec.

[0064] From this knowledge, and pump event data stream that includes (or from which can be derived) the pump start (t.sub.on) and pump stop times (t.sub.off), the duration of time a pump runs for and also that the pumping system is off (irrespective of number of pumps) following can be determined: [0065] D.sub.off=time duration pumps are off=time to fill the sump=indication of inflow (Q.sub.i)

[00001]$Q_i=\frac{\mathrm{hA}}{D_{\mathrm{off}}}$ [0066] D.sub.on=time duration pumps are on=time to pump the sump down=indication pump flow rate Q.sub.p+ continuing inflow Q.sub.i

[00002]$Q_p-Q_i=\frac{\mathrm{hA}}{D_{\mathrm{on}}}$

[0067] These can be combined by substituting Q.sub.i and as a result, data on inflow to the sump is not needed:

[00003]$Q_p=\frac{\mathrm{hA}}{D_{\mathrm{off}}}+\frac{\mathrm{hA}}{D_{\mathrm{on}}}=\mathrm{hA}\left(\frac{1}{D_{\mathrm{off}}}+\frac{1}{D_{\mathrm{off}}}\right)$

[0068] Q.sub.p is the flow rate of the pump:

[00004]$\begin{array}{cc}{Q}_p=\mathrm{hA}\left[\frac{1}{D_{\mathrm{on}}}+\frac{1}{D_{\mathrm{off}}}\right]& \left(1\right)\end{array}$

[0069] The run-time durations are therefore at a minimum when the inflow is very low. By monitoring the run-time and learning the normal minimum run-time durations for any given sump-pump-main system, abnormal behaviour can be detected. For example, run-times below the expected (learnt) minimum can indicate a burst rising main. Abnormally long run-times can indicate a blockage or failing pump.

[0070] As discussed above, hA, is a physical parameter of a particular sump construction and hence is a constant value. Q.sub.p is a characteristic of the pump and is therefore also a constant value.

[0071] If the pipeline has a burst, the pump run-time, D.sub.on, will be shorter and hence an increase in the

[00005]$\frac{1}{D_{\mathrm{on}}}+\frac{1}{D_{\mathrm{off}}}$

term in equation (1) above.

[0072] The reason a burst causes a reduction in run-time duration and increase in pump flow rate can be understood from the system curve, FIG. 2. When a pipeline bursts, it becomes less restrictive, and the equilibrium point between the pump and the pipeline moves to a new higher flow and lower pressure point as shown by the green dot on the system curve.

[0073] The pump only has to lift the fluid to the burst location rather than all the way to the outfall. The position of the dot in FIG. 2 changes with the location of the burst site along the main.

[0074] FIG. 3 is a flow diagram of an anomaly detection method according to an embodiment.

[0075] In step 100, pump start and pump stop event data is extracted from a received data stream.

[0076] In step 110 the method iterates through the pump start and stop time data set and for each pump start event and preceding (in time) pump stop event, computes the Off-Duration (D.sub.off) set (difference between an Off event time and subsequent On event time) and the Run-Duration (D.sub.on) set (difference between an On event time and subsequent Off event time).

[0077] In step 120, flow (actual or relative) is calculated and stored, in step 130, in a data repository.

[0078] If the flow varies more than a predetermined threshold compared to expected flow for the pipeline (which as discussed above may be learnt, calculated from a model or predicted by a machine learning system), an exception is raised and preferably stored in the data repository against the flow data in step 140.

[0079] In step 150, an alarm is raised in dependence on exceptions (for example, if there are a sufficient number within a predetermined time period and/or a similar number of exceptions with similar variation of a sequence of exceptions identified matching a particular fault pattern (such as a leak increasing in magnitude).

[0080] Alarms may, for example, be in the form of emails or other communications, an API push to operations team or other alarm mechanisms. An example alarm may be, for example when outflow lower than −0.225% per sec (indicative of a burst).

[0081] FIG. 3A is a schematic diagram of an anomaly detection system for a pumped pipeline, the pipeline having a fluid to be pumped from a sump by a pumping system having a predetermined high and low level setpoint, the pumping system having a pump configured to start pumping when fluid in the sump is at the high level and stop pumping when the fluid is at the low level. The anomaly detection system 10 comprises:

[0082] a pipeline flow data repository 20;

[0083] an input interface 30 configured to receive a data stream over time on operation of the pump;

[0084] a processor 40 configured to execute computer program code for detecting anomalies from the data stream, the computer program code including:

[0085] computer program code configured to obtain pump start and pump stop event data from the data stream;

[0086] computer program code configured, for each pair in time of a pump start event and preceding pump stop event in the data stream, to: [0087] determine from the pump start and pump stop event data a duration of time that the pump is off, D.sub.off; [0088] determine from the start and stop event data a duration of time that the pump is on, D.sub.on; [0089] calculate flow from D.sub.off and D.sub.on; [0090] store the calculated flow in the data repository; [0091] compare the calculated flow to an expected flow; [0092] record in the data repository an exception upon the variation between calculated flow and expected flow exceeding a predetermined threshold; and [0093] an output interface 50 configured to trigger an alarm in dependence on the exception.

[0094] FIG. 4 is a plot of pump run status (3 pumps), calculated run durations and off durations.

[0095] Where the pumping system does not export its data, embodiments may include appropriate hardware and infrastructure to retrieve a regular export (for example every 15 minutes) of data such as SCADA data. Preferably, the anomaly detection method is performed by a monitoring system—it may be centrally located or may be dedicated to a particular pipeline (or may be a distributed system with local monitoring systems reporting to a central system).

[0096] Embodiments may also cleanse the pump start and stop data to remove repeated points.

[0097] Typically, each pump in a pumping system has its own stream of start and stop times. In such cases, embodiments joined the data streams together to a single time-ordered series of start and stop times. Note that the preceding stop event may not be from the same pump as the start event in a pair—it is the overall system that is being evaluated not individual pumps. Where multiple pumps run at the same time, these events may be combined and the fact there is combined running taken into account when checking for variation compared to normal timings.

[0098] In selected embodiments, output may be made to a display to visually highlight potential anomalies. In such an embodiment, the Off-Duration set (x-axis variable) may be plotted against the Run-Duration set (y-axis variable) on a scatter plot (FIG. 5). The plot then shows the normal operation range and variance of the sump-pump-main system being monitored.

[0099] The 1/x nature of this relationship, shown in equation (1) is clear from the plot.

[0100] Bursts are indicated by a new cluster of points on the scatter plot appearing with an unusually low run time (FIG. 5), shown as zone 200. From equation (1) it is possible to learn, by monitoring the system for a while, or compute, an alarm threshold for Q.sub.p and this will be positioned within the highlighted zone 200 in FIG. 5. The data does not need to be shown on a plot to identify anomalies—calculated pump flow can also be monitored for variance as discussed above.

[0101] As discussed above, embodiments may be combined with other detection methods and systems such as that described in the applicant's other patent applications. Combining detection based on pump event data such as the SCADA data as described above with pressure (as described in GB2586775 and US 2020/0393326) based burst detection methods enables reduction of false-positives. Each algorithm could operate independently with the final decision on whether to issue a burst alarm being decided by voting logic combining the two alarm signals (or weighting or some heuristic approach) and associated metadata (which might include, as an example, meteorological data that would indicate, for example, inflow increase due to road run off).

[0102] A hybrid system like this: [0103] Is more expensive to implement as a pressure monitoring point is also required [0104] Reduces time for positive identification of burst event [0105] Reduces false positives due to non-burst failures or system configuration changes [0106] Improves the sensitivity of the detector to small bursts [0107] Improves the sensitivity to the detector to bursts near the outfall end of the pipe

[0108] An advanced alarm generation method could also include the pressure data and checking of operating point on system curve (i.e. with a threshold on both needing to be met to trigger an alarm).

[0109] It is to be appreciated that certain embodiments of the invention as discussed above may be incorporated as code (e.g., a software algorithm or program) residing in firmware and/or on computer useable medium having control logic for enabling execution on a computer system having a hardware/computer processor. Such a computer system typically includes memory storage configured to provide output from execution of the code which configures a processor in accordance with the execution. The code can be arranged as firmware or software, and can be organized as a set of modules such as discrete code modules, function calls, procedure calls or objects in an object-oriented programming environment. If implemented using modules, the code can comprise a single module or a plurality of modules that operate in cooperation with one another.

[0110] Optional embodiments of the invention can be understood as including the parts, elements and features referred to or indicated herein, individually or collectively, in any or all combinations of two or more of the parts, elements or features, and wherein specific integers are mentioned herein which have known equivalents in the art to which the invention relates, such known equivalents are deemed to be incorporated herein as if individually set forth.

[0111] Although illustrated embodiments of the present invention have been described, it should be understood that various changes, substitutions, and alterations can be made by one of ordinary skill in the art without departing from the present invention which is defined by the recitations in the claims below and equivalents thereof.