FR2957097A1 - Systeme et procede de surveillance de ressources dans un reseau de distribution d'eau - Google Patents

Abstract

Un procédé informatisé pour surveiller un réseau de distribution d'eau, le réseau de distribution d'eau comportant un réseau de canalisations pour délivrer l'eau aux consommateurs et une pluralité de compteurs placés dans les canalisations dans le réseau de distribution d'eau. Le procédé inclut la réception de données de compteur représentant des paramètres mesurés par les compteurs, tels que le débit, la pression, le niveau de chlore, le pH et la turbidité de l'eau distribuée par les canalisations. Le procédé inclut également la réception de données secondaires à partir de sources externes aux compteurs et représentant des conditions affectant la consommation de l'eau dans une région desservie par le réseau de distribution d'eau, tel que la météo et les vacances. Les données du compteur et les données secondaires sont analysées en utilisant des techniques statistiques pour identifier des événements du réseau d'eau comprenant des événements de type fuite et d'autres événements concernant la quantité et la qualité de l'eau traversant les canalisations et le fonctionnement du réseau d'eau. Les événements sont rapportés aux utilisateurs par l'intermédiaire d'une interface utilisateur.

Description

AVIS DE COPYRIGHT Le contenu d'une partie de la divulgation de ce document de brevet est soumis à la protection par copyright. Le détenteur du copyright n'oppose aucune objection à la reproduction fac-similé par toute personne du document de brevet ou de la divulgation de brevet, telle qu'elle apparaît dans les fichiers ou enregistrements de brevets du Patent and Trademark Office, mais se réserve toutefois tous les droits de copyright sans exception aucune. DOMAINE DE L'INVENTION Le domaine de l'invention concerne, de façon générale, la surveillance de systèmes de distribution de ressources, tels qu'un réseau de distribution d'eau, et la détection d'anomalies associées au réseau distribué. ARRIERE-PLAN DE L'INVENTION D'après les Nations Unies, la consommation d'eau a augmenté deux fois plus que la croissance démographique au siècle dernier, et de plus en plus de régions manquent d'eau de façon chronique. D'ici 2025, les deux-tiers de la population mondiale pourraient connaître des pénuries d'eau en raison de l'augmentation de la population. L'eau, particulièrement l'eau potable, est essentielle pour tout développement socio-économique et pour que la population reste en bonne santé. A mesure que les populations croissent dans le monde, elles aspirent à une attribution plus grande d'eau propre à la consommation, ce qui a pour effet une plus grande pénurie d'eau. Un procédé destiné à traiter le problème de la pénurie d'eau et à conserver les ressources réside dans la détection de fuites et d'autres événements survenant dans des réseaux de distribution d'eau. Certains experts estiment que les pertes dues aux fuites et au vol s'élèvent à 25-30% de l'eau transitant par les réseaux de distribution d'eau. Par conséquent, une part importante de l'eau peut être conservée simplement en traitant les problèmes de perte d'eau dans des systèmes déjà contrôlés par l'homme. Des canalisations anciennes, mal construites, une protection insuffisante contre la corrosion, des vannes mal entretenues et des dommages mécaniques font partie des facteurs qui contribuent à la perte d'eau. En plus, les fuites d'eau réduisent la pression d'approvisionnement dans le système, et en conséquence, on doit élever la pression dans le système pour compenser les pertes. L'élévation de la pression du système a comme conséquence le pompage de plus d'eau et une augmentation de la consommation d'énergie du distributeur d'eau. En effet, les réseaux de distribution d'eau sont les plus grands consommateurs individuels d'énergie dans de nombreux pays. En identifiant et en corrigeant les fuites d'eau, ainsi que d'autres problèmes du réseau, les distributeurs peuvent conserver l'eau pour un usage ultérieur et fortement réduire la consommation d'énergie. S'ajoute à cette difficulté le fait que la plupart des réseaux de distribution d'eau sont de grande taille et complexes, et qu'ils ont été construits de façon sporadique, beaucoup de canalisations se trouvant dans des configurations arbitraires pour desservir des besoins géographiques spécifiques se développant au fil du temps.

