Sewer flow monitoring method and system

[0002] This application claims priority under 35 U.S.C. §119(e) to U.S. Provisional Application Serial No. 60/274,839, entitled “Sewer Flow Monitoring Method and System”, filed Mar. 9, 2001, the contents of which are incorporated herein by reference.

[0003] 1. Field of the Invention

[0004] The present invention relates generally to sewage flow monitoring systems. More particularly, the present invention relates to a method and system of monitoring the flow of a fluid substance to detect flow loss based on a predicted flow volume.

[0005] 2. Description of the Related Art

[0006] Fluid flows in pipes and open channels are common in numerous industrial, commercial, municipal, and residential systems. Proper and efficient operation of these systems, and meaningful planning for future expansion and maintenance of such systems, depends upon accurate measurement of the flow thatpasses through such systems. Sewer systems, such as municipal sanitary sewer systems, are an example of one system in which accurate flow measurement is critical.

[0007] Many sewer flow measuring devices operate by detecting both the depth of flow in a channel or pipe and the velocity of the flow in the same location of channel of pipe. The data is collected at periodic sampling times and is used to calculate a flow rate. Examples of such flow measurement devices are disclosed in U.S. Pat. No. 4,397,191, to Forden; U.S. Pat. No. 4,630,474, to Petroff; and U.S. Pat. No. 5,198,989, to Petroff, each of which is incorporated herein by reference in its entirety. In the wastewater industry, real-time detection of problem events and accurate prediction of future system operation have become increasingly important. Real-time detection of system problems, such as leaks or system breaks, sanitary sewer overflows, and system blockages, allows system managers to quickly respond to such problems. With a rapid response, system managers can prevent or minimize unwanted incidents such as basement back-ups or sewage in waterways that may result from system overflows or breaks. For example, with early detection of a system blockage, managers could respond to and clear the blockage or repair the pipe before it causes an overflow or a buildup of pressure within the system resulting in a break or leak. Further, if an overflow occurs, such as may happen during a storm event, system managers can take action to redirect the flow to other channels within the system in order to reduce or eliminate the overflow condition.

[0008] Further, a system with predictive capabilities could allow managers to stop overflows before they occur, to more effectively use existing system features, and identify and plan for required system expansions.

[0009] Conventional monitoring systems have exhibited several problems. The conventional systems are limited to reporting of data and basic alarming. Such systems do not reliably validate, in real time, monitored data. Further, alarm conditions are typically triggered based on predetermined levels, and the monitoring systems are susceptible to false alarms during storm conditions, holidays, and other unusual events that are not necessarily reflective of a sewer system problem. Further, the conventional monitoring systems lack reliable predictive capabilities for predicting flow at various points in a sewer system.

[0010] Accordingly, it is desirable to provide an improved method and system for monitoring flow in a sewer system.

[0011] It is therefore a feature and advantage of the present invention to provide an improved flow monitoring method and system.

[0012] In accordance with one embodiment of the present invention, a method of monitoring and analyzing flow in a sewer system includes the steps of using a monitoring assembly to collect data representative of actual flow volume of a fluid substance in a first location such as a sewer pipe, storing the actual flow volume data in a memory, maintaining previously stored data in the memory, determining a predicted flow volume and comparing the actual flow volume wit the predicted flow volume to yield a difference value. The predicted flow volume is dependent on the data selected from the previously stored data and a day and time that corresponds to both the actual flow volume data and the data selected from the previously stored data. Optionally, the predicted flow volume may also be dependent upon additional data corresponding to a rain event.

[0013] In situations where the difference value exceeds a predetermined variance value, the method may further include the step of issuing a flow loss notification. If the difference value does not exceed a predetermined variance value, the method may also include storing the actual flow volume in the memory as stored calibration data. As additional options, the method may include the additional step of transmitting the flow velocity data, depth data, and/or the actual flow volume over a data network such as the Internet to a computing device. Also optionally, the actual flow volume may be a rolling average flow volume.

[0014] As additional options, at least one of the determining step and the comparing step may be performed by the monitoring assembly. In the alternative, the determining step and/or the comparing step may be performed by the computing device. As a further option, the method may include the additional step of validating the data representative of flow velocity and depth. In such a case, the validating step may optionally be performed by the monitoring assembly. In addition, the data representative of actual flow volume may include at least one of flow velocity data and depth data, and the method may include calculating the flow volume based upon such data.

[0015] In accordance with an additional embodiment of the present invention, a flow monitoring system includes a first monitoring assembly having at least one sensor. The sensor operates to collect data representative of actual flow volume at a first location. The system also includes a processor and a memory. The memory operates to store the data representative of flow volume as well as a detection time associated with the data. The system also includes a central computing device in communications with the first monitoring assembly. The processor is trained to compare the actual flow volume with a predicted flow volume to yield a difference value. The predicted flow volume is dependent on the data stored in the memory and the detection time associated with such data.

