Patent Application
20230315955
The disclosed embodiments generally relate to utility pipe leak detection technology, and more particularly to a system and method for probabilistically determining the occurrence of leaks in utility pipes for determining leak sensor placement using machine learning techniques.
Drinking water is a scarce resource, yet much of it is lost through pipe failures during its journey to consumers. The World Bank estimates that water leaks cost utilities up to $14 billion per year globally. In the U.S. alone, there are more than 240,000 water leaks per year, a loss of nearly one out of seven gallons of treated water. Compounding the problem is an aging pipe infrastructure, with many pipes reaching the end of their useful life within the next thirty years.
Water pipe leaks range from small and steady to large and catastrophic. Furthermore, some leaks surface above ground causing visible water loss and/or ground changes (e.g. sinkholes) whereas other leaks remain underground and can be hidden for extended periods providing no visible leak indication. The visible leaks are easy to find and are often reported directly by the public, whereas the hidden leaks can remain unknown to the water utilities and may be leaking for an extended period of time. These hidden leaks are often referred to by the water industry as “Non-Revenue Water” (NRW), and represent a significant problem because of lost revenue and the negative environmental impact caused by hidden leaks. It is to be appreciated that NRW levels vary from country to country. However, even in countries with advanced infrastructure, NRW levels can reach significant levels. For instance, the United Kingdom's NRW represents 19% of its total water produced, France 26%, and Italy 29%.
It is noted that prior art techniques have been devised for identifying hidden water leaks. These techniques typically place sensors in various locations within the water network infrastructure of a municipality to collect data which is then processed and analyzed to identify possibly leaks. For example, Echologics LLC has developed a proprietary technology that uses acoustic sensors placed in water hydrants to collect audio signals which are analyzed to identify and locate the sound of leaking water. These methods can have acceptable accuracy, however they are expensive and infeasible to deploy across a complete water pipe infrastructure. As a consequence, water utilities selectively pick only a few locations within their network to monitor using these sensor-based technologies.
There is thus a need to determine optimal locations for deploying leak sensors for detecting hidden leaks. Often picking these locations is subjective and based on the opinion of human experts, which is expensive and often non-effective for determining optimal locations for positioning leak sensors.
The purpose and advantages of the below described illustrated embodiments will be set forth in and apparent from the description that follows. Additional advantages of the illustrated embodiments will be realized and attained by the devices, systems and methods particularly pointed out in the written description and claims hereof, as well as from the appended drawings.
In furtherance of the illustrated embodiments discussed herein, it is to be appreciated and understood Artificial Intelligence (AI) may be used to support decision making determinations associated with water pipe leaks by providing processes which calculate the probability of any water pipe failing that occurs in a future time period. Thus, and in accordance with the below described illustrated embodiments, various sensors may be deployed strategically to monitor and examine water pipes that represent a highest Risk within the water infrastructure, where Risk is to be understood to be defined as a function of Likelihood of Failure (LoF) and Consequence of Failure (CoF) associated with the water pipe. This Risk assumption is predicated upon that pipes with high LoF may have already failed causing a leak that hasn't surfaced yet but can be detected by the appropriate equipment, or they will fail soon and thus need to be monitored closely.
To achieve these and other advantages and in accordance with the purpose of the illustrated embodiments, in one aspect, a computer-implemented method and system for determining placement of a sensor component on a utility pipe is described in which at one or more computing devices, data relating to the utility pipe is inputted. The inputted data is then processed to generate one or more variables. The one or more computer devices, via the one or more variables, preferably trains one or more models to produce an output indicative of a likelihood of failure variable associated with the utility pipe from each model. The outputs from all models are preferably combined into an ensemble output indicative of a likelihood of failure associated with the utility pipe. A consequence of failure variable associated with the utility pipe is determined preferably utilizing a plurality of weighted variables. A sensor placement determinative variable is then calculated contingent upon the ensemble output and the consequence of failure variable associated with the utility pipe. Feedback data is then provided indicative of physical placement of one or more sensor components associated with the utility pipe based at least in part on the sensor placement determinative variable.
The accompanying appendices and/or drawings illustrate various non-limiting, example, inventive aspects in accordance with the present disclosure:
The illustrated embodiments are now described more fully with reference to the accompanying drawings wherein like reference numerals identify similar structural/functional features. The illustrated embodiments are not limited in any way to what is illustrated as the illustrated embodiments described below are merely exemplary, which can be embodied in various forms, as appreciated by one skilled in the art. Therefore, it is to be understood that any structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a basis for the claims and as a representation for teaching one skilled in the art to variously employ the discussed embodiments. Furthermore, the terms and phrases used herein are not intended to be limiting but rather to provide an understandable description of the illustrated embodiments.
Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Although any methods and materials similar or equivalent to those described herein can also be used in the practice or testing of the illustrated embodiments, exemplary methods and materials are now described.
It must be noted that as used herein and in the appended claims, the singular forms “a”, “an,” and “the” include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to “a stimulus” includes a plurality of such stimuli and reference to “the signal” includes reference to one or more signals and equivalents thereof known to those skilled in the art, and so forth.
It is to be appreciated the illustrated embodiments discussed below are preferably a software algorithm, program or code residing on computer useable medium having control logic for enabling execution on a machine having a computer processor. The machine typically includes memory storage configured to provide output from execution of the computer algorithm or program.
As used herein, the term “software” is meant to be synonymous with any code or program that can be in a processor of a host computer, regardless of whether the implementation is in hardware, firmware or as a software computer product available on a disc, a memory storage device, or for download from a remote machine. The embodiments described herein include such software to implement the equations, relationships and algorithms described above. One skilled in the art will appreciate further features and advantages of the illustrated embodiments based on the above-described embodiments. Accordingly, the illustrated embodiments are not to be limited by what has been particularly shown and described, except as indicated by the appended claims.
Turning now descriptively to the drawings, in which similar reference characters denote similar elements throughout the several views,
It is to be understood a communication network 100 is a geographically distributed collection of nodes interconnected by communication links and segments for transporting data between end nodes, such as personal computers, workstations, smart phone devices, tablets, televisions, sensors and or other devices such as automobiles, etc. Many types of networks are available, with the types ranging from local area networks (LANs) to wide area networks (WANs). LANs typically connect the nodes over dedicated private communications links located in the same general physical location, such as a building or campus. WANs, on the other hand, typically connect geographically dispersed nodes over long-distance communications links, such as common carrier telephone lines, optical lightpaths, synchronous optical networks (SONET), synchronous digital hierarchy (SDH) links, or Powerline Communications (PLC), and others.
As will be appreciated by one skilled in the art, aspects of the illustrated embodiments may be embodied as a system, method or computer program product. Accordingly, aspects of the illustrated embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the illustrated embodiments may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium (e.g., such as an “app” downloadable from an app store (e.g., iTunes™)) or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, cloud service or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, an or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
Computer program code for carrying out operations for aspects of the illustrated embodiments may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
Aspects of the illustrated embodiments are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the illustrated embodiments. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
With reference now to
Device 200 is intended to represent any type of user computer system capable of carrying out the teachings of various embodiments of the illustrated embodiments. Device 200 is only one example of a suitable system and is not intended to suggest any limitation as to the scope of use or functionality of embodiments of the illustrated embodiments described herein. Regardless, user device 200 is capable of being implemented and/or performing any of the functionality set forth herein.
User device 200 is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with computing device 200 include, but are not limited to, tablet devices and preferably other portable user computing devices (e.g., hand-held or laptop devices) that include any of the above systems or devices, and the like.
User device 200 may be described in the general context of computer system-executable instructions, such as program modules, being executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, and so on that perform particular tasks or implement particular abstract data types. User device 200 may be practiced in distributed data processing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed data processing environment, program modules may be located in both local and remote computer system storage media including memory storage devices.
User device 200 is shown in
Bus 218 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus.
User device 200 typically includes a variety of computer system readable media. Such media may be any available media that is accessible by device 200, and it includes both volatile and non-volatile media, removable and non-removable media.
System memory 228 can include computer system readable media in the form of volatile memory, such as random access memory (RAM) 230 and/or cache memory 232. Computing device 200 may further include other removable/non-removable, volatile/non-volatile computer system storage media. By way of example only, storage system 234 can be provided for reading from and writing to a non-removable, non-volatile magnetic media (not shown and typically called a “hard drive”). As will be further depicted and described below, memory 228 may include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of embodiments of the invention.
Program/utility 240, having a set (at least one) of program modules 215, such as underwriting module, may be stored in memory 228 by way of example, and not limitation, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data or some combination thereof, may include an implementation of a networking environment. Program modules 215 generally carry out the functions and/or methodologies of embodiments of the illustrated embodiments as described herein.
Device 200 may also communicate with one or more external devices 214 such as a keyboard, a pointing device, one or more camera components, a display 224, etc.; one or more devices that enable a user to interact with computing device 200; and/or any devices (e.g., network card, modem, etc.) that enable computing device 200 to communicate with one or more other computing devices. Such communication can occur via Input/Output (I/O) interfaces 222. Still yet, device 200 can communicate with one or more networks such as cellular networks (e.g., TDMA, CDMA, 4g and 5g); a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet) via network adapter 220. As depicted, network adapter 220 communicates with the other components of computing device 200 via bus 218. It should be understood that although not shown, other hardware and/or software components could be used in conjunction with device 200. Examples, include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.
With the exemplary communication network 100 (
In accordance with the illustrated embodiments, the aforementioned machine learning algorithms, in performing one or more functions described herein, may preferably utilize Large Language Models, such as (but not limited to): XLNet; GPT; BERT; and LLaMA. As is known, LLMs are deep learning Neural Network models that recognize, summarize, translate, predict and generate text and other content based on knowledge gained from relevant datasets as described below. A LLM is typically an AI language model consisting of many parameters (typically billions of weights or more), trained on large quantities of text using self-supervised learning or semi-supervised learning. As used herein LLMs are models that perform a wide range of tasks, including, but not limited to reading and analyzing unstructured data from description fields (preferably received from external/third party network coupled databases) such as maintenance records, incident reports, and other relevant documentation relating to utility pipes and transition them into usable data (structured data) for the analytics as described herein, such as determining Likelihood of Failure (LoF) and Consequence of Failure (CoF) variables. In accordance with the illustrated embodiments, the unstructured data may include, but is not limited to, text data, image data, video data and other types of data suitable for use with the illustrated embodiments described herein.
Additionally, LLMs may be utilized to normalize data, particularly in auto-mode (e.g. implementations where an automated process trains and generates machine learning models without the intervention, guidance, or any type of work or involvement by human engineers or scientists), which typically have differing structural data variations (e.g. such as material types associated with utility pipes) whereby LLMs utilize Artificial Intelligence (AI) techniques to determine when variations actually refer to a same/common item, for instance. In accordance with the illustrated embodiments, LLMs are also utilized to create human-readable detailed explanations as to why certain utility pipes have ranked higher on others for monitoring purposes, as mentioned further below. Still further, LLMs are utilized in the illustrated embodiments to provide automated continuous monitoring for providing dynamic risk assessment of utility pipes determined to have a sensor component (such as, but not to be limited to, a pressure sensor, flow sensor, acoustic sensor or a like sensor having utility for the purposes described herein in accordance with the illustrated embodiments, which sensor component may additional be configured and functional as an Internet of Things (IoT) type of sensor) associated therewith, in addition to an alerting system that provides real-time alert notifications to pertinent users, providing real-time data from sensor components, so as to notify, in real-time, changing conditions regarding the sensor components.
It is to be appreciated that the subject invention is applicable to determining leaks in utility pipes, and for ease of description, discussion is provided with regards to a water utility pipe. However, the illustrated embodiments are to be understood to not be limited to water utility pipe application as other fluid and gas carrying utility pipes and systems are to be understood to be encompassed by the illustrated embodiments, such as sewer pipes and gas pipes.
In accordance with the illustrated embodiments, data relating to a utility pipe, such as a water pipe, is accessed and preferably cleansed from a utility company regarding their pipes and breaks. As mentioned above, the aforesaid data cleaning may be accomplished using LLMs. This obtained data typically includes information regarding pipe networks, such as topology of the water pipes, installation year for each pipe, material, diameter, length, etc. In addition, utility companies, or other data sources (such as municipalities) may also provide known pipe break history including dates for certain pipe breaks, location, cause of break (if known), etc. However, it is known that such accessed data often contains errors and omissions attributable to various reasons, such as: errors introduced when legacy paper records were converted to digital format, data entry errors, crews that repair pipe breaks recorded erroneous location of breaks, and the like. To obviate these occurrences, statistical techniques are utilized in the illustrated embodiments to correct such errors, which may be accomplished through the usage of LLMs. For instance, outliers are detected and replaced by statistically valid values, or may be removed from a dataset.
Additionally, publicly available data related to the geographic location of the pipe network is collected, which may include for instance soil data obtained from the USGS databases, weather data obtained from NOAA, population density obtained from the Census Bureau relating to the environment and/or geography associated with a subject water pipe. This public data is then preferably combined with the aforesaid data accessed from a utility company to enrich a dataset regarding a subject water pipe. For instance, accumulated data relating to a subject water pipe record may include the type of soil it is surrounded by, the population size it serves, and the weather conditions present during prior breaks. It is to be appreciated this accumulated data is beneficial during a machine learning phase when a model is trained to identify the conditions under which a water pipe is most likely to leak or break.
It is to be appreciated that the aforesaid obtained data variables are combined to create new data variables utilized to calculate a probability of failure for a water pipe. For example, a created data variable may combine geometric features of a pipe with population density and soil data the water pipe is associated with. These created data variables may also include data transformations enabling the water pipe data to be better suited for particular machine learning algorithms. For instance, a linear regression algorithm works well when independent variables have linear relationships with the dependent variables, whereby if the actual relationship of a variable is exponential, then a new variable may be created using the logarithmic function, such that the resulting relationship can be transformed to linear.
Once the aforesaid data preparation is completed, the resulting dataset is preferably utilized to train several machine learning models representing various algorithms, such as: Logistic Regression; Support Vector Machines; Neural Networks; Bayesian Networks and the like. It is to be understood that each machine learning model preferably produces a different set of outputs. Hence, in order to obtain an optimal result, the different outputs from the models are preferably combined through an Ensemble technique, such as voting or a weight-combination. The output of the Ensemble technique is a Likelihood of Failure (LoF) probability for every pipe in the system of a utility company that data was provided for.
A Consequence of Failure (CoF) variable is then calculated for each such pipe in the pipe network. It is to be appreciated the calculation of CoF variables is contingent upon various factors related to the consequences of failure of a certain pipe, such as cost of pipe repair, cost of pipe replacement, potential environmental damage, size of affected population, important facilities such as hospitals or schools serviced by the pipe, potential traffic disruptions caused by failure of the pipe and the like. A numeric score is assigned to each one of these factors associated with the pipe, and these individual scores are combined with each other, preferably using weighted values, to determine a final CoF metric. The overall Risk metric for a water pipe is calculated as a function of LoF and CoF, such as (but not to be limited to): Risk=LoF*CoF.
Based on the aforesaid calculated Risk metric for each water pipe in a pipe network, optimal locations for placing pipe leak sensors are then calculated. An exemplary algorithm for calculating such locations is contingent on the type and number of leak sensors, as well as being contingent upon any restrictions associated with their use. For instance, if the sensors are acoustic and require attachment to water hydrants, then the location of the hydrants is necessary for the calculations of optimal sensor placements. That is, each hydrant may be assigned a score based on the cumulative Risk of the water pipes that can be monitored through that hydrant, and thus the hydrants with the highest score are preferably given priority for sensor placement. Thus, the potential locations for placing sensors are ranked and sorted by their determined probabilistic effectiveness in catching the most likely and most catastrophic water leaks.
With particular reference now to
It is to further understood that the data inputted at step 310 may further include data provided by, or accessed from, public sources regarding geographic public data associated with subject utility pipes, which for example, may include soil data obtained from the USGS databases, weather data obtained from NOAA, and population density obtained from the Census Bureau. Additional examples of geographic public provided/accessed data in step 310 may include utility pipe records, soil type surrounding utility pipes, size of the population serviced by the utility pipe, and weather conditions during prior utility pipe breaks. Additionally, the data inputted at step 310 may also consist of a combination of geographic public data combined with existing utility pipe data for enriching the aggregated inputted dataset which consequently preferably enhances performance of process 300 in the one or more devices 200.
Next, at step 320, the inputted data (step 310) is processed to generate one or more variables at the one or more computer devices 200. Preferably, this processing includes combining inputted data 310 to create proprietary variables that can be useful in calculating a likelihood of failure (LoF) for each utility pipe. Processing 320 the inputted data 310 may also include generating data transformations for use in training of the one or more models and/or executing the calculation of the LoF variable for each utility pipe. For instance, the LoF variable of a subject utility pipe is preferably generated based upon the combination of geometric features of a utility pipe with geographic population density and soil data obtained from the inputted data of step 310. For instance, in the processing by the one or more devices 200 of step 320, the aforesaid data transformations are generated using one or more of (and is not to be understood to be limited to): linear regression algorithms, statistical error-correcting, statistical data filling techniques, and data augmentation methods such as Synthetic Minority Over-Sampling Techniques (SMOTE) or Generative Adversarial Networks (GANs) for optimizing the inputted data (step 310) for accommodation by individual machine-learning methods. For example, in step 320, a linear regression algorithm may perform well when an independent variable has linear relationships with a dependent variable such that if the actual relationship of a variable is exponential, a new variable is then created using the logarithmic function such that that the resulting relationship is transformed to linear.
Proceeding the step 330 of process 300, the aforementioned training of the one or more models preferably produces an output indicative of a LoF variable associated with the subject utility pipe from each model at the one or more computer devices 200, via the one or more variables. It is to be understood a resulting dataset is produced from the inputted data (step 310) and training process (step 330). During the training process 400 (step 330), as detailed in
Proceeding to step 340 of process 300, the outputs from the models are utilized to preferably produce an ensemble output indicative of a LoF variable associated with a subject utility pipe. With reference to
Proceeding now to step 350 of process 300, a Consequence of Failure (CoF) variable is now calculated that is associated with the subject utility pipe. In accordance with the illustrated embodiments, the CoF variable is calculated preferably utilizing a plurality of weighted variables at the one or more computer devices 200. It is to be understood that calculating the CoF variable (step 350) may also be calculated in regard to each subject utility pipe in a utility pipe network for which data is accessed/provided (step 310). With reference to process 500 of
In accordance with the illustrated embodiments, at step 360 of process 300 a sensor placement determinative variable is determined by the one or more devices 200, preferably via the ensemble output (LoF variable) (step 470) and the determined CoF variable (step 580) each associated with a subject utility pipe. It is to be appreciated the calculated sensor placement determinative variable (step 360) is preferably generated as a function of the LoF variable (step 470) and the CoF variable (step 580), which in one illustrated embodiment may be calculated by the equation:
sensor placement determinative variable=LoF variable*CoF variable
However, it is to be understood and appreciated that the illustrated embodiments may encompass other calculation methodologies for determining a sensor placement determinative variable (step 360).
Next, at step 370 of process 300, the one or more devices 200 are configured to provide feedback output data that is indicative of physical placement of one or more sensor components associated with the subject utility pipe based at least in part on the aforesaid sensor placement determinative variable (step 360). It is to be understood that providing feedback output data (step 370) preferably indicates an optimum location for placing one or more sensor components for detecting leaks/breaks associated with the subject utility pipe. It is to be further understood that providing feedback output data (step 370) may be contingent upon a specific geographic location of the subject utility pipe, and may further depend on the type and number of the one or more sensor components to be associated with the subject utility pipe, which may include restrictions associated with their deployment or usage. For instance, if the one or more sensor components associated with the subject utility pipe are acoustic and are required to be attached to associated water hydrants, then the location of the hydrants may be necessary for the calculation of the optimum sensor physical placements as part of providing feedback output data (step 370) based at least in part on the sensor placement determinative variable (step 360). For example, a certain hydrant may be assigned a score value dependent upon the cumulative weight of the sensor placement determinative variable (step 360) regarding the utility pipes which may be monitored through that specific hydrant, via the feedback output data (step 370). Therefore, the hydrants with the most favorable score may be given priority for the placement of the one or more sensor components. It is thus to be appreciated that by providing this feedback output data (step 370), the ranking of potential locations for the placement of the one or more sensor components is generated, which may preferably be sorted by their effectiveness in detecting likely and catastrophic leaks associated with the subject utility pipe.
With certain illustrated embodiments described above, it is to be appreciated that various non-limiting embodiments described herein may be used separately, combined or selectively combined for specific applications. For instance, the one or more user devices 200 may be configured to enable a policyholder user to record one or more personal property losses associated with the structure. Further, some of the various features of the above non-limiting embodiments may be used without the corresponding use of other described features. For instance, the one or more computer devices 200 (preferably utilizing LLMs) determine and generate human-readable detailed explanations of why certain utility pipes have ranked higher on others for monitoring purposes, as well as providing continuous monitoring (which is preferably automated) for providing dynamic risk assessment of utility pipes determined to have a sensor component (such as an as Internet of Things (IoT) type of sensor component) associated therewith. Additionally, the one or more computer devices 200 (preferably utilizing LLMs) are configured and operative to provide an alerting system that provides real-time alert notifications to pertinent users providing real-time data from sensor components positioned on one or more utility pipes so as to notify, preferably in real-time, changing conditions regarding the sensor components.
Yet further embodiments may include the integration of a chatbot interface providing user functionality such as (but to be understood to not be limited to) enabling users to interact with system 200 of the above described illustrated embodiments to query the status of their utility pipe system (e.g., become aware of potential issues). The integrated chatbot interface preferably simulates human-like conversations with users via a chat dialog box. The chatbot interface preferably utilizes artificial intelligence (AI) systems (e.g., LLMs) that are capable of maintaining a conversation with a user in natural language and simulating the way a human would behave as a conversational partner, which preferably utilizes aspects of deep learning and natural language processing.
Thus, the foregoing description should therefore be considered as merely illustrative of the principles, teachings and exemplary embodiments of this invention, and not in limitation thereof. For instance, the attached Appendix contains further illustrative features of the illustrated embodiments.
It is to be understood that the above-described arrangements are only illustrative of the application of the principles of the illustrated embodiments. Numerous modifications and alternative arrangements may be devised by those skilled in the art without departing from the scope of the illustrated embodiments, and the appended claims are intended to cover such modifications and arrangements.
This application is a Continuation-in-Part Application of U.S. patent application Ser. No. 17/069,537 filed Oct. 13, 2020, which claims priority to U.S. Patent Application Ser. No. 62/913,671 filed Oct. 10, 2019 which is incorporated herein by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 62913671 | Oct 2019 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 17069537 | Oct 2020 | US |
| Child | 18205359 | US |