De plus, la plupart des réseaux de distribution d'eau ne procèdent à aucune mesure en temps réel, fréquente et précise, de la consommation des usagers, ce qui pourrait assurer une conservation simple de la comptabilité de la masse des entrées et sorties. En plus, les réseaux de distribution d'eau sont conçus pour délivrer l'eau à un grand nombre de consommateurs, dont le comportement individuel est imprévisible et sujet à des changements qui dépendent de plusieurs facteurs. De tels facteurs incluent, par exemple, des changements météorologiques et des événements naturels (par exemple, une météo chaude augmente la consommation, idem pour les sécheresses), les vacances et des événements sociaux particuliers (par exemple, amenant les consommateurs à rester chez eux et à augmenter la consommation d'eau dans les réseaux résidentiels et à la faire baisser dans les quartiers d'affaires), et les changements démographiques dans les quartiers au fil du temps. Les procédés existants pour la détection de fuites dans les réseaux de distribution d'eau n'abordent pas ces problèmes de façon adaptée. Par exemple, les dispositifs matériels de détection de fuites disponibles dans le commerce utilisés pour des enquêtes de terrain, tels que les détecteurs acoustiques, peuvent être efficaces pour indiquer une fuite dans un secteur donné de façon exacte, mais leur installation et leur utilisation coûtent cher et ils ne permettent pas une découverte rapide et une couverture globale de tout le réseau. Les systèmes informatiques existants pour la gestion de l'eau, tels que AdviseTM Water Leakage Management proposé par ABB, essayent d'utiliser des données de compteur mais cette utilisation est simpliste et les résultats sont par conséquent d'une utilité limitée. Par exemple, les systèmes n'identifient pas de façon exacte, ou ne rendent pas compte, en temps réel de différents événements spécifiques tels que des fuites ou d'autres événements concernant le réseau, n'identifient pas des défauts de mesure ou des conditions de type qualité médiocre de l'eau, ne proposent pas d'analyses statistiques nécessaires pour comprendre de façon précise le fonctionnement en cours du réseau, et sont handicapés par d'autres insuffisances. En outre, les systèmes actuellement en service sont handicapés par l'incapacité de détecter les vols d'eau ou la déperdition d'énergie. L'une des défaillances principales des approches les plus actuelles est un manque profond de modélisation statistique des nombreux composants non mesurés des réseaux d'eau, en particulier la consommation d'eau par les clients du distributeur, qui est fréquemment modelée par des techniques très rudimentaires, mais qui a pourtant un impact notable sur n'importe quelle analyse du réseau. Les systèmes de télésurveillance et d'acquisition de données ("SCADA") sont de plus en plus disponibles chez les distributeurs dans le monde entier, rassemblant des données à partir de divers compteurs dans le réseau, mesurant des grandeurs telles que le débit et la pression. Cependant, chez la majorité des distributeurs d'eau, ces systèmes sont utilisés par quelques opérateurs qualifiés principalement pour les besoins opérationnels courants ; les distributeurs utilisent peu les données d'historique accumulées dans leurs systèmes pour détecter automatiquement (ou par un autre moyen) des fuites et autres événements anormaux sur le réseau. En outre, toute détection d'anomalie est habituellement limitée à des alertes d'un seul capteur à seuil fixe, menant soit à une faible sensibilité soit à une proportion élevée de fausses alertes. Les opérateurs de réseaux de distribution d'eau continuent d'ajouter encore plus de compteurs pour surveiller l'activité des systèmes de distribution. Bien que cela fournisse de plus grandes quantités de données concernant le réseau, et par conséquent un plus grand potentiel pour la compréhension des événements survenant dans le réseau, la grande majorité des données ne sert souvent qu'à brouiller encore plus les opérateurs du réseau, et complique l'aspect déjà problématique de recherche "d'une aiguille dans une botte de foin" en matière de surveillance du réseau d'eau. D'ailleurs, le placement d'un plus grand nombre de compteurs n'est habituellement pas optimisé pour améliorer l'utilité des données reçues de tout le système dans un souci d'amélioration de la surveillance. En conséquence, les volumes de données plus importants décrivant l'activité d'un réseau sont mal organisés et prêtent souvent à confusion sans permettre aux opérateurs du réseau de prendre de meilleures décisions quant à l'état du réseau de distribution d'eau. De ce fait, on a besoin de systèmes et de procédés améliorés pour mieux analyser les données récupérées d'un réseau de distribution d'eau et les données concernant le réseau et la consommation de ses ressources en vue de faciliter une meilleure gestion de ces ressources. RESUME DE L'INVENTION Une partie ou toutes les insuffisances ci-dessus ainsi que d'autres insuffisances relevées dans l'art antérieur sont résolues par un procédé informatisé de conservation de l'eau en surveillant un réseau de distribution d'eau, le réseau de distribution d'eau comportant une pluralité de canalisations et de dispositifs de réseau tels que des vannes de réduction de pression, des réservoirs, ou des pompes, pour délivrer l'eau aux consommateurs ainsi qu'une pluralité de compteurs positionnés à des emplacements au sein du réseau de distribution d'eau. Les compteurs peuvent être placés à l'intérieur ou à l'extérieur des canalisations, près des dispositifs de réseau, ou à d'autres emplacements arbitraires. Dans certains modes de réalisation, le procédé inclut le fait de recevoir des données de compteur à partir des compteurs, les données représentant une pluralité de paramètres mesurés par les compteurs, les paramètres comprenant au moins le débit d'eau dans les canalisations. Dans certains modes de réalisation, les données de compteur sont des données de type télésurveillance et acquisition de données ("SCADA"). Dans certains modes de réalisation, les données de compteur sont traitées avant d'être analysées, par exemple par filtrage du bruit des données de compteur, et en les formatant pour les stocker dans une base de données d'information du réseau. Selon certains modes de réalisation, les données de compteur sont analysées pour identifier des événements survenant au niveau du réseau d'eau, les événements du réseau d'eau comportant des événements de type fuite et des événements informationnels concernant la consommation de l'eau fournie à travers le réseau d'eau et du fonctionnement du réseau et des compteurs. Les événements informationnels dont on peut rendre compte incluent une augmentation inattendue du profil de consommation, un changement de profil de consommation, un vol d'eau, une infraction au niveau d'une frontière régionale, un défaut de compteur du réseau de distribution et un défaut de fonctionnement d'un dispositif de réseau. Le procédé selon certains modes de réalisation peut en outre inclure la réception, au cours du temps, de données concernant la qualité de l'eau indiquant la turbidité, le niveau de chlore et le pH de l'eau livrée à travers le réseau et identifiant des événements du réseau en détectant des changements au niveau des données concernant la qualité de l'eau au cours du temps dépassant un seuil de valeur statistique, proportionnel, ou constant. Le ou les événements du réseau sont rapportés à l'utilisateur par l'intermédiaire d'une interface utilisateur. Dans certains modes de réalisation, les événements du réseau d'eau sont stockés dans une base de données ; ils peuvent ainsi être accessibles à divers modules d'interfaces qui rendent compte des événements de différentes manières, y compris par des listes d'événements, des graphiques ou données tendancielles, et dossiers d'incidents ou d'autres alertes. Dans certains modes de réalisation, le procédé inclut le fait de recevoir des données secondaires d'une ou de plusieurs sources externes aux compteurs, les données secondaires représentant une ou plusieurs conditions affectant la consommation d'eau dans une région desservie par le réseau de distribution d'eau. Les données secondaires peuvent inclure, par exemple, des données météorologiques représentant des conditions météorologiques dans la région du réseau de distribution d'eau, des données calendaires représentant un ou plusieurs facteurs affectant la consommation d'eau à une date donnée, des données de réparation représentant une ou plusieurs réparations exécutées sur le réseau de distribution d'eau, et des données structurelles représentant une structure du réseau de distribution d'eau. Tel qu'on l'explique en outre ici, ces données secondaires peuvent être analysées avec les données de compteur pour fournir de meilleurs résultats, plus précis et pour réduire ou éliminer les fausses alertes. Par exemple, une augmentation anormale du débit d'eau ou de la consommation dans une région donnée d'un réseau de distribution d'eau peut être expliquée par une chaleur ou une sécheresse au-dessus de la moyenne ou par des vacances ou autre événement naturel ou humain qui amène les gens à rester chez eux au lieu d'aller travailler ou qui change d'autre manière le profil de consommation typique à un emplacement ou à des emplacements particuliers. Dans certains modes de réalisation, des données de compteur sont analysées en prédisant de façon statistique des données de compteur pour un premier compteur sur la base d'autres données de compteur du réseau de distribution d'eau, par exemple en calculant une distribution statistique de valeurs probables pour le premier compteur et en comparant les données de compteur reçues pour le premier compteur aux données de compteur prédites pour le premier compteur. A titre d'illustration, des données d'historique peuvent indiquer que les valeurs du premier compteur sont typiquement d'environ le double des valeurs mesurées en même temps par un deuxième compteur ; dans ce cas, on prédit que la lecture en cours du premier compteur est approximativement du double de la lecture obtenue récemment du deuxième compteur. Les événements du réseau peuvent être identifiés en détectant une anomalie si la valeur de comptage effective reçue du premier compteur s'écarte de la valeur de comptage prédite pour le premier compteur par un écart statistique prédéfini, pendant une durée dépassant un seuil prédéfini, si leur fréquence d'occurrence dans une fenêtre temporelle prédéfinie dépasse un seuil prédéfini, ou par d'autres moyens. La détection statistique d'anomalies au niveau de valeurs de comptage est une façon solide pour surmonter les difficultés inhérentes aux nombreux composants non mesurés des réseaux d'eau, en particulier la consommation d'eau par des clients du distributeur, qui a un impact important sur toute analyse du réseau. La structure statistique de cette consommation, telle qu'une tendance à la périodicité, se propage dans tout le réseau, menant à une structure statistique semblable ou dérivée en termes de valeurs de comptage, permettant une analyse de la probabilité que des valeurs de comptage particulières ont été générées pendant un fonctionnement courant du réseau (aucune anomalie). En outre, l'utilisation de la détection statistique d'anomalies comme décrit ici permet l'utilisation de procédés et de systèmes de la présente invention avec des réseaux qui procurent des données de compteur qui ne couvrent pas chaque partie du réseau, ne sont pas fournies en temps réel, ou sont sinon incomplètes et déficientes. Ainsi, par exemple, la détection d'anomalies décrite ici est conçue pour être très utile dans des réseaux de distribution d'eau dans lesquels les compteurs ne sont présents qu'à certaines jonctions ou à certains emplacements du réseau, ou dans lesquels des lectures des compteurs sont prélevées au niveau des lieux de résidence des consommateurs sur une base mensuelle ou n'arrivent autrement pas à fournir des informations à jour. En effet, comme expliqué ci-dessus, les réseaux de distribution d'eau classiques présentent une ou plusieurs de ces insuffisances en matière de données de compteur collectées à partir du réseau, et manquent de mesures de consommation précises, fréquentes, et en temps réel, auprès des consommateurs, qui pourraient permettre une conservation simple de la comptabilité de masses des entrées et sorties, et sont conçues pour délivrer l'eau à un grand nombre de consommateurs, dont le comportement individuel reste imprévisible et est sujet à des changements dus à maints facteurs. Dans certains modes de réalisation, la prédiction statistique de données de compteur pour le premier compteur sur la base de données d'autres compteurs du réseau de distribution d'eau inclut le fait de choisir un ou plusieurs deuxièmes compteurs en tant qu'un ou plusieurs compteurs correspondants et de corréler des données de compteur reçues du premier compteur avec des données de compteur reçues du ou des compteurs correspondants. Le ou les deuxièmes compteurs peuvent être choisis en corrélant des données d'historique de compteur pour le ou les plusieurs deuxièmes compteurs avec des données d'historique de compteur pour le premier compteur. Dans certains modes de réalisation, le ou les plusieurs deuxièmes compteurs peuvent être des compteurs dont chacun présentait historiquement une forte corrélation avec les valeurs du premier compteur. Généralement, lors d'opérations habituelles du réseau, on s'attend à ce que les valeurs du premier compteur prolongent cette corrélation. A titre d'illustration, une telle situation peut se produire quand plusieurs compteurs mesurent le débit d'eau consommée par plusieurs quartiers distincts avec un profil démographique semblable, et donc des profils de consommation semblables (ou proportionnels). Le ou les plusieurs deuxièmes compteurs peuvent en outre être choisis en tant que compteurs qui sont placés dans le réseau de distribution d'eau afin de ne pas être affectés par des anomalies locales touchant le premier compteur, de celles qui sont d'intérêt pour l'opérateur du réseau, telles qu'une fuite ; néanmoins, faisant partie du même réseau et du même secteur général, les deuxièmes compteurs sont affectés par les mêmes anomalies globales, telles qu'une consommation accrue par une chaude journée. De cette façon, une anomalie locale affectant les données du premier compteur n'affectera pas les données des deuxièmes compteurs et elle sera donc plus facile à détecter par une comparaison statistique par rapport aux données provenant du ou des deuxièmes compteurs, bien qu'une anomalie globale ne produira pas de fausse alerte, même si sa cause est inconnue. Certaines ou toutes les insuffisances ci-dessus ainsi que d'autres insuffisances présentes dans l'art antérieur sont résolues par un système informatisé de surveillance d'un réseau de distribution d'eau, le système ayant une base de données d'informations du réseau pour stocker des données de compteur représentant une pluralité de paramètres mesurés par les compteurs, les paramètres comprenant au moins le débit de l'eau dans les canalisations, et des données secondaires provenant d'une ou de plusieurs sources externes aux compteurs, les données secondaires représentant une ou plusieurs conditions affectant la consommation de l'eau dans une région desservie par le réseau de distribution d'eau. Le système contient en outre un moteur d'analyse configuré pour analyser les données de compteur et les données secondaires en vue d'identifier des anomalies, un moteur de classification d'événements configuré pour identifier des événements du réseau de distribution d'eau sur la base des anomalies, les événements du réseau d'eau comprenant des événements de fuite et d'autres événements concernant la quantité ou qualité de l'eau traversant les canalisations et les dispositifs de réseau et le fonctionnement du réseau de distribution d'eau, et une base de données d'événements pour stocker des données d'événements du réseau de distribution d'eau représentant le ou les plusieurs événements du réseau d'eau identifiés par le moteur de classification d'événements. Le système peut en outre inclure un ensemble de modules d'interfaces pour récupérer des données d'événements du réseau de distribution d'eau à partir de la base de données d'événements et les rapporter aux utilisateurs. Dans certains modes de réalisation, le moteur d'analyse comporte une pluralité de modules prédictifs pour générer une distribution statistique de valeurs probables des données de compteur pour un compteur donné, en supposant un fonctionnement habituel et l'absence d'événements anormaux, et une pluralité de modules détecteurs d'anomalies pour comparer les données de compteur effectives pour le compteur donné à la distribution de valeurs probables pour détecter des anomalies dans les données de compteur. Une partie ou toutes les insuffisances ci-dessus ainsi que d'autres insuffisances de l'art antérieur sont résolues par un procédé informatisé pour gérer un réseau de distribution d'eau, le procédé comportant le fait d'envoyer des données de compteur à un moteur d'analyse, de recevoir du moteur d'analyse des données représentant des événements du réseau de distribution d'eau, et d'afficher les événements reçus du réseau de distribution d'eau à l'attention d'un utilisateur sur un dispositif d'affichage informatisé. Selon certains modes de réalisation, les événements du réseau d'eau incluent des événements de fuite et d'autres événements concernant la quantité ou la qualité de l'eau traversant les canalisations et les dispositifs de réseau et le fonctionnement du réseau de distribution d'eau. Les données concernant les événements du réseau de distribution d'eau peuvent avoir été identifiées par suite de l'analyse des données de compteur et des données secondaires, les données secondaires représentant une ou plusieurs conditions affectant la consommation de l'eau dans une région desservie par le réseau de distribution d'eau. BREVE DESCRIPTION DES DESSINS L'invention est illustrée dans les dessins joints qui sont censés représenter des exemples sans être limitatifs, dans lesquels des références identiques sont prévues pour désigner des parties identiques ou correspondantes, et dans lesquels : les figures 1 et 2 présentent des schémas de principe montrant des systèmes pour surveiller un réseau d'eau selon des modes de réalisation de la présente invention ; la figure 3 présente un organigramme illustrant un procédé pour surveiller un réseau d'eau selon un mode de réalisation de la présente invention la figure 4 présente un organigramme illustrant en outre un procédé pour surveiller un réseau d'eau selon un mode de réalisation de la présente invention ; la figure 5 présente un organigramme illustrant un procédé pour prédire des valeurs mesurées pour un compteur donné selon un mode de réalisation de la présente invention ; les figures 6 et 7 présentent des organigrammes illustrant la sélection d'attributs selon un mode de réalisation de la présente invention ; la figure 8 présente un organigramme illustrant un procédé pour détecter un événement de fuite d'eau ; les figures 9 - 11 présentent des organigrammes illustrant la détection d'événements pour des types d'événements spécifiques selon des modes de réalisation de la présente invention ; et les figures 12 - 15 présentent des captures d'écran montrant une interface utilisateur web présentant des informations d'événements générées par le moteur d'analyse selon un mode de réalisation de la présente invention. DESCRIPTION DETAILLEE DES MODES DE REALISATION Dans la description qui suit, on fait référence aux dessins joints, qui en font partie, et dans lesquels on montre à titre d'illustration des modes de réalisation spécifiques où l'invention peut être pratiquée. On doit comprendre que d'autres modes de réalisation peuvent être utilisés et des changements structurels peuvent être apportés sans s'écarter de la portée de la présente invention. La figure 1 présente un schéma fonctionnel illustrant un mode de réalisation d'un système pour surveiller des ressources dans un système de distribution d'eau. Suivant les indications de la figure 1, le système comporte un moteur 100 d'analyse de réseau d'eau composé de divers modules logiciels et de bases de données résidant sur un matériel informatique et remplissant les fonctions décrites plus en avant. Le moteur 100 peut inclure un ou plusieurs dispositifs de traitement effectuant les opérations décrites ci-dessous en réponse à des instructions exécutables. Le moteur 100 d'analyse du réseau d'eau analyse les données reçues de différents compteurs, capteurs, dispositifs de lecture ou d'autres données concernant un réseau de distribution. L'homme du métier se rendra compte qu'à moins que le contexte spécifique n'indique explicitement autre chose, les termes "compteur" et "capteur", tels qu'on les utilise ici, se rapportent globalement à la même classe de dispositifs de réseau et englobent tout type de compteur, capteur, jauge, ou tout autre dispositif capable de mesurer des paramètres ou des valeurs ou un stimulus, particulièrement un stimulus concernant un réseau de distribution d'eau. Le système identifie des anomalies et des événements sur la base de ces données et fournit des alertes en temps réel ou des comptes rendus de données en différé aux utilisateurs qui peuvent alors prendre une mesure, selon les cas, pour traiter tout phénomène ou événement identifié par le moteur 100 d'analyse. Comme décrit plus en avant, les anomalies et les événements identifiés par le moteur 100 d'analyse incluent des fuites, des éclatements, une consommation inattendue d'eau, des compteurs défectueux, des problèmes de calibrage des compteurs, des changements de qualité de l'eau, d'autres questions importantes en termes de quantité d'eau délivrée à travers le réseau, des défauts de fonctionnement dans des dispositifs de réseau, et d'autres questions que l'homme du métier connaît. Comme le montre la figure 1, les données reçues en tant qu'entrées au moteur 100 d'analyse de réseau d'eau incluent, dans certains modes de réalisation, des données GIS 101, des données opérationnelles 102, des données de système 103 de distribution d'eau, des données 103a d'un compteur 1, des données 103b d'un compteur N et des données externes 104.

Les données GIS 101 sont des données provenant d'un système d'information géographique ("GIS") décrivant la structure et la disposition du réseau d'eau et le positionnement des compteurs à travers ce dernier, et incluent des types de compteurs, les emplacements des compteurs, âges des compteurs, descriptions des canalisations d'eau telles que les diamètres et les matériaux de fabrication, séparations du réseau en zones de pression et/ou zones d'approvisionnement, la carte d'une ville ou d'un secteur, et des données supplémentaires en évolution que l'homme du métier connaît. Toutes les autres caractéristiques de la géographie et de l'ingénierie du système de distribution d'eau peuvent également être utilisées, aussi bien que toutes autres données sur lesquelles peut s'appuyer un homme du métier. On notera également que ces données peuvent être des données évolutives comprenant des mises à jour compatibles avec l'évolution du système de ressource sous-jacent lui-même, par exemple quand de nouvelles canalisations d'eau, de nouveaux raccords, compteurs, etc., sont installés ou modifiés dans le système. En outre, ces données peuvent inclure des mises à jour lorsque le système de ressources sous-jacent est échantillonné ou mesure, par exemple lorsqu'on contrôle, par inspection des canalisations existantes, la fatigue des matériaux ou la constriction interne par accumulation de dépôts solides.