[0016] Optionally, the processor is further trained to issue a notification if the difference value exceeds a predetermined variance value. Also, the data representative of actual flow volume may include depth data and/or velocity data, and the processor would be further trained to calculate the actual flow volume corresponding to such data.

[0017] As an additional option, the processor may be integral with the first monitoring assembly. As an alternative option, the processor may be integral with the central computing device.

[0018] Also in accordance with this embodiment, a first monitoring assembly may optionally be capable of validating the flow velocity in depth. As an additional option, the system may include a second monitoring assembly that has a means for detecting the quantity of rain at a location during a period of time, such as a rain gauge, a weather service, or even a weather web site. Further, the central computing device may be trained to predict an anticipated flow velocity, depth, and/or flow volume of the fluid substance at a second location.

[0019] FIG. 1 is a flow chart illustrating the steps that maybe followed in an embodiment of the present invention as a method.

[0020] FIG. 2 illustrates an example of the operation of the flow loss detection feature of the present invention.

[0021] FIG. 3 further illustrates the flow loss detection feature.

[0022] FIG. 4 further illustrates the flow loss detection feature.

[0023] FIG. 5 illustrates examples of certain hardware aspects of the present system. FIG. 5A is a block diagram illustrating further details of the system shown in FIG. 5.

[0024] FIG. 6 is an exemplary scatterplot hydrograph in a normal pipe.

[0025] FIG. 7 is an exemplary scatterplot hydrograph in a blocked system.

[0026] FIG. 9 is an exemplary scatterplot hydrograph in a system experiencing sanitary sewer overflow.

[0027] FIG. 9 is a block diagram that illustrates data validation features of the present invention.

[0028] FIG. 10 is a block diagram that illustrates alarm event detection features of the present invention.

[0029] The present invention provides a novel sewer flow monitoring method and system. A flow chart 100 of the present invention in a method embodiment, and the potential steps to be implemented by a system embodiment, are illustrated in FIG. 1. Referring to FIG. 1, the method includes the step of using a monitoring assembly to collect 12 data representative of flow velocity in depth of the fluid substance in a first sewer location. This data may be collected by velocity and depth sensors that are integral with the monitoring assembly, such as those described in col. 2 of U.S. Pat. No. 4,397,191, to Forden (including the drawings referenced therein), and col. 2 of U.S. Pat. No. 5,821,427, to Byrd (including the drawings referenced therein), each of which is incorporated herein by reference.

[0030] The method also includes determining a flow volume 16 corresponding to the flow velocity and depth detected. The flow volume may be determined by any appropriate method, such as simply by multiplying the flow velocity and the depth to result in a volume, or by using methods that consider additional variables such as temperature as described for example in U.S. Pat. No. 5,198,989, to Petroff, which is incorporated herein by reference in its entirety.

[0031] The steps of detecting a flow velocity and depth and determining a flow volume are preferably performed in the monitoring assembly itself. In such an embodiment, the monitoring assembly would include a processor and a memory, and the processor would be trained, such as through computer program instructions or digital logic, to perform the calculation of flow velocity. Optionally, the flow velocity and depth data may be transferred to a remote or central computing device over a communications network such as the Internet, and the determination of flow velocity may be performed by the remote or central computing device. The processes of detecting flow velocity and depth and calculating flow volume are periodically repeated, such as may occur during one-minute intervals, fifteen-minute intervals, or any regular or irregular interval that is desired. The flow velocity data, depth data, and flow volume data are stored in a memory 18. In the embodiment where the flow volume is determined at the monitor level, the memory 18 is preferably integral with the monitor. In the embodiment where the flow volume is determined at the computer, the memory 18 is preferably integral with the computer. The memory 18 maintains stored data 20 over a period of time, although optionally data may be discarded after it achieves a predetermined age, such as a week, a month, a year, or (such as many be desirable for data relating to unique days such as holidays) several years.

[0032] As an additional option, in step 12 only one of flow velocity and depth data may be obtained. For example, flow volume could be calculated as a function of either depth or velocity, without need for collecting the other data item. Further, in an optional embodiment, step 12 may be completely eliminated and the system may directly collect flow volume data, such as when data from a pump station or other area is available.