Les données opérationnelles 102 incluent des informations de gestion des biens, et peuvent être toute information en un format numérique concernant des opérations effectuées par l'opérateur du réseau qui peuvent être corrélées avec des lectures de compteurs pour déterminer ou réfuter une anomalie. Par exemple, les données opérationnelles 102 peuvent inclure des informations concernant des opérations sur le réseau d'eau, telles que des opérations routinières ou planifiées sur le réseau d'eau, l'ouverture et la fermeture de vannes qui affectent le débit d'eau, des opérations sur les pompes, des enquêtes acoustiques, des réparations ou des améliorations apportées à toute partie du réseau d'eau, des dates et heures des réparations/améliorations, des emplacements des réparations/améliorations, l'entretien régulier fait au réseau, et des informations de contrôle d'accès indiquant à quel moment et à quel endroit le personnel technique du réseau est susceptible d'être en activité. Dans un mode de réalisation, les données opérationnelles 102 sont fournies par le système utilisé pour gérer le réseau d'eau. Les systèmes surveillés de distribution d'eau produisent de grandes quantités de données à base temporelle comme, mais sans y être limité, des indicateurs hydrauliques tels que le débit, la pression, et le niveau des réservoirs, et des indicateurs de qualité tels que. le taux de chlore, la turbidité, le pH, et autre. Ces données peuvent être produites par des compteurs distribués dans tout le réseau, et peuvent être représentées par le système 103 de distribution d'eau. En outre, les compteurs distribués dans tout le réseau peuvent se trouver à des emplacements arbitraires, ou des emplacements qui ne fournissent qu'une représentation partielle de tout le réseau. Les données 103a du compteur 1 et les données 103b du compteur N représentent des données produites par les divers capteurs et compteurs dans le système 103 de distribution d'eau. Un exemple d'un système employé pour collecter des données du réseau telles que celles représentées par les données 103a de réseau et les données 103b de compteur est un système SCADA. Les données de type SCADA peuvent inclure des données de compteur continues dépendant du temps, telles que la pression de l'eau, le débit de l'eau, la turbidité de l'eau, les niveaux de chlore dans l'eau, le pH de l'eau, et les niveaux d'eau dans les réservoirs. L'homme du métier est familiarisé avec les systèmes de données SCADA et peut s'apercevoir que le terme représente une abstraction de la collecte de données à partir d'un processus industriel, dans ce cas, un réseau de distribution. Les données externes 104 incluent des informations supplémentaires concernant des conditions de consommation d'eau et du réseau, mais pas strictement dans les catégories ci-dessus, telles que les rapports météorologiques, les vacances ou d'autres événements calendaires qui affectent la consommation d'eau et le comportement du réseau dans des parties données du réseau, ou tout autre événement du fait du distributeur lui-même ou de ses clients qui peut avoir un impact sur le fonctionnement du réseau d'eau. Le moteur 100 d'analyse du réseau d'eau analyse les divers flux de données en entrée et renvoie une sortie classée par catégorie et formulée en tant que données d'événements selon des opérations de traitement décrites de manière plus détaillée ci-dessous. Le moteur 100 d'analyse du réseau d'eau stocke des données dans la base de données 106, et les données à partir de la base de données 106 sont récupérées par un ou plusieurs systèmes d'interface, tels qu'une interface de suivi d'événements 108, une interface d'alerte 109, une interface de comptes rendus 110, une interface de système propriétaire 111 ainsi que d'autres interfaces 112. Le moteur 100 d'analyse de l'eau peut également accéder à des données précédemment stockées à partir de la base de données 106, pour fournir la continuité en termes de déclaration des événements, par exemple pour mettre à jour le fait qu'un événement précédemment détecté est encore en cours, plutôt que de le détecter comme événement supplémentaire et distinct. Différents types de systèmes d'interfaçage sont employés pour fournir aux utilisateurs ou à des systèmes externes des informations concernant des événements de différentes manières. Par exemple, l'interface de suivi d'événements 108 permet à des utilisateurs de passer en revue tous les événements détectés sur le réseau, alors que l'interface d'alerte 109 envoie des alertes aux utilisateurs (par exemple par l'intermédiaire d'un email, d'un SMS ou d'un message vocal) ou des systèmes externes que des règles ou politiques ont été déterminées comme exigeant une attention plus immédiate. On peut avoir accès aux interfaces 108-112 par divers dispositifs informatisés, tels que des ordinateurs de bureau et des ordinateurs portables, des téléphones portables, des dispositifs de type blackberry, des téléphones intelligents, des bipeurs et autres périphériques mobiles programmes pour recevoir des radiomessages, des dossiers d'incidents et d'autres types d'alertes. Les dispositifs informatisés peuvent accéder aux interfaces 108-112 les demandant via des serveurs connectés sur tout réseau approprié, comme, mais sans y être limité, Internet, ou les interfaces peuvent être acheminées en direction de tels dispositifs pour le visionnement par des utilisateurs ou rentrées dans d'autres systèmes tels que des systèmes de dossiers d'incident. Les sorties du moteur 100 d'analyse du réseau d'eau peuvent être stockées dans la base de données 106, dans un fichier journal électronique, ou être imprimées sur papier. Bien qu'illustré comme système simple, dans divers modes de réalisation, le système illustré peut être intégré et/ou réparti sur plusieurs dispositifs matériels et peut être distribué logiquement, physiquement ou géographique- ment. Le moteur 106 d'analyse du réseau d'eau peut être tout dispositif de traitement physique approprié effectuant des opérations de traitement comme décrit ici, en réponse à des instructions exécutables. Le moteur 100 d'analyse du réseau d'eau peut également inclure tout type approprié de dispositif de stockage pouvant fonctionner pour stocker électroniquement des données. La figure 2 présente un schéma fonctionnel représentant d'autres détails d'un système de surveillance d'un réseau d'eau selon certains modes de réalisation. Dans un mode de réalisation, des éléments 203-207 forment le moteur 100 d'analyse du réseau d'eau des figures 1. La figure 2 inclut le réseau d'eau 200, le réseau d'eau 201, les données 202, la base de données 203 d'informations du réseau, le moteur 204 de préparation des données, les prédicteurs 205, les détecteurs d'anomalies 206, le moteur 207 de classification et décision concernant les événements, la base de données 208, et les interfaces de sortie 209, y compris l'interface de suivi d'événements 210, l'interface d'alerte 211, l'interface 212 de comptes rendus, l'interface de système propriétaire 213, et d'autres interfaces 214. Les systèmes de distribution d'eau, représentés par les éléments 200 et 201, sont un ou plusieurs systèmes de distribution d'eau raccordés, ou des systèmes de distribution d'eau situés dans différents secteurs avec quelques, ou sans, raccords entre eux. Dans un mode de réalisation, les éléments 200 et 201 peuvent être tout réseau de distribution de ressources approprié, tel qu'un réseau de service municipal, rural, ou de vente d'eau en gros, un réseau de distribution de liquides dans une usine ou tout autre gros bâtiment, ou navire, ou tout autre réseau de collecte de ressources approprié tel qu'un réseau d'égouts. L'homme du métier se rendra compte que les éléments 200 et 201 peuvent être tout système de distribution ou de collecte d'eau. Le réseau d'eau 200 et le réseau d'eau 201 envoient des données qui évoluent avec le temps représentatives du réseau, telles que le débit, la pression, la turbidité, de l'eau, le niveau des réservoirs, le niveau de chlore, et le niveau de pH. Par exemple, le réseau peut obtenir cette information à l'aide d'un système SCADA. Les données provenant du réseau d'eau 200 ou du réseau d'eau 201 peuvent rendre compte des données issues de compteurs spécifiques, ou d'ensembles de compteurs, dont certains peuvent être associés. Par exemple, des compteurs peuvent être groupés géographique- ment par zone ou par Secteur de Distribution, District Metered Area (DMA) en anglais, comme l'appréciera l'homme du métier. Les données peuvent être envoyées directement des compteurs ou des groupes de compteurs dans le réseau, ou les données peuvent provenir d'une base de données 203 d'interface réseau ; en plus les données peuvent être enrichies par le moteur 204 de préparation de données, par exemple, pour ajouter ou calculer de nouveaux types de données, telles que des données de consommation de la matinée et de la soirée. Par souci de commodité, le terme "données de compteur" sera employé dans cette spécifications pour se rapporter aux données effectives d'un seul compteur, ou à une combinaison significative prédéfinie de lectures provenant de plusieurs compteurs ou de lectures multiples provenant d'un ou de plusieurs compteurs, reçues au cours du temps, comme la somme totale du débit d'entrée à un DMA, ou tout autre calcul prédéfini semblable produisant un ensemble significatif de données dépendant du temps décrivant un certain aspect du réseau. L'homme du métier identifiera aisément de telles combinaisons significatives, selon la disposition du réseau et les emplacements des différents compteurs. Les données 202 représentent d'autres données comprenant des informations de gestion des biens, qui peuvent être toute information selon un format numérique que l'on peut corréler avec des lectures de compteurs pour déterminer ou réfuter une anomalie. Par exemple, ceci peut inclure des informations au sujet des opérations du réseau d'eau, telles que des opérations routinières ou planifiées sur le réseau d'eau, l'ouverture et la fermeture de vannes qui affectent le débit d'eau, des enquêtes acoustiques, les réparations ou améliorations apportées à toute partie du réseau d'eau, les dates et les périodes des réparations/améliorations, les emplacements des réparations/améliorations, un entretien régulier apporté au réseau, et des informations de contrôle d'accès indiquant à quel moment et à quel emplacement le personnel technique du réseau est susceptible d'intervenir. En plus, les données 202 incluent des informations supplémentaires concernant les conditions du réseau et de consommation d'eau, telles que des rapports météorologiques, des vacances ou d'autres événements calendaires qui affectent la consommation d'eau et le comportement du réseau dans des parties données du réseau, ou tout autre événement par le système lui-même ou par ses clients pouvant affecter le fonctionnement du réseau d'eau.

La base de données 203 d'informations du réseau agrège les données brutes collectées à partir des compteurs dans les réseaux d'eau 200 et 201, et les données 202. Les données provenant de la base de données 203 d'informations du réseau sont envoyées au moteur 204 de préparation de données. Le moteur 204 de préparation de données organise et formate les données reçues pour un traitement ultérieur. Comme le sait l'homme du métier, les formats de données employés par différents systèmes de distribution d'eau peuvent différer les uns des autres. Par exemple, la ville de Londres peut collecter et stocker des données du réseau selon un format complètement différent de celui de la ville de New York. De plus, le moteur 204 de préparation de données prépare des données pour analyse en enlevant les données ne reflétant pas la performance effective du réseau ou ne reflétant pas un phénomène passager que les concepteurs du système ou les gestionnaires du réseau ont décidé de ne pas traiter ; des procédés généralement connus dans l'art peuvent être appliqués en vue de "lisser" les données collectées à partir du réseau. Certains de ces procédés sont le nettoyage heuristique et lissage LOWESS appliqués aux données spécifiques reçues d'un réseau d'eau donné. Le moteur 204 de préparation de données extrait les éléments de données des données du réseau et les formate en un format cohérent. Parmi les informations filtrées on peut trouver du bruit associé aux transmissions de données à partir d'aspects de la ressource, comme par exemple la transmission de données avec bruit à partir d'un compteur, ou des erreurs liées aux mesures, aux transmissions ou à la collecte de données. Le moteur 204 de préparation de données peut également délivrer en sortie toutes les données reçues des réseaux d'eau 200 et 201, après formatage mais avec moins, ou sans, filtrage ou lissage, pour permettre au système d'analyser les données qui sinon pourraient être rejetées si l'une des techniques de lissage était appliquée d'abord. Le moteur 204 de préparation de données envoie des données prétraitées aux prédicteurs 205 et aux détecteurs 206 d'anomalies. L'homme du métier appréciera que les éléments 203-214 peuvent être contenus dans, ou peuvent résider sur, le même dispositif, ou être répartis sur plusieurs dispositifs.

Dans un mode de réalisation, les prédicteurs 205 contiennent un nombre N de prédicteurs individuels utilisant diverses techniques. Comme décrit encore plus loin, les prédicteurs 205 analysent des ensembles de données et procurent des prédictions de distributions statistiques des valeurs de comptage attendues en supposant l'absence d'événements anormaux. Comme habituellement connu dans l'art, les prédicteurs peuvent être conçus en utilisant un cadre d'apprentissage par machine pour analyser les données de manière statistique. Des exemples de cadres d'apprentissage par machine sont cités dans Ethem Alpaydin, Introduction to Machine Learning (Adaptive

22 Computation and Machine Learning), MIT Press (2004), ISBN 0262012111; Ryszard S. Michalski, Jaime G. Carbonell, Tom M. Mitchell, Machine Learning: An Artificial Intelligence Approach, Tioga Publishing Company (1983), ISBN 0-935382- 05-4 cités ici dans leur totalité à titre de référence. On trouve des descriptions plus détaillées du fonctionnement de certains prédicteurs spécifiques aux figures 5-6 et dans les descriptions qui les accompagnent. Les détecteurs 206 d'anomalies, qui peuvent inclure un nombre M de détecteurs individuels, reçoivent des données de prédiction statistique à partir des prédicteurs 205 et des données prétraitées du moteur 204 de préparation de données. Comme évoqué dans la figure 5, l'ensemble de données reçues des prédicteurs 205 inclut une distribution avec la valeur probable, la variance et tout autre descripteur statistique des valeurs. L'homme du métier notera que l'ensemble de données peut contenir plusieurs valeurs probables et effectives pour le compteur analysé. Les détecteurs 206 d'anomalies incluent des détecteurs d'anomalies pour tester la probabilité d'absence d'anomalies pour le compteur et pour tester la probabilité d'hypothèses alternatives telles que des types spécifiques d'événements. Les détecteurs 206 d'anomalies envoient des anomalies au moteur 207 de décision et de classification des événements. Certaines de ces anomalies représentent des événements dans et d'elles-mêmes, et d'autres représentent des parties d'événements telles que le début d'un événement, la fin d'un événement, le changement majeur au niveau d'un événement, le pic d'un événement, et analogues.

Les détecteurs 206 d'anomalies peuvent fonctionner pour analyser l'importance de tout écart de la valeur prévue envoyée à partir des prédicteurs et de la valeur effective récupérée du réseau. Pour chaque ensemble de données, chaque détecteur d'anomalie détermine, en analysant l'importance des écarts, la probabilité statistique qu'aucune anomalie pertinente ne s'est produite étant donné les lectures de compteur au cours d'une période donnée. Les détecteurs 206 d'anomalies analysent l'importance des écarts au cours du temps, par exemple, au cours de minutes, d'heures, de jours ou plus, puisque, par exemple, l'occurrence continue ou fréquente des écarts augmente l'importance de tels écarts. Comme le reconnaîtra l'homme du métier, un concepteur de systèmes sera amené à concevoir ou ajuster les détecteurs 206 d'anomalies pour analyser des écarts sur une période selon, notamment, la sensibilité souhaitée pour des événements survenant sur de petites échelles temporelles, les événements qui ont récemment débuté, que l'on peut habituellement détecter quand ils ont de grandes ampleurs, par opposition aux événements de faible ampleur qui nécessitent des écarts soutenus sur une période plus importante pour la détection. Ainsi, par exemple, un petit écart qui ne se produit qu'une fois ou pendant un laps de temps court tel qu'une minute ne sera pas détecté comme anomalie, alors que le même petit écart se produisant sur une période prolongée ou fréquemment au cours de cette période serait identifié comme statistiquement significatif par les détecteurs 206 d'anomalies et détecté en tant qu'anomalie. Concernant l'analyse de l'importance des écarts, par exemple, une lecture de compteur, par comparaison aux données statistiques d'historique, peut être significative à la lumière des données statistiques d'historique. Par exemple, une différence de trois écarts type ou une valeur dans le percentile supérieur peut être un écart significatif. Dans d'autres modes de réalisation, l'écart statistique est mesuré par la distribution des écarts en fonction des paramètres. Un tel paramètre peut être l'heure du jour, signifiant que l'importance de l'écart peut dépendre de la distribution des écarts qui peuvent varier selon l'heure du jour. D'autres parmi ces paramètres peuvent inclure des mesures météorologiques telles que la température ou l'humidité, des alertes météo, des vacances, ou des manifestations sportives qui peuvent changer les caractéristiques du réseau en ce jour à cette heure du jour. En plus, le seuil significatif de l'écart des valeurs peut être changé par le niveau du niveau de confiance statistique souhaité par un concepteur du système, l'utilisateur ou le gestionnaire de distribution de l'eau. Dans divers modes de réalisation, le seuil est . (1) un niveau de confiance statistique, calculé selon la distribution des écarts à partir de la corrélation dans les données d'historique, comme un multiple spécifié de l'écart type ; ou (2) une constante, au-dessus de laquelle le système détecte une anomalie. Dans certains modes de réalisation, le rapport de la valeur effective par la valeur prédite est analysé, plutôt que la différence entre les deux ; on doit comprendre que le terme "différence" est employé pour désigner pareillement, dans le cas de tels modes de réalisation, ce rapport. Dans un mode de réalisation, un détecteur d'anomalie trouve une anomalie lorsqu'il y a un grand écart statistiquement cohérent à partir de valeurs prévues sur une période donnée. Statistiquement important signifie une limite relative statistiquement significative (telle que N écarts type ou K fois l'intervalle interquartile, ou d'autres normalisations qui prennent en considération la distribution effective des données, selon des mises en œuvre particulières). En outre, la comparaison de lectures "momentanées" aux valeurs attendues, en utilisant l'écart type global (ou tout autre descripteur statistique) de différences par rapport à des valeurs attendues peut produire un nombre élevé de faux positifs, parce que la comparaison peut, par exemple, confondre des heures du jour à forte variance et des heures du jour à faible variance. Par conséquent, pour réduire cette erreur, le système compare une lecture X(t) à la valeur attendue P(t) en divisant X(t) - P(t) en, par exemple, l'écart type de telles différences à cette heure approximative du jour, à ce jour de la semaine. L'ampleur de la limite relative et la durée de la période sont des paramètres du procédé, permettant à des instanciations particulières de se concentrer, alternativement, sur des événements plus courts ou plus petits. Dans un autre mode de réalisation, un détecteur d'anomalie calcule le secteur sous la courbe (AUC) de la différence entre des valeurs effectives et prédites sur des périodes fixes particulières (ou, alternativement, de la valeur absolue de cette différence - ceci affecte le fait que des valeurs basses peuvent neutraliser des valeurs élevées subséquentes). Ce calcul peut être exécuté de cette façon, par exemple, chaque quart de jour. L'AUC n'est pas en soi une quantité statistique, mais puisqu'il s'agit de périodes fixes, la distribution peut être mesurée de façon empirique : si seuls 5% des valeurs AUC du compteur X entre minuit et 6h du matin en un jour de la semaine sont plus grands que X0, alors la probabilité de trouver une telle valeur AUC est d'approximativement "5%". La durée des périodes fixes (et à quelles périodes on les compare) sont des paramètres du procédé, qui permettent à des instanciations particulières de se concentrer alternativement sur des événements plus courts ou plus petits. Le moteur 207 de décision et de classification des événements peut fonctionner pour comparer une analyse statistique à partir des M détecteurs 206 d'anomalies pour déterminer la probabilité statistique globale de l'hypothèse d'absence d'anomalie compte tenu de lectures récentes de compteurs. Le moteur 207 augmenterait la probabilité statistique d'un événement selon la détection de plusieurs anomalies, du même ou de compteurs différents et au même moment ou sur une période donnée, qui indiquent tous de manière uniforme l'occurrence de l'événement. Par exemple, une anomalie peut représenter le début d'un événement et une autre anomalie peut représenter un changement ou la fin de l'événement, et le moteur 207 de classification reconnaît ces anomalies comme étant liées à un seul événement. A titre d'autre exemple, deux anomalies de différents compteurs relatives à un accroissement de débit, au même moment et à partir d'emplacements liés, indiqueraient toutes deux le même événement. Dans un mode de réalisation, des heuristiques sont employées pour déterminer la probabilité statistique globale d'une lecture de compteur, selon une combinaison de la probabilité statistique d'une lecture d'après les données statistiques temporelles, et la probabilité statistique d'une lecture d'après les données statistiques spatiales. Par exemple, si la comparaison des données statistiques d'historique indique que la probabilité pour que la lecture actuelle du compteur soit aussi élevée n'est que de 15%, mais que la comparaison de données statistiques spatiales indique que la probabilité pour que la lecture actuelle du compteur soit aussi élevée est de 95%, alors la probabilité globale pour que la lecture soit aussi élevée est de 75%. Voir, par exemple, Koziol, James et Tuckwell. Henry, "A basian method for combining Statistical Tests". Journal of. Statistical Planning and Inference 1999 : 78 (1-2), 317-323, cité à titre de référence. Des exemples d'événements détectés par le moteur d'analyse sont une fuite d'eau, un éclatement, un compteur défectueux, un vol d'eau, un défaut de communication, un problème de qualité de l'eau, une augmentation inattendue de consommation, un changement de profil de consommation, des défauts de fonctionnement du réseau tels que des niveaux ou des pressions de réservoirs anormaux, et autres analogues. On peut inclure plus de détails concernant les événements tels que l'heure de début de l'événement, l'heure de fin de l'événement, l'ampleur de l'événement, une perte totale d'eau liée à l'événement, par exemple. Le moteur 207 de décision et de classification des événements génère également des données supplémentaires concernant chaque événement, telles que l'heure de début, l'heure de fin, l'ampleur de l'événement, une ampleur accumulée de l'événement comme l'eau totale perdue depuis le début de la fuite, le type, l'état et les unités physiques de l'événement, telles que les unités de pression, de pH, ou la concentration en chlore. L'ampleur de l'événement est, dans certains modes de réalisation, une valeur représentant la taille ou la proportion de l'événement, telle qu'un calcul du débit en plus par rapport aux conditions normales, l'erreur de calcul du compteur, ou le changement du niveau de chlore. Cette information est stockée dans la base de données 208 pour être envoyée en outre aux interfaces 209. Certaines sorties d'anomalies sont mises en correspondance avec certains champs d'événements stockés dans la base de données 208.

Des exemples de champs liés aux événements sont : le type d'événement (comme le détermine le moteur 207 de décision et de classification des événements), l'heure de début, l'heure de fin, l'ampleur, et les unités physiques du type d'événement.

L'homme du métier appréciera qu'en utilisant plusieurs prédicteurs et détecteurs d'anomalies, la comparaison de probabilités statistiques à partir des M détecteurs 206 d'anomalies peut avoir comme conséquence soit une confiance accrue qu'un événement détecté est une anomalie, soit une confiance réduite qu'un événement détecté est une anomalie. Dans un mode de réalisation, le moteur 207 de décision et de classification des événements peut pondérer équitablement les événements ou des parties d'événements envoyés de chaque détecteur d'anomalie M. Dans un autre mode de réalisation, le moteur 207 de décision et de classification des événements peut attribuer des poids aux événements ou aux parties d'événements envoyés de chaque détecteur d'anomalie M selon une configuration prédéfinie. La base de données 208 reçoit des informations à partir du moteur 207 de décision et de classification des événements à stocker dans la base de données 208 et à récupérer de la base de données 208 par des interfaces de sortie 209. L'interface de suivi des événements 210 procure une liste d'événements à des utilisateurs du système. Les utilisateurs peuvent visualiser des événements individuels et leurs données associées en sélectionnant un événement sur la liste. Les événements envoyés à l'interface de suivi des événements 210 peuvent être filtrés par l'utilisateur du système. Par exemple, un utilisateur dont la tâche consiste à réparer des fuites uniquement ne peut voir que les événements de type fuite, alors qu'un administrateur du système peut voir tout type d'événements et les données d'événements ou une vue agrégée d'événements. Des utilisateurs distincts voient des types d'événements distincts, et les besoins ou responsabilités d'un utilisateur peuvent dicter les événements que l'utilisateur est amené à voir. Par exemple, un gestionnaire de fuites peut ne voir que les événements de type fuites à niveau de confiance élevé, ou que les fuites avec une importance dépassant un certain seuil fixé. Dans un autre exemple, des utilisateurs dont la tâche est la surveillance d'un voisinage voient des événements associés à des données de compteur de ce voisinage. Dans un autre exemple, des gestionnaires du réseau d'eau 201 voient tous les événements associés au réseau d'eau 201, alors que les administrateurs des deux réseaux d'eau 200 et 201 voient tous les événements associés aux deux réseaux. L'homme du métier reconnaîtra qu'une interface utilisateur fondée sur les rôles, le contrôle d'accès, et les procédés de gestion d'utilisateurs qui peuvent être gérés par des administrateurs système, peut être utilisée pour apporter cette granularité d'accès à des données et comptes rendus d'événements. Les données d'événements représentées dans l'interface de suivi d'événements 210 peuvent inclure l'heure de début de l'événement, le type, l'emplacement, l'ampleur, et l'état. En outre, un utilisateur qui sélectionne l'événement peut en outre avoir plus d'informations détaillées telles que des cartes, des graphiques, des commentaires postés par des utilisateurs associés à l'événement sélectionné et des annotations relatives à des événements sélectionnés, cartes, graphiques et analogues réalisés par les moteurs ou les utilisateurs, comme expliqué ci-dessous. Comme exemple plus détaillé, les utilisateurs de l'interface de suivi des événements peuvent annoter les événements, ou inclure des liens hypertexte à d'autres événements ou objets d'interfaces utilisateurs. Les annotations sont communiquées de l'interface de suivi d'événements sous forme, par exemple, de champs HTML, que l'on communique sur le web et que l'on stocke dans la base de données 208 dans l'enregistrement d'événements associé pour que d'autres utilisateurs du système les voient. Les utilisateurs peuvent également attribuer la propriété ou la responsabilité d'un événement ou de tâches associées à l'événement à d'autres utilisateurs du système. Par exemple, un analyste de fuites peut attribuer une fuite suspecte particulière à un ingénieur hydrotechnicien d'une zone adjacente, pour s'enquérir si la maintenance récente peut expliquer une anomalie de débit, ou à un gestionnaire de salle de commande pour recommander ou demander une enquête ou une réparation. Les informations détaillées concernant l'événement présentées à un utilisateur incluent des données qui vont aider davantage l'utilisateur à prendre une décision motivée quant à l'événement et agir en conséquence. Par exemple, si le système détecte une fuite et envoie un événement de type fuite à 210, le système fournit les données de l'événement à partir de l'enregistrement de l'événement et la visualisation des données à travers des cartes, graphiques, et autres analogues, pour montrer, par exemple, une comparaison des valeurs présentes effectives par rapport à des valeurs antérieures ou prédites. Par exemple, une visualisation des données de l'événement peut se faire sous la forme d'un graphique montrant le débit au cours du temps et une partie surlignée de l'augmentation du débit indiquant une fuite, pour aider l'utilisateur à se concentrer sur des aspects importants de l'événement. Des exemples de captures d'écran pour l'interface de suivi d'événements 210 sont montrés aux figures 11-15. L'interface d'alerte 211 fonctionne, selon des règles et politiques prédéfinies, en vue d'identifier certains événements qui doivent être transmis à des utilisateurs spécifiques à travers des dispositifs informatisés conçus par les utilisateurs. Par exemple, un utilisateur peut spécifier, par le biais de règles et politiques, que certains événements d'une ampleur spécifiée soient envoyés par messagerie électronique directement à l'utilisateur alors que d'autres événements d'un type plus urgent ou prioritaire ou d'ampleurs spécifiées plus importantes soient envoyés directement à son téléphone mobile par texte, radiomessage, ou autre analogue. Les alertes générées par l'interface d'alerte 211 contiennent certaines données spécifiées concernant l'alerte pour aider l'utilisateur à prendre une décision motivée quant à l'événement. L'utilisateur peut configurer l'interface d'alerte 211 quant à la quantité de détails à inclure dans les messages eux-mêmes, et à la quantité de données supplémentaires qui doivent être mises à la disposition de l'utilisateur pour récupérer, par exemple à travers une liaison à un article, dans l'interface de suivi des événements 210. L'interface 212 de comptes rendus est un système de compte rendu qui récupère des données d'événements de la base de données 208 et génère divers comptes rendus, tableaux, diagrammes, graphiques et analogues pour illustrer des événements ou des agrégations d'événements. Comme le comprendra l'homme du métier, l'interface 212 de comptes-rendus permet à des utilisateurs d'agréger des événements et des données d'événements par champ ou paramètre désiré, tel qu'un champ géographique, horaire, ou type d'événement, et analogues. Les comptes rendus produits par l'interface 212 de comptes rendus permettent à des utilisateurs tels que des gestionnaires du réseau d'eau de mieux planifier des réparations futures ou améliorations du réseau, le placement des compteurs, ou d'autres décisions liées à des considérations opérationnelles, de conception, et d'inventaire. L'interface de système propriétaire 213 est un système qui s'interface avec un autre logiciel employé par les opérateurs du système de distribution d'eau. Par exemple, l'interface de système propriétaire 213 récupère des données d'événements de la base de données 208 et les rentre en totalité, ou une partie spécifiée de celles-ci, dans un système de dossiers d'incident pour informer le personnel d'entretien des fuites ou d'autres événements. Un exemple de logiciel de dossiers d'incident est Track-it!® de Numara®'. A titre d'autre exemple, les données d'événement peuvent être envoyées à un système de flux de travaux ou un système de gestion de biens (tel que le système MaximoTM fourni par IBM Corp.) de sorte que l'on puisse intervenir plus rapidement sur l'événement. Des données d'événement, pour établir un compte rendu aux utilisateurs, sont bien classées et peuvent être adaptées pour être utilisées par toute interface industrielle standard. Un exemple d'interface de système de flux de travaux est Bizflow® de Handysoft. En plus de tous les modes de réalisation précédemment décrits, les éléments 203 - 209 peuvent résider sur un serveur ou sur un ensemble de serveurs tels qu'un serveur web et peuvent utiliser un modèle de fournisseur de services applicatifs ("ASP") pour fournir à des utilisateurs des interfaces 209 l'accès aux alertes et aux comptes rendus par l'intermédiaire d'une interface Web.