[0033] Optionally, the method may include validating 14 the flow volume and/or depth data before determining the flow volume, or it may include validating 14 the flow volume data after it is determined or calculated. In a preferred embodiment, using depth data for purposes of discussion, the validation is performed by comparing the detected depth with previously-collected depth data stored in the memory. The validation step considers the time that the data is collected, and preferably the day that the data is collected, and compares it to data previously collected for similar days and times. For example, the system may collect depth data at 8:00 a.m. on a weekday, and the validation step will include comparing that data to depth data collected at or near 8:00 a.m. on previous weekdays. Similarly, weekend days may correspond, and the system may also optionally be programmed to recognize, holidays (which typically have unique flow trends) and/or individual days within the week, such as Mondays, Tuesdays, etc.

[0034] The comparison may be done to the most recent relevant previously-collected data, or it may be to a set of previous data. Preferably, the previously-collected data is limited to that collected recently, such as during the past ten related days and times, so that trends are followed and gradual changes do not result in false determinations of invalidity. Optionally, the previously-collected data may be averaged, or a mean may be calculated for comparison purposes. Optionally, the average may be a weighted average, such that the most recent data is given the most weight, while older data is given less weight. If the current depth data differs from the previous data by more than a predetermined variance level, then the system assumes that the data is invalid, and the monitor is re-fired to collect another set of data The predetermined variance level may be any amount, such as a percentage or a set number, and is preferably set to be large enough to avoid false invalidity determinations and small enough to capture most invalid readings. After re-firing, the system may perform the validation step again. Optionally, if a predetermined number of re-firings yield similar results, the system will presume that the data is valid.

[0035] Preferably, the validation step is performed at the monitor level, but optionally and alternatively the validation may be performed by the remote or central computer.

[0036] Returning to FIG. 1, the system includes the feature of detecting flow loss by comparing the actual, detected flow volume with a predicted flow volume. First, the system determines a predicted flow volume 22 based on the data representative of flow velocity and depth in that is previously stored in the memory. As with the validation feature described above, the predicted flow volume is determined based on the day and time of the current reading and comparing 24 it with readings taken at previous, related days and times. If the current reading falls below a predetermined threshold 26, such as 75% of the expected reading, an alarm may be issued 28.

[0037] An illustration 200 of such a comparison is shown in FIG. 2, where the calculated velocity 205 is identified as Q_Cand the predetermined threshold 210, such as 75% of the predicted flow loss, is identified as Q_MINQ_Cand Q_MINtypically vary over different days and times, as sewage flow on weekdays typically differs from that on weekends, and flows during different times of day also vary. For example, flows at 3:00 am. on a weekday are typically much lower than flows at 8:00 am. on a weekday. Trends associated with holidays or individual days may also be considered. As illustrated in FIG. 2, if the flow 205 drops below the predetermined threshold 210, an alarm is triggered 215. The alarm, as well as any or all of the data, may be transmitted to a remote or central computer over a communications network, as illustrated by step 30 in FIG. 1.

[0038] FIG. 3 illustrates that the method may include compensation for wet weather. For example, FIG. 3 illustrates that when the system detects a gradual increase in flow volume or a gradual decrease in flow volume, the system may presume that the increase or decrease results from a storm event. In such a situation, a quick loss is identified 305 as an actual flow loss, while a gradual decrease is identified as an end of a storm event. Optionally, the system may use actual data collected from one or more rain gauges, or even data obtained from a weather service or weather web site, to determine when a storm event is occurring.

[0039] FIG. 4 illustrates that the predetermined threshold 210 is preferably set at a level that is not too close to the actual readings in order to avoid false alarms. For example, starts and stops of pump stations in a sewer system can cause spikes and/or erratic flows 405. Thus to avoid a change and pump status causing a false alarm, the predetermined threshold 210 may be anywhere from 5% to 50% below the predicted value, or more or less as may be appropriate for the system. In addition, to avoid “spikes” 405, the actual flow volume 205 may be calculated on a “moving boxcar” or rolling average basis, such as by using the average of the previous two, ten, or any predetermined number of readings.

[0040] FIG. 5 illustrates an example of several elements of the system embodiment 500 of the present invention. Referring to FIG. 5, a network of flow monitors 505 detects depth and velocity at various locations in a sewer system. Referring also to FIG. 5A, the flow monitors 505 each include a sensor 530 to perform the detections and a processor 535. The monitors 505 communicate with a central or remote server 510 over a data network such as a local area network, wide area network, or the Internet. The server 510 includes a processor 520 and a memory 525. Optionally, the central server 510 may also communicate with one or more user workstations 515 over a data network such as a local area network, wide area network, or the Internet. The system 500 may also be used to monitor or predict potential problems with a sewer system.

[0041] During the last century, several hydraulic engineers developed equations, known as pipe curve equations or hydraulic element curves, to describe the relationship between the depth of open channel gravity flow to the velocity of that flow. For a given depth of flow there is a unique and predictable velocity (and flow rate). FIG. 6 shows an exemplary scattergraph 600 from a normal open channel flow sewer. The plot of paired depth and velocity readings from an open channel flow meter should form a pattern similar to this pipe curve 600. Patterns that deviate from the expected pipe curve 600 indicate that either the hydraulics of the pipe are changing or the meter is malfunctioning.