La Figure 3 présente un organigramme illustrant un procédé pour surveiller un réseau d'eau selon des modes de réalisation de la présente invention. Dans l'étape 301, le système reçoit des données de ou au sujet du réseau d'eau, y compris des données de réseau (par exemple, données SCADA), des données GIS, des données opérationnelles, et des données d'événements externes du système de distribution d'eau et d'autres sources. Le système peut fonctionner pour recevoir d'autres types de données de la même source ou d'autres sources, et peut être modifié pour traiter de telles données avec la même approche analytique.

L'étape 301 peut être exécutée, dans un mode de réalisation, par l'élément 100 sur la figure 1, ou plus spécifiquement par l'élément 203 sur la figure 2. Ensuite, dans l'étape 302, le système analyse les données reçues en utilisant des modèles statistiques et d'autres algorithmes décrits ici. L'étape 302 peut être exécutée, dans un mode de réalisation, par l'élément 100 sur la figure 1, ou plus spécifiquement toute combinaison des éléments 204-208 dans la figure 2. Enfin, dans l'étape 303, le système produit et affiche une sortie comprenant des événements, des alertes, des comptes rendus et des graphiques. L'étape 303 peut être exécutée, dans un mode de réalisation, par des éléments 106-112 dans la figure 1, ou plus spécifiquement par des éléments 210-214 dans la figure 2. La figure 4 présente un organigramme illustrant de manière plus détaillée un procédé pour surveiller un réseau d'eau selon des modes de réalisation de la présente invention. Dans l'étape 401 le système reçoit des données du réseau d'eau analysé ; les données comprenant l'identification et des emplacements géographiques des compteurs dans le réseau. Ensuite, dans l'étape 402, le système choisit au moins un compteur à analyser. Ensuite, dans l'étape 403, le système prédit une distribution probable de valeurs sur la base des données reçues dans l'étape 401. Des modes de réalisation pour prévoir une distribution probable des valeurs sont discutés en référence à la figure 5. Ensuite, dans l'étape 4.04 le système détermine s'il existe un écart statistiquement significatif de valeurs après avoir comparé les valeurs prédites aux valeurs effectives. Des modes de réalisation pour déterminer l'importance des écarts sont discutés en référence à la figure 2. S'il n'y a aucun écart des valeurs, ou que l'écart n'est pas significatif, le système passe à l'étape 402 et choisit une autre cible à analyser. Si, en revanche le système détermine que l'écart des valeurs est significatif, le système passe à l'étape 405 et détecte une anomalie. Ensuite, dans l'étape 406 le système classe l'événement ou parties de l'événement. Ensuite, dans l'étape 406a le système détermine si l'événement ou l'événement connexe existe dans la base de données. Si l'événement ou l'événement connexe n'existe pas dans la base de données, le système passe à l'étape 406b et crée un événement dans la base de données. Cependant, si l'événement ou un événement connexe existe dans la base de données, le système met à jour l'événement précédemment stocké dans la base de données dans l'étape 406c. En vue de déterminer si l'événement détecté existe dans la base de données, le système compare l'événement détecté à des événements actifs qui ont été précédemment stockés dans la base de données. Un événement actif peut être un événement qui est encore en cours, comme une fuite qui a été précédemment détectée mais qui n'a pas été encore réparée. Dans un mode de réalisation, pour déterminer les événements qui sont encore actifs, le système détermine si un événement, tel qu'une fuite, a pris fin. Le système détermine si un événement détecté se rapporte à un événement précédemment stocké en regardant la similitude de types d'événements, l'heure de début de l'événement détecté et de l'événement précédemment stocké, que l'événement précédemment stocké n'a pas pris fin, l'emplacement de l'événement détecté et de l'événement précédemment stocké, ou tous autres champs de données qui peuvent lier les deux événements ou plus en tant que détections alternatives ou partielles du même événement réel physique. Dans un mode de réalisation, lorsque le système met à jour l'événement dans l'étape 406c, l'enregistrement de l'événement reste dans la base de données comme étant le même événement, de sorte que les utilisateurs surveillant l'événement précédemment stocké observent l'événement détecté et son impact sur le statut de l'événement précédemment stocké. Ensuite, dans l'étape 407, le système fournit l'événement et des données associées à une interface ou à un autre système capable de rendre compte ou de stocker les données. Dans un mode de réalisation, les données associées fournies avec l'événement sont des données associées à la détection de l'événement. Par exemple, si le système détecte et classe une fuite, les données associées fournies à une interface utilisateur peuvent être une carte montrant l'emplacement de la fuite, aussi bien que des graphiques montrant la différence de débit au cours du temps qui a incité le système à montrer l'événement.

Dans l'étape 408, le système choisit la prochaine cible à surveiller, et le système poursuit la détection d'anomalies pour d'autres compteurs dans le réseau. La Figure 5 présente un organigramme illustrant un procédé pour la prédiction de valeurs dans l'étape 403 de la figure 4. Le système de la figure 5 exécute une prédiction en choisissant d'abord des attributs dans l'étape 501. Les attributs sont, de façon générale, des collectes de données, telles que les données d'historique d'un compteur donné. Les données d'historique du compteur peuvent inclure une lecture de compteur et la date et l'heure correspondantes pour cette lecture de compteur. Dans un mode de réalisation, les attributs choisis sont des données de l'historique du compteur pour un compteur, ou des compteurs, correspondant(s), selon une forte corrélation des données d'historique du compteur à analyser avec les données d'historique du ou des compteurs correspondants choisis. La figure 6 présente un mode de réalisation qui consiste à déterminer des compteurs correspondants selon une forte corrélation avec les données d'historique du compteur à analyser.

Ensuite, dans l'étape 502, le système peut déterminer la combinaison offrant la meilleure approximation des attributs choisis selon une erreur métrique, par exemple à l'aide d'une régression linéaire et la mesure de l'erreur quadratique moyenne (RMSE). La combinaison de la meilleure approximation produit une fonction des attributs choisis qui fait une approximation de l'ensemble de données à prédire. Ensuite, dans l'étape 503, le système prévoit la distribution probable de valeurs des attributs choisis en appliquant la fonction obtenue à l'étape 502 avec des données des attributs choisis. L'ensemble de données résultant inclut une distribution probable de valeurs pour le compteur. Ensuite, l'ensemble de données résultant passe des prédicteurs dans l'élément 205 à un détecteur d'anomalie correspondant dans l'élément 206 de la figure 2. De façon générale, on peut générer une prédiction en choisissant plusieurs attributs tels que des ensembles de données de compteur et en les combinant pour produire une approximation proche de l'ensemble de données pour lequel une prédiction est générée. Dans un mode de réalisation, "sélection indépendante d'attributs", la sélection d'attributs se fait en choisissant les N ensembles de données qui ont chacun, individuellement, la meilleure approximation avec l'ensemble de données sous analyse. A titre d'exemple, si le métrique d'erreur utilisé est l'erreur quadratique moyenne (RMSE), et les attributs doivent être combinés de manière affinée, ensuite les ensembles de données choisis seront les ensembles de données qui chacun, individuellement, se rapproche le mieux de l'ensemble de données analysé, en termes de RMSE, sous la transformation affinée de la meilleure approximation. A cet effet, le système trouve les paramètres de la meilleure approximation pour chaque ensemble individuel de données (par rapport à l'approximation de l'ensemble de données sous analyse), et enregistre l'erreur d'approximation réalisée par chaque ensemble de données avec des paramètres optimaux ; le système choisit les ensembles de données avec les erreurs les plus basses (meilleure approximation). Comme l'appréciera l'homme du métier, on peut trouver les paramètres de la meilleure approximation par des procédés bien connus, tels qu'une régression linéaire. Dans un autre mode de réalisation, "sélection exhaustive d'attributs", la sélection d'attributs se fait en choisissant les N ensembles de données qui minimisent l'erreur de prédiction en explorant tous les N-uplets possibles des ensembles de données disponibles pour la prédiction. Pour chaque N-uplet, le système trouve les paramètres de la meilleure approximation (pour se rapprocher de l'ensemble de données sous analyse, par rapport à un métrique d'erreur spécifique tel que RMSE), enregistre l'erreur d'approximation réalisée, et choisit le N-uplet avec la plus basse erreur (meilleure approximation). Dans un mode de réalisation, "sélection d'attributs incrémentale", la sélection d'attributs se fait en choisissant les N ensembles de données un à un, de sorte que chaque ensemble de données supplémentaire fournisse la plus grande réduction en termes d'erreur d'approximation, en générant la combinaison de la meilleure approximation d'ensembles de données déjà choisis avec le nouvel ensemble de données. A l'étape K+l, quand K ensembles de données ont été déjà choisis (K<N), le système détermine l'ensemble de données K+l pour les leur ajouter en trouvant les paramètres de la meilleure approximation et en enregistrant l'erreur d'approximation pour toutes les collectes des K+l ensembles de données comprenant les K ensembles de données déjà choisis et l'un des autres ensembles de données disponibles pour la prédiction ; le système choisit l'ensemble de données supplémentaire qui réalise la plus basse erreur (meilleur approximation). La figure 7 fournit un organigramme pour un mode de réalisation de la "sélection d'attributs incrémentale". Dans l'étape 701 le système choisit le premier ensemble de données, ou des données de compteur, à ajouter aux attributs choisis. Le premier ensemble de données peut être choisi sur la base de l'analyse d'une forte corrélation avec les données de compteur. Ensuite, dans l'étape 702, le système détermine si une autre collecte de données doit être ajoutée à l'ensemble de données en déterminant si N, le nombre d'ensembles de données dans la combinaison, est inférieur à K, le nombre prédéfini d'ensembles de données dont le concepteur permet la combinaison. Dans le cas contraire, le système passe à l'étape 708 et exécute l'analyse. Si une autre collecte de données doit être ajoutée à l'ensemble de données, le système passe à l'étape 703 et choisit une deuxième collecte de données à ajouter à l'ensemble de données. Ensuite, dans l'étape 704 le système trouve les paramètres de la meilleure approximation pour toutes les collectes de données dans l'ensemble de données, et enregistre ensuite les erreurs d'approximation pour toutes les collectes de données dans l'ensemble de données dans l'étape 705. Ensuite, dans l'étape 706 le système détermine si l'ensemble de données supplémentaire réalise la plus basse erreur en déterminant la meilleure approximation. Si l'ensemble de données supplémentaire ne réalise pas la plus basse erreur, le système passe à l'étape 702. Cependant, si la deuxième collecte de données devait réaliser la plus basse erreur, le système passe à l'étape 707 et ajoute la deuxième collecte de données à l'ensemble de données. Le système passe alors à l'étape 702.

Après chacun de ces modes de réalisation de sélection d'attributs, la sélection de paramètres passe ensuite par des procédés quelconques familiers de l'homme du métier, tels qu'une régression linéaire, pour produire la combinaison affinée de la meilleure approximation de tous les ensembles de données choisis, en termes de métrique d'erreur employé (par exemple, RMSE). Dans un mode de réalisation, plusieurs régressions ou procédés de régression différents sont utilisés en parallèle, et le résultat est la combinaison médiane ou moyenne ou semblable de résultats de régressions individuelles.

Comme s'en rendra compte l'homme du métier, "sélection indépendante d'attributs" est, sur le plan informatique, le plus rapide mais le moins précis de ces modes de réalisation, "sélection approfondie d'attributs" est, sur le plan informatique, le plus lent mais le plus précis de ces modes de réalisation, et "sélection d'attributs incrémentale" peut fournir un niveau intermédiaire de précision avec une vitesse de calcul intermédiaire. Généralement, les ensembles de données qui peuvent être utilisés pour des prédictions incluent tout ou partie des ensembles de données de compteur reçus par le système, tels que toutes les séries chronologiques de lectures de compteurs et les transformations des ensembles de données tels que les décalages temporels des séries chronologiques des lectures de compteurs. Dans un mode de réalisation, les ensembles de données qui sont disponibles pour la prédiction (les attributs à partir desquels la sélection d'attributs doit choisir N ensembles) sont les ensembles de données pour des compteurs autres que le compteur sous analyse, et certains décalages temporels de l'ensemble de données pour le compteur analysé et d'autres compteurs. Les décalages temporels correspondent à des multiples des périodes cycliques prévues dans les données, telles qu'un jour, une semaine, et un an. A titre d'exemple, les autres compteurs dont les ensembles de données sont considérés peuvent être le groupement complet de compteurs disponibles, ou le groupement de compteurs qui mesurent la même quantité (par exemple, compteurs de débit, si le compteur sous analyse est un compteur de débit), ou seulement des compteurs qui sont placés éloignés du compteur sous analyse, de sorte qu'un événement local enregistré par le compteur sous analyse n'est pas susceptible de se propager hydrauliquement à travers le réseau vers l'un quelconque des compteurs distants. Dans certains modes de réalisation, les données de compteur utilisées peuvent être une version traitée des données originales de compteur reçues, et peuvent être en outre limitées dans le temps de toutes les données d'historique. Par exemple, les ensembles de données utilisés pour l'analyse ci-dessus peuvent être des valeurs moyennes de compteurs calculées sur des périodes consécutives de six heures (une valeur moyenne pour chaque compteur toutes les 6 heures), commençant 70 jours avant l'heure actuelle, et finissant 7 jours avant l'heure actuelle. Ceci pourrait, par exemple, éliminer tout effet indésirable de dissimilitude récente entre compteurs, du fait d'un effet courant qui doit être détecté ; toute dissimilitude hors sujet qui aurait pu exister il y a longtemps (comme pendant une autre saison) ; et de courtes différences pendant la journée. La figure 6 présente un organigramme illustrant un procédé pour la sélection de données correspondantes pour une prédiction concernant un compteur correspondant. La figure 6 représente un sous-cas simple des algorithmes de sélection cités ci-dessus, dans lesquels un ensemble de données simple d'un compteur distinct est choisi comme ensemble de données correspondant. Ceci utilise l'observation selon laquelle des compteurs distants ne peuvent habituellement pas être affectés par les mêmes événements locaux, tels qu'une fuite en aval de l'un des compteurs, mais peuvent être similairement affectés par des événements globaux de consommation ou de réseau (tels qu'un jour de chaleur ou une manifestation sportive), évitant ainsi beaucoup de fausses alertes potentielles. Dans l'étape 601 le système choisit un premier ensemble de données comprenant des données d'historique d'un compteur. Les données d'historique comportent des valeurs de pression et de débit et l'heure liée aux lectures de pression et de débit. Ensuite, dans l'étape 602, le système choisit un deuxième ensemble de données, le deuxième ensemble de données comprenant des données d'historique d'un compteur. Dans un mode de réalisation le deuxième ensemble de données consiste en des données d'historique d'un dispositif de réseau physiquement différent et pas fortement relié hydrauliquement au dispositif de réseau représenté par le premier ensemble de données. Par exemple, le premier ensemble de données est associé à un compteur situé à Manhattan, et le deuxième ensemble de données est associé à un compteur situé dans le quartier du Queens. Des emplacements choisis peuvent être assez éloignés ou suffisamment à l'écart du compteur analysé de sorte que les ensembles de données ne soient pas hydrauliquement reliés, et donc, non affectés par la même anomalie ou événement, par exemple, leur débit d'eau n'est pas affecté par les mêmes fuites, des changements de qualité d'eau de l'un n'affectant pas l'autre, et analogues. Cependant, bien que le deuxième ensemble de données ne soit pas affecté par le même événement hydraulique local, les deux ensembles de données peuvent toujours être affectés par le même événement régional ou global, tel qu'un jour chaud ou une manifestation sportive couvrant toute la ville. Dans un autre mode de réalisation, le deuxième ensemble de données est un ensemble de données d'une période différente du même compteur représentée par le premier ensemble de données. Par exemple, le premier ensemble de données provient du compteur 1, et le deuxième ensemble de données provient également du compteur 1 mais représente des données de trois jours avant.

Ensuite, dans l'étape 603, le système compare les données d'historique du premier ensemble de données aux données d'historique du deuxième ensemble de données pour déterminer si une forte corrélation entre les deux compteurs existe. On peut déterminer une corrélation selon des techniques standard de corrélation connues dans l'art. Certaines techniques existantes de corrélation connues dans l'art sont décrites dans Miles, Jeremy et Shevlin, Mark Applying Regression and Correlation: A Guide for Students and Researchers, Sage Publications Ltd. (2000), ISBN 0761962301. Une corrélation peut être considérée comme forte si la valeur de corrélation dépasse un seuil prédéterminé, dans ce cas, le système passe à l'étape 604. Par exemple, si le métrique de corrélation utilisé est R2 (également appelé coefficient de détermination), qui se trouve dans la plage de 0 à 1, alors le système peut identifier les compteurs comme compteurs correspondants si le R2 calculé est au-dessus d'une valeur prédéfinie telle que 0,9. Dans l'étape 604, le système détermine si un autre ensemble de données correspondant peut être nécessaire. Dans un mode de réalisation, un autre ensemble de données correspondant peut être nécessaire pour permettre une détection d'anomalies plus précise, et le système passe à l'étape 602. Si aucun ensemble de données correspondant n'est nécessaire, le système exécute l'analyse dans l'étape 605, et comme cité en référence à la figure 5. Cependant, en revenant à l'étape 603, et dans un autre exemple, si la valeur de corrélation est inférieure au seuil, le système peut reconnaître que les ensembles de données ne présentent pas de forte corrélation, dans ce cas, le système passe à l'étape 602 et un autre ensemble de données est choisi. Dans certains modes de réalisation, les données utilisées par un prédicteur peuvent inclure d'autres formes de données disponibles pour le moteur d'analyse du réseau, telles que des données externes et opérationnelles, décrites ci-dessus. De telles données peuvent être par exemple utilisées en outre pour limiter, améliorer, ou classer les données de compteur. A titre d'illustration, un prédicteur peut utiliser de telles données de sorte que seules des données de vacances précédentes (jours ouvrables non ordinaires) soient utilisées pour prédire des valeurs pour vacances actuelles, ou éliminer les effets météorologiques non saisonniers, d'événements connus de réseau, ou de changements provisoires au niveau du réseau.

La Figure 8 présente un organigramme illustrant un procédé pour détecter et enregistrer un événement de fuite d'eau. Dans l'étape 801, le système obtient des données prétraitées à partir du système de distribution d'eau. Ensuite, dans l'étape 802, le système exécute un nombre N de prédictions statistiques selon le nombre N de modèles de prédictions statistiques. Ensuite, dans l'étape 803, et pour chaque prédicteur, le système compare les données de prédiction aux données effectives pour déterminer s'il existe un écart statistiquement significatif. Si aucun écart statistiquement significatif n'existe pour le prédicteur particulier, le système passe à l'étape 807 et aucun événement n'est produit. A l'étape 807, le système passe à l'étape 808 pour choisir un autre ensemble de données de compteur à partir du réseau d'eau pour analyse.

Cependant, dans l'étape 803, s'il y a un écart statistiquement significatif pour le prédicteur particulier, le système passe à l'étape 804 et détecte une anomalie. Ensuite, dans l'étape 805, l'anomalie peut être classée comme événement selon l'étude des exemples fournie en référence à la figue 4. Par exemple, si le système, selon différents modèles de prédicteurs, rend compte d'une anomalie d'une augmentation continue statistiquement significative de débit et une anomalie d'une réduction à court terme statistiquement significative de pression (suivie par une correction de pression), les anomalies sont classées dans l'étape 805 comme le début d'un événement de fuite. A un moment ultérieur, si le système détecte une anomalie correspondante de diminution de débit d'une grandeur semblable, l'anomalie est classée comme fin de cet événement de fuite. Un autre procédé de classification des écarts dans l'étape 805 est l'utilisation de données externes pour confirmer ou réfuter les anomalies détectées dans l'étape 804. Par exemple, si le jour où l'analyse a eu lieu s'avère être un jour de vacances, où, par exemple, des profils résidentiels d'utilisation d'eau peuvent changer de manière significative, alors de grands écarts statistiques par rapport aux données prédites peuvent augmenter le seuil statistique nécessaire pour identifier un événement de fuite. Dans un autre exemple, une manifestation sportive peut déclencher une consommation accrue dans un secteur du réseau, et le système peut être équipé pour utiliser cette information en tant que donnée externe pour confirmer ou réfuter l'existence d'un événement. Dans d'autres modes de réalisation, le système peut réfuter une anomalie détectée en appliquant des limitations supplémentaires sur les données qui produisent l'anomalie. Par exemple, le système, ou les opérateurs du réseau, peut décider de fournir des alertes correspondant seulement aux fuites franchissant un certain seuil de grandeur, présentant un écart par rapport à des valeurs prédites qui durent pendant plus d'une période spécifiée, ou se produisant au-dessus d'une certaine fréquence sur une période. La sensibilité du système à détecter des fuites peut dépendre au moins en partie du seuil de grandeur déterminé par l'utilisateur, ou présentant une fuite qui dure au moins une période spécifiée. Ensuite, dans l'étape 806 le système enregistre un événement tel qu'une fuite et fournit en outre des caractéristiques d'une fuite détectée. Les caractéristiques peuvent inclure l'ampleur de la fuite, la tendance ou taux d'accroissement de la fuite et la quantité totale d'eau qui a fui jusqu'à présent. L'alerte de fuite et les caractéristiques de la fuite peuvent être stockées dans un élément comme une base de données 208 dans la figure 2, et peuvent également être reproduites sur l'une quelconque des sorties 210-214 de la figure 2. Après enregistrement d'un événement dans l'étape 806, le système passe à l'étape 808 pour choisir un autre ensemble de données de compteur du réseau pour analyse. La figure 9 présente un organigramme illustrant un procédé pour détecter une anomalie de compteur défectueux.

Dans l'étape 901 le système choisit un ensemble de données à analyser. Les éléments 902 et 905-909 représentent divers prédicteurs et détecteurs d'anomalies pour déterminer l'importance statistique de tout écart par rapport à des valeurs effectives et prédites. L'homme du métier appréciera que chaque élément 902 et 905-909 ou combinaison d'éléments peut être employé(e) pour déterminer les valeurs probables et pour rendre compte d'une anomalie. En outre, le système peut procéder en exécutant toute combinaison des éléments de manière concomitante, ou séquentielle dans un ordre quelconque. En procédant avec le mode de réalisation illustré dans l'organigramme de la figure 9, le prédicteur et les détecteurs d'anomalies représentés par l'élément 902 déterminent s'il y a un écart statistiquement significatif de la valeur transmise, ou non, au-delà de ce qui peut être expliqué par un vrai événement sur le réseau, tel qu'une fuite. Les détecteurs d'anomalies et le prédicteur représentés par les éléments 903-905 déterminent si un écart statistiquement significatif de dérive d'horloge existe, ou non, lorsque le premier ensemble de données est corrélé avec un deuxième ensemble de données. Les détecteurs d'anomalies et le prédicteur procèdent en choisissant un ensemble de données de référence ou des ensembles multiples à l'étape 903, et ensuite en corrélant le premier ensemble de données avec l'ensemble de données de référence dans l'étape 904. L'ensemble de données de référence peut inclure un ou plusieurs compteurs qui présentent habituellement des valeurs en forte corrélation avec le compteur sous analyse. Ensuite, le système passe à l'étape 905 pour déterminer si le compteur présente une dérive d'horloge statistiquement significative en recherchant le décalage temporel qui produit la meilleure corrélation. Si le compteur présente la dérive d'horloge (c'est-à-dire, si le meilleur décalage temporel est sensiblement différent de 0), le système passe à l'étape 910 et émet une alerte de défectuosité d'un compteur. Les détecteurs d'anomalies et le prédicteur représentés par l'élément 906 déterminent si une valeur fixe a été transmise. Le système détermine si une valeur fixe, ou des données qui ne changent pas au cours du temps, a été transmise dans l'étape 904. Si le compteur a transmis une valeur fixe, presque fixe ou fréquemment fixe, pendant un temps anormalement long, le système passe à l'étape 910 et émet une alerte de défectuosité d'un compteur.

Les détecteurs d'anomalies et le prédicteur représentés par l'élément 907 déterminent si la variabilité à court terme est trop importante ou trop faible. Si la variabilité à court terme est trop importante ou trop faible, le système passe à l'étape 909 et émet une alerte de défectuosité d'un compteur. Les détecteurs d'anomalies et le prédicteur représentés par l'élément 908 déterminent s'il y a un écart statistiquement significatif par rapport à la quantité de données habituelles transmises. Si on a transmis beaucoup moins ou beaucoup plus de données qu'habituellement, alors le système produit une anomalie. Par exemple, si aucune valeur n'a été transmise par le compteur pendant trois jours, le système produit une anomalie. Cependant, si l'écart entre la quantité de données prédites à transmettre et des données effectivement transmises n'est pas statistiquement significatif, aucune anomalie n'est produite. Les détecteurs d'anomalies et le prédicteur représentés par l'élément 909 déterminent si les valeurs sont confirmées ou non par d'autres compteurs de réseau. Par exemple, la conservation de masse peut indiquer que la lecture à un premier compteur de débit doit être plus grande que la lecture à un deuxième compteur de débit en aval de celui-ci, ou la somme de plusieurs autres lectures de compteurs. Si de telles valeurs "impossibles" sont trouvées, le système passe à l'étape 910 et rend compte d'un événement de défectuosité d'un compteur. Après apparition d'un événement dans l'étape 910, le système choisit la prochaine cible à analyser dans l'étape 911 et continue à analyser le réseau à la recherche d'autres compteurs défectueux. La figure 10 montre un organigramme illustrant un mode de réalisation pour fournir une anomalie de consommation inattendue ou de vol. Les éléments 1003-1005 représentent divers prédicteurs et détecteurs d'anomalie pour déterminer l'importance statistique de tout écart de valeurs effectives et prédites. L'homme du métier appréciera que chaque élément 1003-1005 ou combinaison de ces éléments peut être employé(e) pour déterminer les valeurs probables et rendre compte d'une anomalie. En outre, le système peut procéder en exécutant toute combinaison des éléments de façon concomitante, ou séquentielle dans n'importe quel ordre. A l'étape 1001 le système choisit un compteur d'un réseau d'eau à analyser à la recherche d'une consommation d'eau inattendue ou d'un vol d'eau. Dans un autre mode de réalisation, le système choisit une section d'un réseau d'eau, ou un réseau d'eau entier à analyser à la recherche d'une consommation inattendue d'eau ou d'un vol d'eau.

Ensuite, dans l'étape 1002 si le système détecte une augmentation du débit de la section du réseau ou du compteur choisi, le système avance en vue de classer encore l'anomalie, représentée par des éléments 1003-1005. Dans un certain mode de réalisation, le système peut détecter une augmentation de débit au-dessus des données d'historique du compteur et appliquer l'analyse statistique décrite en référence à la figure 2. Dans un autre mode de réalisation le système peut détecter une augmentation de débit en analysant des données en temps réel provenant du compteur. Les détecteurs d'anomalies et le prédicteur représentés par l'élément 1003 déterminent s'il y a une concordance statistiquement significative d'augmentation de débit par rapport au profil de consommation. A l'étape 1003, le système peut analyser l'augmentation actuelle de débit avec un profil de consommation précédemment stocké.