[0042] It is a rare sewer system that produces an ideal scattergraph 600. Bottlenecks can be caused by undersized pipes, broken pipes, Toots and severe turns in manholes. FIG. 7 illustrates the classic “ski jump” shape 700 which is the distinguishing characteristic of a sewer with a downstream bottleneck The hydraulic grade line 700 in this example will become flat during the surcharge period and the backwater condition can be detected several manholes upstream of the bottleneck.

[0043] Sanitary sewer overflows (SSOs) are also a problem in many sewer systems. They are difficult to witness or document because they usually occur during rain events when people are indoors. Also, they frequently are located out of sight at the lowest manholes or structures along creeks and ravines. Toilet paper in the branches along the creek may be the only evidence that some SSOs leave behind. The first reaction to SS0's from casual observers and some collection system managers may be that they “need a bigger pipe.” However, in whole or in part, many SSOs are caused by a downstream bottleneck. Thus, in such cases, bigger pipes may not be needed, and simple elimination of the bottleneck may solve the problem. SSOs and bottlenecks each will leave telltale evidence in the data of nearby flow meters. FIG. 8 is an exemplary scattergraph 800 produced by flow monitor data collected during an upstream SSO event.

[0044] Referring to FIG. 9, a block diagram 900 illustrates how the present inventive method 100 and system 500 can use scatterplots to validate data and identify bottlenecks and SSOs. An optional “scatterplot feature” 905 compares valid depth and velocity data points to an expected hydraulic signature curve. If these data points do not fall within the expected hydraulic signature curve limits, the sensors are re-fired to collect new data at block 910 to test the validity of the data and verify whether a sensor may have malfunctioned. If depth and velocity data points are repeatable, it is assumed that the data is valid and it is stored. If they are not repeatable, they are flagged as “bad” data. If the verified data points fall outside of expected curve limits, the alarm notification module 915 initiates an event call out. An optional “hydrograph function” 920 compares valid depth data with previously-collected data, such as a “learned 24 hour” diurnal curve. The result of that comparison typically indicates a quantity above or below the expected diurnal curve at a specific time of day. Any quantity plots above or below the expected diurnal curve may result in an alarm event at block 915.

[0045] FIG. 10 is a block diagram 1000 that illustrates exemplary embodiments of features of event management in the present inventive method 100 and system 500. Upon receiving an event notification 1003 from a flow monitor 505, the system 500 may plot the event depth and velocity points against an expected hydraulic signature curve at block 1005. The expected hydraulic signature curve is generated using a 24 hour data collection, followed by analysis and normalization of the data at block 1008. If the event depth and velocity points fall inside a normal plot standard deviation, the system 500 considers the point to be valid. The system 500 may also plot the event depth points against an average weekday or weekend or holiday hydrograph at block 1010. Data is then saved in an event management store at block 1015. If an event depth point falls above or below the predetermined average daily hydrograph limits, the system 500 considers the event depth point to be invalid and may trigger an alarm and/or recollect the data at 1020. When triggered, an alarm is generated by an alarm device that is typically integral with a processor for example either the server processor 520 or a monitor processor 535. Optionally, if a predetermined number of alarms occurs in a set period (such as three alarms in an eight-hour shift), a high priority alarm may be triggered at 1020 in order to prompt a user of system manager to investigate the problem.

[0046] The system 500 includes several functions that a user may optionally see on a user display. For example, a log-on/log-offbutton may be provided to allow the user to log on and off the system. A system overview button may allow the user to select a graphic view of the system that provides an overview of a geographic area, such as a county or river basin. The user may be provided with a select topic button that allow the user to select an area, such as a county or basin, or an individual site. Alarm summaries and communications summaries may also be made available to the user. Optionally, a weather button may allow the user to view weather data, such as that collected by rain gauges or even as obtained from a weather service or weather web site. A site detail screen may allow the user to see real-time monitor data as well as scatterplots and time-lapse data. Such data may include, for example, flow volume, velocity, and depth, temperature, pH, or even content such as dissolved oxygen. Further examples of such screens and plots are described in the materials appended hereto, and made a part hereof, as Appendix A.

[0047] It is to be understood that the invention is not limited in its application to the details of construction and to the arrangements of the components set forth herein the following or illustrated in the drawings. The invention is capable of other embodiments and of being practiced and carried out in various ways. Also, it is to be understood that the phraseology and terminology employed herein, as well as the abstract included below, are for the purpose of description and should not be regarded as limiting.