Le profil de consommation précédemment stocké peut inclure des données de compteur ou de réseau se rapportant à la dernière année, ou concernant toute autre période pour faciliter l'analyse de détermination d'un profil de consommation. Si l'augmentation de débit concorde avec le profil de consommation, le système passe à l'étape 1006 pour déterminer si l'événement peut être expliqué par un autre facteur. Les détecteurs d'anomalies et prédicteurs représentés par l'élément 1004 déterminent s'il y a une augmentation chronique statistiquement significative du débit à des heures semblables. Par exemple, le système analyse des données d'historique pour que le compteur ou le système détermine la périodicité du profil de consommation. S'il y a une augmentation chronique du débit, et que ceci ne s'est pas produit davantage dans le passé, le système passe à l'étape 1006 pour déterminer si l'événement peut être expliqué par un autre facteur. Les détecteurs d'anomalies et le prédicteur représentés par l'élément 1005 déterminent s'il y a un débit chronique statistiquement significatif ayant une grandeur semblable à chaque fois. Dans un certain mode de réalisation, le système compare les périodes d'accroissement de débit à d'autres données d'historique de débit du compteur ou du réseau pour déterminer une augmentation presque constante de l'importance du débit au cours des périodes chroniques. Si le système détecte des grandeurs semblables à chaque fois, et que ceci ne s'est pas produit davantage dans le passé, le système passe à l'étape 1006 pour déterminer si l'événement peut être expliqué par un autre facteur.

A l'étape 1006 le système détermine si un événement détecté peut être réfuté par des données externes ou opérationnelles. Dans un certain exemple, le système analyse des données opérationnelles pour déterminer s'il y avait une entrée autorisée au site sous analyse. Dans un autre exemple, le système réfute un événement détecté si une augmentation de débit au niveau d'un compteur et une diminution correspondante de débit d'une grandeur semblable au niveau d'un autre compteur pour la même région indiquent un changement de débit, mais pas un changement de consommation totale dans cette région. Si le système ne réfute pas l'événement détecté dans l'étape 1006, le système fournit un événement de consommation inattendue ou non autorisée ou de vol à l'étape 1007. Cependant, si le système réfute l'événement, le système passe à l'étape 1008. Ensuite, dans l'étape 1008, le système choisit la prochaine cible à analyser et continue d'analyser le réseau à la recherche d'autres événements de consommation inattendue ou non autorisée ou de vol. La figure 11 montre un organigramme illustrant un mode de réalisation destiné à donner une alerte d'anomalie concernant la qualité de l'eau. A l'étape 1101, le système choisit un ensemble de données du premier site à analyser. Les éléments 1103, 1104, et 1106 représentent divers prédicteurs et détecteurs d'anomalies pour déterminer l'importance statistique de tout écart de valeurs effectives et prévues. L'homme du métier appréciera que chaque élément 1103, 1104 et 1106 ou toute combinaison des éléments peut être employé(e) pour déterminer des valeurs probables et pour rendre compte d'une anomalie. En outre, le système peut procéder en exécutant toute combinaison des éléments de façon concomitante, ou séquentielle dans n'importe quel ordre. Les détecteurs d'anomalies et le prédicteur représentés par l'élément 1103 déterminent s'il y a statistiquement une modification importante au niveau du chlore, de la turbidité ou du pH dans au moins deux sites choisis dans l'étape 1102, le changement dépassant un seuil prédéfini réglé par les gestionnaires du réseau d'eau. Le système peut choisir au moins deux sites voisins ou plus dans l'étape 1102. Le nombre de sites choisis peut en outre aider le système à prévoir plus exactement une anomalie de qualité de l'eau. Si le système détecte un changement à l'étape 1103, le système passe à l'étape 1105 pour décider s'il doit rendre compte de l'événement. Les détecteurs d'anomalies et le prédicteur représentés par l'élément 1104 déterminent s'il y a une augmentation statistiquement significative de turbidité au niveau du compteur choisi du site choisi, et si c'est le cas, le système passe à l'étape 1105 pour décider s'il doit rendre compte de l'événement.

Les détecteurs d'anomalies et le prédicteur représentés par l'élément 1106 déterminent s'il y a une diminution statistiquement significative de chlore au niveau d'un même site. S'il y a une diminution de chlore au niveau du site, le système passe à l'étape 1105 pour décider s'il doit rendre compte de l'événement. A l'étape 1105 le système reçoit des événements des éléments 1103, 1104 et 1106 et détermine s'il doit rendre compte des événements ou s'il doit les disqualifier. L'une des raisons pour qu'un événement soit disqualifié est le fait qu'il y a une chute de pression, une augmentation de débit statistiquement significative ou une entrée autorisée sur le site choisi dans l'étape 1101. Dans un mode de réalisation, une entrée autorisée sur le site peut inclure une réparation du site par une équipe de construction, qui peut avoir comme conséquence une augmentation provisoire de turbidité au niveau du compteur choisi. Une chute de pression temporaire significative peut, par exemple, indiquer un événement de fuite ou d'intervention sur le réseau, qui devrait être considérée comme la cause première de ce qui semble être une anomalie de qualité. Cependant, parce qu'une réparation peut être relativement brève, le système peut ne pas vouloir fournir une alerte d'anomalie du fait d'une réparation provisoire, et le système passe à l'étape 1108 pour choisir un autre ensemble de données à analyser. Si le système ne détecte pas de chute de pression, d'augmentation de débit ou d'entrée autorisée sur le site, le système passe à l'étape 1107 et fournit un événement de qualité d'eau. Après fourniture d'un événement dans l'étape 1107, le système choisit la prochaine cible à analyser dans l'étape 1108 et continue à analyser le réseau à la recherche d'autres événements concernant la qualité de l'eau. L'homme du métier appréciera que d'autres modes de réalisation peuvent similairement traiter d'autres paramètres et indicateurs de qualité de l'eau, en prenant en considération les événements du réseau et les activités qui peuvent temporairement affecter ces autres paramètres. La figure 12 montre une capture d'écran de l'interface utilisateurs ("UI") générée par l'interface de suivi des événements selon un mode de réalisation de la présente invention. L'écran dans la figure 12 affiche des événements détectés et leurs informations associées à l'attention d'un utilisateur. L'utilisateur peut, par exemple, être un opérateur sur un réseau de distribution d'eau chargé de surveiller le réseau d'eau sous analyse. La figure 12 inclut une capture d'écran d'UI 1201 qui comporte des sections pour le statut de mise à jour 1202, le panneau 1203 de liste d'événements, le graphique 1204, les informations sur les événements 1205, le graphique 1206 et la carte 1207. Dans un mode de réalisation, l'UI 1201 est une page Web qui peut être vue par un utilisateur à travers un réseau ou Internet. En plus, le statut 1202 de mise à jour informe l'utilisateur de la dernière date et dernière heure où le système a surveillé le réseau d'eau à la recherche d'anomalies. Le panneau 1203 de liste d'événements fournit à l'utilisateur une liste des événements précédemment détectés, les dates, heures, emplacements et statut des événements. En plus du mode de réalisation, le panneau 1203 de liste d'événements permet en outre à la personne regardant l'interface utilisateurs 1201 de choisir un événement dans le panneau 1203 de liste d'événements. Des informations détaillées liées à l'événement choisi sont reproduites comme informations sur l'événement 1205, graphiques 1204 et 1206 et carte 1207. Les informations sur l'événement 1205 incluent, par exemple, une heure de début de l'anomalie, une heure de fin de l'anomalie, une ampleur de l'anomalie, une perte d'eau totale liée à l'anomalie et tout commentaire donné par des utilisateurs du système. Les commentaires donnés par des utilisateurs ou le système peuvent également fournir des liens hypertextes à d'autres événements stockés par le système. Les graphiques 1204 et 1206 incluent des informations détaillées au sujet de l'événement sélectionné par l'utilisateur telles qu'une comparaison visuelle du débit effectif et prévu (habituel) de l'eau au niveau d'un compteur approprié. En plus, l'interface utilisateur 1201 utilise des données GIS liées à l'événement choisi pour montrer l'emplacement de l'événement sur la carte 1207. Dans un mode de réalisation, l'événement est associé à un compteur spécifique, et l'emplacement du compteur est reproduit sur la carte 1207. La carte 1207 d'événements peut également afficher un secteur du réseau affecté par l'événement détecté, ou un secteur où l'on estime que l'emplacement précis de l'événement est statistiquement susceptible de se trouver. La base de données 208 ou même le moteur 207 de décision et de classification des événements de la figure 2 peuvent accueillir une application logicielle interactive qui associe des données de compteur, alertes, comptes rendus, analyse statistique et une carte du réseau d'eau avec une interface utilisateur pour permettre à un utilisateur du système de distinguer facilement l'emplacement d'une fuite de l'eau ou de tout autre événement. Une interface utilisateur peut être accueillie dans la base de données 208 et présentée à toute interface représentée par l'élément 209. Dans un autre mode de réalisation, le moteur 207 de décision et de classification des événements peut fonctionner pour envoyer directement l'information aux éléments 210, 211, 212, 213, 214. La figure 13 montre une capture d'écran de l'UI que génère l'interface de suivi des événements selon un mode de réalisation de la présente invention. L'écran dans la figure 13 affiche des événements détectés et leurs informations associées à l'attention d'un utilisateur. L'utilisateur peut par exemple être un opérateur sur un réseau de distribution d'eau chargé de surveiller le réseau d'eau sous analyse. La figure 13 inclut l'UI 1301 qui inclut le panneau 1302 de liste d'événements, les graphiques 1303 et 1304, la carte 1305 et des informations sur les événements 1306. Dans un mode de réalisation, l'UI 1301 est une page Web que peut visualiser un utilisateur à travers un réseau ou sur Internet. En plus, le panneau 1302 de liste d'événements fournit à l'utilisateur une liste des événements précédemment détectés, des dates, heures, emplacements de compteurs et statut des événements. En plus du mode de réalisation, le panneau 1302 de liste d'événements permet en outre à la personne visualisant l'UI 1301 de choisir un événement dans le panneau 1302 de liste d'événements. Des informations détaillées liées à l'événement choisi sont reproduites comme informations sur l'événement 1306, graphiques 1303 et 1304 et carte 1305. L'interface utilisateur 1301 utilise des données GIS liées à l'événement choisi pour afficher l'emplacement ou l'emplacement approximatif de l'événement sur la carte 1305. Dans un mode de réalisation, la carte 1305 peut fonctionner pour afficher l'emplacement de plusieurs compteurs enregistrant un événement.

La figure 14 montre une capture d'écran d'une autre UI générée par l'interface de suivi des événements selon un mode de réalisation de la présente invention. L'écran dans la figure 14 affiche des données liées à un événement détecté ou à un compteur ou région du réseau choisi(e).

L'utilisateur peut, par exemple, être un opérateur sur un réseau de distribution d'eau chargé de surveiller le réseau d'eau sous analyse, et plus spécifiquement, la figure 14 représente un module de graphiques illustrant des données collectées par le système, et permettant à l'utilisateur d'explorer, personnaliser et changer davantage les graphiques donnés par le système pour chaque événement, ou d'explorer indépendamment les données à travers diverses visualisations et en utilisant une partie des capacités de prétraitement du système. La figure 14 inclut l'UI 1401, le panneau 1402 de liste des compteurs et de commande des graphiques 1402, le graphique 1403 et le statut 1404 de mise à jour. Dans un mode de réalisation, l'UI 1401 est une page Web que peut visualiser un utilisateur à travers un réseau ou sur Internet. L'utilisateur de l'UI 1401 peut choisir un ou plusieurs compteurs et un large éventail de types de graphiques à partir du panneau 1402 de la liste de compteurs et de commande des graphiques. Les données liées au/aux compteur(s) choisi(s) peuvent être produites dans le graphique 1403. Les données produites dans le graphique 1403 peuvent être toute information obtenue par le système. Le statut 1402 de mise à jour informe l'utilisateur de la dernière date et dernière heure où le système a surveillé le réseau d'eau à la recherche d'anomalies. La figure 15 montre une capture d'écran de l'UI générée par l'interface de comptes rendus selon un mode de réalisation de la présente invention. L'écran de la figure 15 affiche un aperçu global des événements détectés et de leurs informations associées à l'attention d'un utilisateur. L'utilisateur peut, par exemple, être un opérateur sur un réseau de distribution d'eau chargé de surveiller le réseau d'eau sous analyse. La figure 15 inclut l'UI 1501, le panneau 1502 de sélection d'aperçu, les panneaux de comptage des événements 1503 et 1504, la carte 1505 et les graphiques 1506. Dans un mode de réalisation, l'UI 1501 est une page Web que peut visualiser un utilisateur à travers un réseau ou sur Internet. En plus, le panneau 1502 d'aperçu fournit à l'utilisateur des options pour afficher toute agrégation d'événements sur une période choisie. L'utilisateur peut choisir l'affichage des événements selon des valeurs de compteurs, des événements, des dates et le statut des événements. Les informations détaillées liées à la sélection faite par l'utilisateur dans le panneau 1502 de sélection d'aperçu sont reproduites en tant que panneaux de comptage d'événements 1503 et 1504, carte 1505, et graphiques 1506. Le panneau 1502 de sélection d'aperçu permet à l'utilisateur de trier et filtrer des événements par leurs divers champs et caractéristiques, par exemple, de ne regarder que des événements récents et non résolus, des événements triés par type, et de mettre à jour des statuts d'événements ainsi que d'autres caractéristiques de flux de travaux. Ceci est conforme à des standards de l'industrie des logiciels, bien connus par l'homme du métier. Les panneaux de comptage d'événements 1504 et 1505 affichent le nombre d'événements, le type d'événements et les emplacements des événements par période. Dans un mode de réalisation, les panneaux de comptage d'événements 1504 et 1505 affichent des événements correspondant à différentes périodes, permettant à un utilisateur de comparer et de contraster le comportement du réseau au cours du temps. La carte 1505 affiche l'emplacement et d'autres informations d'événements en cours ou d'événements qui se sont produits antérieurement dans un secteur. Dans un mode de réalisation, la carte illustre des événements et surligne des secteurs avec plusieurs événements des emplacements avec peu d'événements peuvent être colorés en vert, alors que des emplacements avec beaucoup d'événements peuvent être colorés en rouge. Les graphiques 1506 fonctionnent pour afficher l'évolution du nombre et des types d'événements sur une période. Dans un mode de réalisation, les graphiques 1506 illustrent les types et les nombres d'événements se produisant pendant deux mois consécutifs, par exemple permettant à l'utilisateur de comparer et d'analyser des tendances récentes. L'homme du métier appréciera que toute information collectée par le système peut être reproduite sur le graphique 1506 pour mieux aider un utilisateur chargé de surveiller le réseau de distribution d'eau. Les figures 1 à 15 sont des illustrations conceptuelles permettant d'expliquer la présente invention.

On doit comprendre que divers aspects des modes de réalisation de la présente invention peuvent être mis en oeuvre par un matériel, progiciel, logiciel ou leurs combinaisons. Dans de tels modes de réalisation, les divers composants et/ou étapes peuvent mis en oeuvre par matériel, progiciel et/ou logiciel pour réaliser les fonctions de la présente invention. C'est-à-dire que la même partie du matériel, progiciel ou module de logiciel peut exécuter un ou plusieurs des blocs illustrés (par exemple, composants ou étapes).

On doit également comprendre que l'invention s'applique non seulement aux réseaux de distribution d'eau, mais aussi à tout type de système de distribution. D'autres types de systèmes de distribution peuvent être : pétrole, eaux usées ou eaux d'égouts, gaz, électricité, téléphonie, ou d'autres systèmes de distribution d'énergie qui impliquent des ressources fluides ou circulant d'un secteur vers les consommateurs. En effet, l'invention peut être appliquée à tout système de distribution ou de collecte ayant des compteurs ou des capteurs à des emplacements arbitraires dans le réseau mesurant des paramètres de distribution tels que le débit, la pression, la qualité ou le flux de données lui-même. Dans des mises en oeuvre logicielles, le logiciel informatique (par exemple, programmes ou autres instructions) et/ou les données est stocké sur un support lisible par machine en tant qu'élément d'un produit de programme informatique, et est chargé dans un système d'ordinateur ou tout autre dispositif ou machine par l'intermédiaire d'un lecteur de stockage amovible, disque dur ou interface de communications. Des programmes d'ordinateur (également appelés logique de gestion par ordinateur ou code de programme lisible par machine) sont stockés dans une mémoire principale et/ou secondaire, et exécutés par un ou plusieurs processeurs (contrôleurs, ou analogues) pour amener le ou les processeurs à mettre en oeuvre les fonctions de l'invention telles que décrites ici. Dans ce document, les termes "support lisible par machine", "support de programme d'ordinateur" et "support utilisable par ordinateur" sont employés pour désigner généralement des médias tels qu'une mémoire vive (RAM) ; une mémoire morte (ROM) ; une unité de stockage amovible (par exemple, un disque magnétique ou optique, un dispositif de mémoire flash, ou analogues) ; un disque dur ; ou analogues. En particulier, les figures et exemples ci-dessus ne sont pas censés limiter la portée de la présente invention à un seul mode de réalisation, car d'autres modes de réalisation sont possibles en échangeant .une partie ou l'ensemble des éléments décrits ou illustrés. Par ailleurs, lorsque certains éléments de la présente invention peuvent être partiellement ou entièrement mis en œuvre en utilisant des composants connus, seules les parties de ces composants connus qui sont nécessaires pour comprendre la présente invention sont décrites, et des descriptions détaillées d'autres parties de ces composants connus ne sont pas abordées pour ne pas alourdir l'invention. Dans la présente spécification, un mode de réalisation montrant un composant singulier ne doit pas être nécessairement limité à d'autres modes de réalisation comprenant une pluralité du même composant, et vice-versa, à moins que le contraire ne soit explicitement indiqué ici. De plus, les déposants ne prévoient pas qu'un terme quelconque de la spécification ou des revendications ait une signification inhabituelle ou spéciale à moins qu'on l'indique explicitement. De plus, la présente invention englobe des équivalents connus présents et futurs aux composants connus désignés à titre d'illustration.

La description ci-dessus des modes de réalisation spécifiques divulgue si globalement la nature générale de l'invention que d'autres peuvent, en appliquant leurs connaissances dans la ou les techniques appropriées (y compris le contenu des documents cités et incorporés ici à titre de référence), aisément modifier et/ou adapter à différentes applications de tels modes de réalisation spécifiques, sans expérimentation inutile, sans s'écarter du concept général de la présente invention. Ainsi, on entend que de telles adaptations et modifications s'inscrivent dans le sens et l'étendue des équivalents des modes de réalisation divulgués, selon l'enseignement et les conseils présentés ici. Alors que divers modes de réalisation de la présente invention ont été décrits ci-dessus, on doit comprendre qu'ils ont été présentés à titre d'exemple non limitatif. Il apparaîtra clairement à l'homme du métier que divers changements de forme et de détail peuvent y être apportés sans s'écarter de l'esprit et de la portée de l'invention. Ainsi, la présente invention ne doit pas être limitée par l'un quelconque des exemples de réalisation décrits ci- dessus mais ne doit être définie que par les revendications qui suivent et leurs équivalents.

Claims (20)

1. REVENDICATIONS1. Procédé informatisé pour surveiller un réseau de distribution d'eau, le réseau de distribution d'eau comportant au moins un réseau de canalisations pour délivrer l'eau aux consommateurs et une pluralité de compteurs placés dans le réseau de distribution d'eau, le procédé comprenant : la réception de données de compteur, les données de compteur représentant une pluralité de paramètres mesurés par les compteurs, les paramètres comprenant au moins le débit ou la pression de l'eau dans les canalisations ; la réception de données secondaires d'une ou de plusieurs sources externes aux compteurs, les données secondaires représentant une ou plusieurs conditions affectant le débit ou la consommation d'eau dans une région desservie par le réseau de distribution d'eau ; l'analyse des données de compteur en prédisant statistiquement des données de compteur pour un premier compteur sur la base des deuxièmes données de compteur provenant du réseau de distribution d'eau et des données secondaires, où les deuxièmes données de compteur comportent des données de compteur autres que les premières données compteur reçues, et en comparant les premières données de compteur reçues aux données de compteur prédites pour que le premier compteur identifie un ou plusieurs événements du réseau de distribution d'eau comportant au moins un ou plusieurs événements de type fuite en détectant une anomalie si les premières données de compteur reçues s'écartent des données de compteur prédites pour le premier compteur par un écart statistique ; et le compte rendu du ou des plusieurs événements du réseau à l'attention d'un utilisateur par l'intermédiaire d'une interface utilisateur.
2. 2. Procédé de la revendication 1, comprenant le 35 stockage des événements du réseau d'eau dans une base de données.
3. 3. Procédé de la revendication 1, dans lequel la réception des données de compteur comporte la réception de données de type télésurveillance et acquisition de données (SCADA).
4. 4. Procédé de la revendication 1, comprenant la classification de l'anomalie comme événement de type fuite.
5. 5. Procédé de la revendication 1, dans lequel la détection de l'anomalie comporte le fait de déterminer si une durée de l'anomalie dépasse un seuil prédéfini.
6. 6. Procédé de la revendication 1, dans lequel la détection de l'anomalie comprend le fait de déterminer si une fréquence de l'anomalie dans une fenêtre temporelle prédéfinie dépasse un seuil prédéfini.
7. 7. Procédé de la revendication 1, dans lequel la prédiction statistique de données de compteur pour le premier compteur sur la base des deuxièmes données de compteur du réseau de distribution d'eau comporte le fait de choisir un ou plusieurs deuxièmes compteurs en tant qu'un ou plusieurs compteurs correspondants et de corréler les données de compteur reçues du premier compteur avec les données de compteur reçues du ou des plusieurs compteurs correspondants.
8. 8. Procédé de la revendication 7, dans lequel la sélection d'un ou de plusieurs deuxièmes compteurs comme le ou les plusieurs compteurs correspondants comporte le fait de corréler des données d'historique de compteur pour le ou les plusieurs deuxièmes compteurs avec des données d'historique de compteur pour le premier compteur ; et de choisir le ou les plusieurs deuxièmes compteurs pour lesquels une corrélation avec le premier compteur existe.
9. 9. Procédé de la revendication 7, dans lequel la sélection du ou des plusieurs deuxièmes compteurs comme le ou les plusieurs compteurs correspondants comporte le fait d'identifier le ou les plusieurs deuxièmes compteurs dans le réseau de distribution d'eau qui sont placés dans leréseau de distribution d'eau afin de ne pas être affectés par des anomalies affectant le premier compteur.
10. 10. Procédé de la revendication 1, dans lequel la prédiction statistique des données de compteur pour le premier compteur sur la base de deuxièmes données de compteur du réseau de distribution d'eau comporte le fait de corréler des données de compteur reçues du premier compteur avec au moins des données d'historique de compteur stockées pour le premier compteur.
11. 11. Procédé de la revendication 1, dans lequel la prédiction statistique de données de compteur pour le premier compteur comporte le fait de calculer une distribution statistique de valeurs probables pour le premier compteur.
12. 12. Procédé de la revendication 1, dans lequel les événements du réseau d'eau comportent en outre le fait d'identifier un ou plusieurs événements informationnels concernant la quantité ou la qualité de l'eau circulant dans les canalisations et le fonctionnement du réseau de distribution d'eau.
13. 13. Procédé de la revendication 12, dans lequel la réception de données de compteur comporte le fait de recevoir au fil du temps des données concernant la qualité de l'eau représentant la turbidité, le niveau de chlore et le pH de l'eau délivrée par le réseau, et dans lequel l'identification d'un ou de plusieurs événements du réseau comporte le fait de détecter le dépassement d'un seuil par les données portant sur la qualité de l'eau au cours du temps.
14. 14. Procédé de la revendication 1, dans lequel la réception de données secondaires comporte le fait de recevoir au moins une . de données météorologiques représentant des conditions météorologiques dans la région du réseau de distribution 35 d'eau ;de données calendaires représentant un ou plusieurs facteurs affectant la consommation d'eau à une date donnée ; de données de réparation représentant une ou plusieurs réparations exécutées sur le réseau de distribution d'eau ; et de données structurelles représentant une structure du réseau de distribution d'eau.
15. 15. Procédé de la revendication 12, dans lequel le ou les plusieurs événements informationnels comportent au moins l'un : d'une augmentation inattendue du profil de consommation, d'un changement de profil de consommation, d'un vol d'eau, d'une rupture au niveau d'une zone frontière, d'un défaut d'un compteur du réseau et d'un défaut de fonctionnement d'un dispositif du réseau.
16. 16. Procédé de la revendication 1, comportant le traitement des données de compteur avant de les analyser, y compris leur filtrage pour éliminer le bruit des données de compteur.
17. 17. Système informatisé pour surveiller un réseau de distribution d'eau, le réseau de distribution d'eau comportant un réseau de canalisations pour délivrer l'eau aux consommateurs et une pluralité de compteurs placés dans le réseau de distribution d'eau, le système comprenant : une base de données d'informations de réseau pour stocker des données de compteur représentant une pluralité de paramètres mesurés par les compteurs, les paramètres comprenant au moins le débit ou la pression de l'eau dans les canalisations, et des données secondaires d'une ou de plusieurs sources externes aux compteurs, les données secondaires représentant une ou plusieurs conditions affectant le débit ou la consommation de l'eau dans une région desservie par le réseau de distribution d'eau un moteur d'analyse configuré pour analyser les données de compteur en prédisant statistiquement des données de compteur pour un premier compteur sur la base de deuxièmes données de compteur du réseau de distributiond'eau et de données secondaires, dans lequel les deuxièmes données de compteur comportent des données de compteur autres que les premières données de compteur reçues, et en comparant les premières données de compteur reçues aux données de compteur prédites pour que le premier compteur identifie des anomalies ; un moteur de classification d'événements configuré pour identifier des événements du réseau de distribution d'eau sur la base des anomalies, les événements du réseau d'eau comportant des événements de type fuite ; et une base de données d'événements pour stocker des données d'événements du réseau de distribution d'eau représentant le ou les événements du réseau d'eau identifiés par le moteur de classification d'événements.
18. 18. Système de la revendication 17, dans lequel le moteur d'analyse comporte une pluralité de modules de prédiction pour générer une distribution statistique de valeurs probables des données de compteur pour un compteur donné et une pluralité de modules détecteurs d'anomalies pour comparer les données de compteur pour le compteur donné à la distribution de valeurs probables pour détecter des anomalies dans les données de compteur.
19. 19. Système de la revendication 17, comportant une pluralité de modules d'interface pour récupérer des données d'événements du réseau de distribution d'eau à partir de la base de données d'événements et les rapporter aux utilisateurs.
20. 20. Procédé informatisé pour gérer un réseau de distribution d'eau, le réseau de distribution d'eau comportant un réseau de canalisations pour délivrer l'eau aux consommateurs et une pluralité de compteurs placés dans le réseau de distribution d'eau, le procédé comprenant : l'envoi de données de compteur à un moteur d'analyse, les données de compteur représentant une pluralité de paramètres mesurés par les compteurs, les paramètrescomprenant au moins le débit de l'eau dans les canalisations ; la réception à partir du moteur d'analyse de données représentant des événements du réseau de distribution d'eau, les événements du réseau d'eau comportant des événements de type fuite, les données d'événements du réseau de distribution d'eau ayant été identifiées comme un résultat de l'analyse des données de compteur en prédisant statistiquement des données de compteur pour un premier compteur sur la base de deuxièmes données de compteur à partir du réseau de distribution d'eau et de données secondaires, les données secondaires représentant une ou plusieurs conditions affectant la consommation ou le débit d'eau dans une région desservie par le réseau de distribution d'eau, où les deuxièmes données de compteur comportent des données de compteur autres que les premières données de compteur reçues, et la comparaison des premières données de compteur reçues aux données de compteur prédites pour que le premier compteur identifie des anomalies ; et l'affichage des événements reçus du réseau de distribution d'eau à l'attention d'un utilisateur sur un dispositif d'affichage informatisé.