BRPI1101199A2

BRPI1101199A2 - método e sistema computadorizado para monitorar uma rede de distribuição de água, e, método computadorizado para administrar uma rede de distribuição de água

Info

Publication number: BRPI1101199A2
Application number: BRPI1101199-8A
Authority: BR
Inventors: Amir Peleg; Uri Barkay; Shai Gutner; Amitai Armon; Haggau Scolnicov
Original assignee: Takadu Ltd
Priority date: 2010-03-04
Filing date: 2011-03-03
Publication date: 2012-10-16
Also published as: ZA201207123B; EP2472467A1; TWI391803B; IE86368B1; GB201103783D0; TWI502299B; IE20120498A1; IE20110098A1; CO6630098A2; PT2472467T; AR080458A1; RU2012142174A; ES2420865T3; GB2499113A; CL2011000466A1; SG193853A1; CN102884407B; TW201303785A; KR20140145637A; AU2011200949B1

Abstract

MéTODO E SISTEMA COMPUTADORIZADO PARA MONITORAR UMA REDE DE DISTRIBUIçãO DE áGUA, E, MéTODO COMPUTADORIZADO PARA ADMINISTRAR UMA REDE DE DISTRIBUIçãO DE áGUA. Um método computadorizado para monitorar uma rede de distribuição de água, a rede de distribuição de água incluindo uma rede de tubos para entregar água a consumidores e uma pluralidade de medidores posicionados dentro dos tubos através da rede de distribuição de água. O método inclui receber dados de medidor representando parâmetros medidos pelos medidores, tais como fluxo, pressão, nível de cloro, pH e turvação da água sendo distribuídos pelos tubos. O método também inclui receber dados secundários de fontes externas aos medidores e representando condições afetando consumo de água em uma região servida pela rede de distribuição de água tais como condições meteorológicas e feriados. O medidor e dados secundários são analisados usando técnicas estatísticas para identificar eventos de rede de água incluindo eventos de vazamento e outros eventos relativos à quantidade e qualidade de água fluindo pelos tubos e operação da rede de água. Os eventos são informados a usuários por uma interface de usuario.

Description

"MÉTODO E SISTEMA COMPUTADORIZADO PARA MONITORAR UMA REDE DE DISTRIBUIÇÃO DE ÁGUA, E, MÉTODO COMPUTADORIZADO PARA ADMINISTRAR UMA REDE DE DISTRIBUIÇÃO DE ÁGUA"

NOTIFICAÇÃO DE DIREITOS AUTORAIS Uma porção da exposição deste documento de patente contém material que está sujeito à proteção de direitos autorais O dono dos direitos autorais não tem nenhuma objeção à reprodução de fac-símile por qualquer um do documento de patente da exposição de patente, como aparece nos arquivos ou registros de patente do Escritório de Patentes e Marcas, mas caso contrário reserva todos os direitos autorais sejam quais forem.

CAMPO DA INVENÇÃO O campo da invenção relaciona-se geralmente a monitorar sistemas de distribuição de recurso, tal como uma rede de distribuição de água, e detectar anomalias associadas com a rede distribuída.

FUNDAMENTO DA INVENÇÃO As Nações Unidas notam que uso de água têm crescido a mais que duas vezes a taxa de aumento de população no último século, e um número crescente de regiões está cronicamente com falta de água. Por 2025 dois terços da população mundial poderia estar sob condições de estresse de água como resultado de populações aumentadas. Água, especialmente água potável, é essencial para todos os desenvolvimentos sócio-econômicos e para manter uma população saudável. Como populações aumentam pelo globo, elas pedem uma distribuição aumentada de água limpa para uso, resultando em escassez de água aumentada.

Um método para tratar escassez de água e conservar recursos é a detecção de vazamentos e outros eventos ocorrendo em redes de utilidade de água. Alguns peritos estimam que perdas devido a vazamentos e roubo montam a 25-39% da água fluindo por redes de utilidade de água. Portanto, uma quantidade significante de água pode ser conservada simplesmente tratando a perda de água em sistemas já controlados por humanos.

Tubulações construídas antigas e pobremente, proteção de corrosão inadequada, válvulas mantidas pobremente, e dano mecânico são alguns dos fatores que contribuem para perda de água. Adicionalmente, vazamentos de água reduzem a pressão de provisão no sistema, e como resultado a utilidade deve elevar a pressão no sistema para compensar as perdas. Elevar a pressão de sistema resulta em mais água sendo bombeada e eleva o consumo de energia da utilidade de água. Realmente, redes de distribuição de água são os únicos maiores consumidores de energia em muitos países. Identificando e corrigindo vazamentos de água e outros assuntos de rede, utilidades podem conservar água para uso futuro e reduzir dramaticamente consumo de energia.

Acrescentando à dificuldade é que a maioria das redes de utilidade de água é grande e complexa, e foram construídas por crescimento gradativo, com muitos tubos em configurações arbitrárias para servir para necessidades geográficas especificas que desenvolvem com o passar do tempo. Ademais, a maioria das redes de utilidade de água falta medição de consumo de cliente precisa, freqüente, em tempo real, que poderia permitir uma conservação simples contabilidade de entrada e saída de massa. Adicionalmente, redes de utilidade de água são projetadas para entregar água a um grande número de consumidores, cujo comportamento individual é imprevisível e sujeito à mudança devido a muitos fatores. Tais fatores incluem, por exemplo, mudanças meteorológicas e eventos naturais (por exemplo, tempo quente aumenta consumo, como fazem secas), feriados e eventos sociais atípicos (por exemplo, fazendo consumidores permanecerem em casa e uso de água aumentar em redes residenciais e diminuir em bairros empresariais), e mudanças demográficas em bairros com o passar do tempo.

Métodos existentes para detecção de vazamento em redes de utilidade de água não tratam adequadamente estes problemas. Por exemplo, dispositivos de detecção de vazamento de hardware comercialmente disponíveis usados para pesquisas de campo, tais como sensores acústicos, podem ser efetivos em localizar um vazamento dentro de uma dada área, mas são caros para instalar e operar e não provêem descoberta rápida e cobertura abrangente de uma rede inteira. Sistemas de IT de água existentes, tal como a Administração de Vazamento de Água Advise™ disponível de ABB, tentam fazer algum uso de dados de medidor, mas esse uso é simplista e assim os resultados são utilidade limitada. Por exemplo, os sistemas não identificam precisamente ou informam em tempo real sobre eventos individuais específicos tais como vazamentos ou outros eventos de rede, não identificam falhas de medidor ou condições de qualidade de água adversas, faltam análise estatística precisada para entender a operação de rede rotineira precisamente, e sofrem outras deficiências. Além disso, os sistemas atualmente em uso faltam a habilidade para detectar perda de energia ou roubos de água. Uma falha fundamental da maioria das abordagens atuais é uma falta de modelagem estatística profunda dos muitos componentes não medidos de redes de água, mais notavelmente o consumo de água por clientes de serviço, que é freqüentemente modelado através de técnicas muito rudimentares, contudo tem um impacto profundo em qualquer análise da rede.

Sistemas de Controle de Supervisão e Aquisição de Dados ("SCADA") se tornaram crescentemente disponíveis em utilidades de água ao longo do mundo, colecionando dados de uma variedade de medidores dentro da rede, medindo quantidades tais como fluxo e pressão. Porém, na maioria das utilidades estes sistemas são usados por alguns operadores qualificados principalmente para necessidades operacionais em andamento; utilidades fazem pouco uso dos dados históricos acumulados nos seus sistemas para detectar automaticamente (ou de outra forma) vazamentos e outros eventos de rede anômalos. Além disso, qualquer detecção de anomalia está limitada normalmente a alertas de limite fixo de sensor único, conduzindo tanto a baixa sensibilidade ou a uma alta proporção de alertas falsos.

Operadores de rede de distribuição de água continuam adicionando até mesmo mais medidores para monitorar a atividade de sistemas de distribuição. Enquanto isto provê maiores quantidades de dados relativos à rede, e conseqüentemente maior potencial para compreender eventos dentro da rede, o volume aumentado de dados serve freqüentemente para confundir os operadores de rede ademais, e exacerbar o aspecto "agulha em um palheiro" já difícil de monitoração de rede de água. Além disso, a colocação de mais medidores não é normalmente otimizada para melhorar a utilidade de dados sendo recebidos do sistema global para propósitos de monitoração avançados. Como resultado, os volumes aumentados de dados descrevendo a atividade de rede são desorganizados e freqüentemente confusos e não permitem aos operadores de rede tomarem qualquer decisão melhor sobre o estado da rede de distribuição de água.

Como tal, existe uma necessidade por sistemas e métodos melhorados para analisar melhor dados recobrados de uma rede de distribuição de água e dados sobre a rede de utilidade e o consumo de seus recursos para facilitar administração melhorada destes recursos.

SUMÁRIO DA INVENÇÃO

Algumas ou todas das deficiências anteriores e outras na arte anterior são resolvidas por um método computadorizado para conservar água monitorando uma rede de distribuição de água, a rede de distribuição de água incluindo uma pluralidade de tubos e dispositivos de rede tais como válvulas redutoras de pressão, reservatórios, ou bombas, para entregar água a consumidores e uma pluralidade de medidores posicionados em locais dentro da rede de distribuição de água. Os medidores podem ser posicionados no interior ou exterior dos tubos, próximo aos dispositivos de rede, ou em outros locais arbitrários. Em algumas concretizações, o método inclui receber dados de medidor dos medidores, os dados representando uma pluralidade de parâmetros medidos pelos medidores, os parâmetros incluindo pelo menos fluxo da água pelos tubos. Em algumas concretizações, os dados de medidor são dados de Controle de Supervisão e Aquisição de Dados (SCADA). Em algumas concretizações, os dados de medidor são processados antes de serem analisados tal como filtrando fora ruído dos dados de medidor e os formatando para armazenamento em um banco de dados de informação de rede.

De acordo com algumas concretizações, os dados de medidor são analisados para identificar eventos de rede de água, os eventos de rede de água incluindo eventos de vazamento e eventos informativos relativos a consumo de água entregue através da rede de água e operação da rede e dos medidores. Os eventos informativos que podem ser informados incluem um aumento inesperado em padrão de consumo, uma mudança em padrão de consumo, um roubo de água, uma brecha de limite de zona, uma falha de medidor de utilidade, e um mau funcionamento de dispositivo de rede. O método de acordo com algumas concretizações pode ademais incluir receber com o passar do tempo dados de qualidade de água representando turvação, cloro e pH da água entregues através da rede e identificar eventos de rede detectando mudanças nos dados de qualidade de água com o passar do tempo em excesso de um limiar de valor estatístico, proporcional, ou constante.

.O um ou mais eventos de rede são informados a um usuário por uma interface de usuário. Em algumas concretizações, os eventos de rede de água são armazenados em um banco de dados, assim eles podem ser acessíveis a uma variedade de módulos de interface que informam os eventos de modos diferentes, incluindo por listas de evento, gráficos ou dados de tendência, e tíquetes de dificuldade ou outros alertas.

Em algumas concretizações, o método inclui receber dados secundários de uma ou mais fontes externas aos medidores, os dados secundários representando uma ou mais condições afetando consumo de água em uma região servida pela rede de distribuição de água. Os dados secundários poderiam incluir, por exemplo, dados meteorológicos representando condições de tempo na região da rede de distribuição de água, dados de calendário representando um ou mais fatores afetando consumo de água em uma dada data, dados de conserto representando um ou mais consertos executados na rede de distribuição de água, e dados estruturais representando uma estrutura da rede de distribuição de água. Como explicado ademais aqui, estes dados secundários podem ser analisados junto com os dados de medidor para prover melhores resultados mais precisos e reduzir ou eliminar falsos alarmes. Por exemplo, um aumento anômalo em fluxo de água ou consumo em uma dada região de uma rede de distribuição de água pode ser explicado por calor acima da média ou seca ou por um feriado ou outro evento natural ou humano que faz as pessoas ficarem em casa e não irem trabalhar ou caso contrário mudar o padrão de consumo típico em um local ou locais particulares.

Em algumas concretizações, dados de medidor são analisados predizendo estatisticamente dados de medidor para um primeiro medidor baseado em outros dados de medidor da rede de distribuição de água, tal como calculando uma distribuição estatística de valores prováveis para o primeiro medidor, e comparando os dados de medidor recebidos para o primeiro medidor com os dados de medidor preditos para o primeiro medidor. Por meio de ilustração, dados históricos podem indicar que os valores do primeiro medidor são tipicamente aproximadamente o dobro dos valores medidos simultaneamente por um segundo medidor; então, o primeiro medidor é predito ter uma leitura atual aproximadamente o dobro da leitura recentemente obtida do segundo medidor. Os eventos de rede podem ser identificados detectando uma anomalia se o valor de medidor recebido atual do primeiro medidor divergir do valor de medidor predito para o primeiro medidor por um desvio estatístico predefinido, para uma duração excedendo um limiar predefinido, se sua ocorrência de freqüência dentro de uma janela de tempo predefinida exceder um limiar predefinido, ou por outros meios. Detecção de anomalia estatística em valores de medidor é um modo robusto para superar as dificuldades inerentes nos muitos componentes não medidos de redes de água, mais notavelmente o consumo de água por clientes de serviço, que tem um impacto profundo em qualquer análise da rede. Estrutura estatística neste consumo, tal como uma tendência para periodicidade, se propaga ao longo da rede, conduzindo à estrutura estatística semelhante ou derivada ou em valores de medidor, permitindo uma análise da probabilidade que valores de medidor particulares eram gerados durante operação rotineira da rede (nenhuma anomalia). Além disso, o uso de detecção de anomalia estatística como descrito aqui permite o uso dos métodos e sistemas da presente invenção com redes que provêem dados de medidor que não cobrem toda a porção da rede, não são providos em uma base de tempo real, ou caso contrário são incompletos e deficientes. Assim, por exemplo, a detecção de anomalia descrita aqui é projetada para ser mais útil em redes de utilidade de água nas quais medidores só estão presentes em certas junções ou locais de rede, ou em que leituras de medidor são tomadas em residências de consumidor mensalmente ou caso contrário falham para prover informação atualizada. Realmente, como explicado acima, redes típicas de utilidade de água sofrem de um ou mais destes tipos de deficiências no dados de medidor colecionados da rede, e faltam medição de consumo de cliente precisa, freqüente, em tempo real, que poderia permitir uma conservação simples de contabilidade de entrada e saída de massa, e são projetadas para entregar água a um grande número de consumidores, cujo comportamento individual é imprevisível e sujeito à mudança devido a muitos fatores.

Em algumas concretizações, predizer estatisticamente dados de medidor para o primeiro medidor baseado em outro dados de medidor da rede de distribuição de água inclui selecionar um ou mais segundos medidores como um ou mais medidores correspondentes e correlatar dados de medidor recebidos do primeiro medidor com dados de medidor recebidos do um ou mais medidores correspondentes. O um ou mais segundos medidores podem ser selecionados correlatando dados históricos de medidor para o um ou mais segundos medidores com dados históricos de medidor para o primeiro medidor. Em algumas concretizações, o um ou mais segundos medidores podem ser medidores que cada um teve historicamente correlação íntima com os valores do primeiro medidor. Falando livremente, na operação de rede de rotina, os valores do primeiro medidor são esperados continuarem esta correlação. Por meio de ilustração, uma tal situação pode surgir quando vários medidores medem o fluxo de água consumida por vários bairros distintos com demografia semelhante, e conseqüentemente padrões de consumo semelhantes (ou proporcionais). O um ou mais segundos medidores podem ser ademais selecionados como os que estão posicionados dentro da rede de distribuição de água para serem afetados por anomalias locais afetando o primeiro medidor, do tipo que é de interesse ao operador de rede, tal como um vazamento; contudo, fazendo parte da mesma rede e área geral, os segundos medidores são afetados pelas mesmas anomalias globais, tal como consumo aumentado em um dia quente. Deste modo, uma anomalia local afetando os dados do primeiro medidor não afetará os dados dos segundos medidores e assim será mais fácil detectar por uma comparação estatística aos dados dos segundos medidores, contudo uma anomalia global não gerará um falso alerta, até mesmo se sua causa for desconhecida.

Algumas ou todas as deficiências anteriores e outras na arte anterior são resolvidas por um sistema computadorizado para monitorar uma rede de distribuição de água, o sistema tendo um banco de dados de informação de rede para armazenar dados de medidor representando uma pluralidade de parâmetros medidos pelos medidores, os parâmetros incluindo pelo menos fluxo da água pelos tubos, e dados secundários de uma ou mais fontes externas aos medidores, os dados secundários representando uma ou mais condições afetando consumo de água em uma região servida pela rede de distribuição de água. O sistema contém ademais uma máquina de análise configurada para analisar os dados de medidor e dados secundários para identificar anomalias, uma máquina de classificação de evento configurada para identificar eventos de rede de distribuição de água baseados nas anomalias, os eventos de rede de água incluindo eventos de vazamento e outros eventos relativos à quantidade ou qualidade de água fluindo pelos tubos e dispositivos de rede e operação da rede de distribuição de água, e um banco de dados de evento para armazenar dados de evento de rede de distribuição de água representando o um ou mais eventos de rede de água identificados pela máquina de classificação de evento. O sistema pode ademais incluir um conjunto de módulos de interface para recobrar dados de evento de rede de distribuição de água do banco de dados de evento e informar isto a usuários.

Em algumas concretizações, a máquina de análise inclui uma pluralidade de módulos de predição para gerar uma distribuição estatística de valores prováveis dos dados de medidor para um dado medidor, assumindo operação rotineira e nenhum evento anômalo, e uma pluralidade de módulos de detector de anomalia para comparar os dados de medidor atuais para o dado medidor à distribuição de valores prováveis para detectar anomalias nos dados de medidor.

Algumas de todas das deficiências anteriores e outras na arte anterior são resolvidas por um método computadorizado para administrar uma rede de distribuição de água, o método incluindo enviar dados de medidor para uma máquina de análise, receber da máquina de análise dados representando eventos de rede de distribuição de água, e exibir os eventos de rede de distribuição de água recebidos a um usuário em um dispositivo de exibição computadorizado. De acordo com algumas concretizações, os eventos de rede de água incluem eventos de vazamento e outros eventos relativos à quantidade ou qualidade de água fluindo pelos tubos e dispositivos de rede e operação da rede de distribuição de água. Os dados de evento de rede de distribuição de água podem ter sido identificados como resultado de análise dos dados de medidor e dados secundários, os dados secundários representando uma ou mais condições afetando consumo de água em uma região servida pela rede de distribuição de água.

DESCRIÇÃO BREVE DOS DESENHOS

A invenção é ilustrada nas figuras dos desenhos acompanhantes que são pretendidas serem exemplares e não limitantes, em que mesmas referências são pretendidas se referir a mesmas ou partes correspondentes, e em que:

Figuras 1 e 2 apresentam diagramas de bloco descrevendo sistemas para monitorar uma rede de água de acordo com concretizações da presente invenção;

Figura 3 apresenta um fluxograma ilustrando um método para monitorar uma rede de água de acordo com uma concretização da presente invenção;

Figura 4 apresenta um fluxograma ademais ilustrando um método para monitorar uma rede de água de acordo com uma concretização da presente invenção;

Figura 5 apresenta um fluxograma ilustrando um método para predizer valores medidos para um dado medidor de acordo com uma concretização da presente invenção;

Figuras 6 e 7 apresentam fluxogramas ilustrando seleção de atributo de acordo com uma concretização da presente invenção;

Figura 8 apresenta um fluxograma ilustrando um método para detectar um evento de vazamento de água; Figuras 9-11 apresentam fluxogramas ilustrando detecção de evento para tipos de evento específicos de acordo com concretizações da presente invenção; e

Figuras 12-15 apresentam tomadas de tela mostrando uma interface de usuário da web apresentando informação de evento gerada pela máquina de análise de acordo com uma concretização da presente invenção. DESCRIÇÃO DETALHADA DAS CONCRETIZAÇÕES

Na descrição seguinte, referência é feita aos desenhos acompanhantes que formam uma parte disso, e em que é mostrado por meio de ilustração de concretizações específicas nas quais a invenção pode ser praticada. E para ser entendido que outras concretizações podem ser utilizadas e mudanças estruturais podem ser feitas sem partir da extensão da presente invenção.

Figura 1 apresenta um diagrama de bloco ilustrando uma concretização de um sistema para monitorar recursos em um sistema de distribuição de água. Como mostrado na Figura 1, o sistema inclui uma Máquina de Análise de Rede de Água 100 composta de vários módulos de software e bancos de dados residindo em hardware de computador e executando as funções descritas ademais abaixo. A máquina 100 pode incluir um ou mais dispositivos de processamento executando as operações descritas abaixo em resposta a instruções executáveis. A Máquina de Análise de Rede de Agua 100 analisa dados recebidos de medidores diferentes, sensores, dispositivos de leitura, ou outros dados pertencendo a uma rede de distribuição. Alguém de habilidade no arte apreciará que a menos que o contexto específico indique explicitamente caso contrário, como usado aqui os termos "medidor" e "sensor" se referem geralmente à mesma classe de dispositivos de rede e cercam qualquer medidor, sensor, calibre, ou outro dispositivo capaz de medir parâmetros ou valores ou um estímulo, especialmente estímulos relativos a uma rede de distribuição de água. O sistema identifica anomalias e eventos baseados nesse dados e provê alertas em tempo real ou relatórios de dados off-line a usuários que podem então entrar em ação, como apropriado, para tratar qualquer fenômeno ou eventos identificados pela Máquina de Análise 100. Como descrito ademais abaixo, as anomalias e eventos identificados pela Máquina de Análise 100 incluem vazamentos, estouros, um consumo de água inesperado, medidores defeituosos, problemas de calibração de medidor, mudanças de qualidade de água, outros assuntos importantes à quantidade de água sendo entregue através da rede, maus funcionamentos em dispositivos de rede, e outros assuntos conhecidos àqueles qualificados na arte.

Como mostrado na Figura 1, os dados recebidos como entradas à Máquina de Análise de Rede de Água 100 incluem, em algumas concretizações, dados de GIS 101, Dados de Operação 102, Sistema de Distribuição de Água 103, Dados de medidor 1 103a, Dados de medidor N 103b, e Dados Externos 104.

Dados de GIS 101 são dados de um sistema de informação geográfico ("GIS") que descreve a estrutura e disposição da rede de água e posicionamento dos medidores por ela, e inclui tipos de medidor, locais de medidor, idades de medidor, descrições dos tubos de água tais como diâmetros e materiais de fabricação, partições da rede em zonas de pressão e/ou zonas de provisão, um mapa de cidade ou área, e dados evolutivos adicionais reconhecidos a alguém de habilidade na arte. Qualquer outra característica da geografia e engenharia do sistema de distribuição de água também pode ser utilizada, como também quaisquer outros dados confiados por alguém qualificado na arte. Também é notado que estes dados podem ser dados evolutivos incluindo atualizações consistentes com a evolução do próprio sistema de recurso subjacente, por exemplo quando novos tubos de água, conexões, medidores, etc., são instalados ou caso contrário modificados no sistema. Além disso, estes dados podem incluir atualizações quando o sistema de recurso subjacente é amostrado ou medido, por exemplo quando tubos existentes são inspecionados para fadiga de material ou constrição interna por depósitos sólidos acumulados.

Dados de Operação 102 incluem informação de administração de patrimônio, e pode ser qualquer informação para um digital sobre operações executadas pelo operador de rede que pode estar correlatada com leituras de medidor para determinar ou refutar uma anomalia. Por exemplo, Dados de Operação 102 podem incluir informação relativa a operações de rede de água, tais como operações de rede de água de rotina ou planejadas, abertura e fechamento de válvulas que afetam fluxo de água, operações de bomba, pesquisas acústicas, consertos ou melhorias feitas a qualquer parte da rede de água, datas e horas dos reparos/melhorias, locais dos reparos/melhorias, manutenção rotineira feita à rede, e informação de controle de acesso indicando quando e onde o pessoal técnico de rede pode estar ativo. Em uma concretização, Dados de Operação 102 são providos pelo sistema usado para administrar a rede de água.

Sistemas de distribuição de água monitorados produzem vastas quantidades de dados dependentes de tempo tais como, mas não limitado a, indicadores hidráulicos tais como fluxo, pressão, e nível de reservatório, e indicadores de qualidade tais como cloro, turvação, pH, e outros. Estes dados podem ser produzidos por medidores distribuídos ao longo da rede, e podem ser representados pelo Sistema de Distribuição de Água 103. Além disso, os medidores distribuídos ao longo da rede podem estar em locais arbitrários, ou locais que só provêem uma representação parcial da rede inteira. Dados de Medidor 1 103a e Dados de Medidor N 103b representam dados produzidos pelos vários sensores e medidores em Sistema de Distribuição de Água 103. Um exemplo de um sistema usado para colecionar dados de rede como aquele representado por Dados de Rede 103a e Dados de Medidor 103b é um sistema de SCADA. Dados de SCADA podem incluir dados de medidor dependentes de tempo contínuos, tais como pressão da água, taxa de fluxo da água, turvação da água, níveis de cloro na água, pH da água, e níveis de água de reservatório. Aqueles de habilidade na arte estão familiarizados com sistemas de dados de SCADA e podem apreciar que o termo representa uma abstração de coleta de dados de um processo industrial, neste caso uma rede de distribuição.

Dados Externos 104 incluem informação adicional pertinente a consumo de água e condições de rede, mas não estritamente dentro das categorias anteriores, tais como boletins meteorológicos, feriados ou outros eventos de calendário que afetam consumo de água e comportamento de rede dentro de dadas porções da rede, ou qualquer outro evento pela própria utilidade ou seus clientes que pode impactar a função da rede de água.

A Máquina de Análise de Rede de Agua 100 analisa os vários fluxos de dados de entrada e retorna saída categorizada e formulada como dados de evento conforme operações de processamento descritas em detalhe adicional abaixo. Máquina Análise de Rede de Água 100 armazena dados em Banco de Dados 106, e dados de Banco de Dados 106 são recobrados por um ou mais sistemas de interface, tal como Interface de Rastreamento de Evento .108, Interface de Alerta 109, Interface de Relatórios 110, Interface de Sistema de Proprietário 111, e Outras Interfaces 112. Máquina de Análise de Água .100 também pode acessar dados previamente armazenados de Banco de Dados 106, para prover continuidade na informação de eventos, por exemplo atualizar um evento previamente detectado ainda está em andamento, em lugar de detectá-lo como um evento separado adicional. Tipos diferentes de sistemas de interface são usados para prover informação sobre eventos para usuários ou sistemas externos de modos indiferentes. Por exemplo, a Interface de Rastreamento de Evento 108 habilita os usuários navegarem por todos os eventos detectados na rede, enquanto a Interface de Alerta 109 envia alertas para usuários (por exemplo por um e-mail, SMS ou mensagem de voz) ou sistemas externos que foram determinados por regra ou política requerer mais atenção imediata. As interfaces 108-112 podem ser acessadas por vários dispositivos computadorizados, tais como computadores de mesa e laptops, telefones celulares, dispositivos de 'blackberry', telefones inteligentes, radiolocalizadores e outros dispositivos móveis programados para receber páginas, tíquetes de dificuldade e outros tipos de alertas. As interfaces 108- 112 podem ser acessadas pelos dispositivos computadorizados pedindo-os de servidores conectados através de qualquer rede satisfatória, tal como mas não limitada à Internet, ou pode ser transferida para tais dispositivos para visão por usuários ou entrada em outros sistemas tal como sistemas de tíquete de dificuldade. Saídas de Máquina de Análise de Rede de Água 100 podem ser armazenadas em Banco de Dados 106, em um arquivo de registro eletrônico, ou impressas em papel.

Embora ilustrado como um único sistema, em várias concretizações, o sistema ilustrado pode ser integrado e/ou distribuído por dispositivos de múltiplos hardware e pode ser distribuído logicamente, fisicamente ou geograficamente. Máquina de Análise de Rede de Água 106 pode ser qualquer dispositivo de processamento físico adequado executando operações de processamento como descrito aqui, em resposta a instruções executáveis. Máquina Análise de Rede de Agua 100 também pode incluir que qualquer tipo adequado de dispositivo de armazenamento operativo para armazenar eletronicamente dados. Figura 2 apresenta um diagrama de bloco descrevendo detalhes adicionais de um sistema de monitoração de rede de água de acordo com certas concretizações. Em uma concretização, elementos 203-207 formam a Máquina de Análise de Rede de Água 100 da Figura 1. Figura 2 inclui Rede de Água 200, Rede de Água 201, Dados 202, Banco de Dados de Informação de Rede 203, Máquina de Preparação de Dados 204, Preditores 205, Detectores de Anomalia 206, Máquina de Decisão e Classificação de Evento 207, Banco de Dados 208, e Interfaces de Saída 209, incluindo Interface de Rastreamento de Evento 210, Interface de Alerta 211, Interface de Relatório 212, Interface de Sistema de Proprietário 213, e Outras Interfaces 214.

Sistemas de distribuição de água, representados por elementos .200 e 201, são um ou mais sistemas de distribuição de água conectados, ou sistemas de distribuição de água localizados em áreas diferentes com poucas ou nenhuma conexão entre eles. Em uma concretização, elementos 200 e 201 podem ser qualquer rede de distribuição de recurso adequada, tal como uma rede de distribuição de água municipal, rural, ou atacadista, rede de distribuição de líquido em uma fábrica ou outro grande edifício, ou embarcação naval, ou qualquer rede de coleção de recurso adequada tal como um sistema de esgoto. Alguém de habilidade na arte apreciará que elementos .200 e 201 podem ser qualquer sistema de distribuição ou coleção de água. Rede de Agua 200 e Rede de Agua 201 enviam dados dependentes de tempo representativos da rede, tais como fluxo de água, pressão, turvação, nível de reservatório, nível de cloro, e nível de pH. Por exemplo, a rede pode obter informação usando um sistema de SCADA. Dados de Rede de Água 200 ou Rede de Agua 201 pode informar dados de medidores específicos, ou coleções de medidores, alguns dos quais podem estar relacionados. Por exemplo, medidores podem ser agrupados geograficamente por zona ou Área Medida de Distrito (DMA), como alguém qualificado na arte apreciará. Os dados podem ser enviados diretamente dos medidores ou coleções de medidores na rede, ou os dados podem vir de um Banco de Dados de Interface de Rede 203; adicionalmente, os dados poderiam ser enriquecidos por Máquina de Preparação de Dados 204 para, por exemplo, adicionar ou calcular novos tipos de dados tais como dados de consumo diurnos e noturnos. Para conveniência, o termo "dados de medidor" será usado nesta especificação para se referir aos dados atuais de um único medidor, ou uma combinação significante predefinida de leituras de múltiplos medidores ou de múltiplas leituras de um ou mais medidores recebidas com o passar do tempo, tal como a soma total de fluxo em andamento para um DMA, ou qualquer cálculo predefinido semelhante gerando um conjunto significante de dados dependentes de tempo descrevendo algum aspecto da rede. Alguém qualificado na arte identificará prontamente tais combinações significantes, baseado na disposição de rede e nos locais de medidores individuais. Dados 202 representam outros dados incluindo informação de administração de patrimônio, que pode ser qualquer informação em um formato digital que pode ser correlatada com leituras de medidor para determinar ou refutar uma anomalia. Por exemplo, isto pode incluir informação relativa a operações de rede de água, tais como operações de rede de água de rotina ou planejadas, abertura e fechamento de válvulas que afetam fluxo de água, pesquisas acústicas, consertos e melhorias feitas a qualquer parte da rede de água, datas e horas dos reparos/melhorias, locais dos reparos/melhorias, manutenção rotineira feita à rede, e informação de controle de acesso indicando quando e onde na rede pessoal técnico pode estar ativo. Adicionalmente, Dados 202 incluem informação adicional pertinente a consumo de água e condições de rede, tais como boletins meteorológicos, feriados ou outros eventos de calendário que afetam consumo de água e comportamento de rede dentro de dadas porções da rede, ou qualquer outro evento pela própria utilidade ou seus clientes que pode impactar a função da rede de água.

Banco de Dados de Informação de Rede 203 agrega os dados brutos colecionados dos medidores em Redes de Água 200 e 201, e Dados 202. Dados de Banco de Dados de Informação de Rede 203 são enviados para Máquina de Preparação de Dados 204. Máquina de Preparação de Dados 204 organiza e formata dados recebidos a serem processados ademais. Como conhecido àqueles de habilidade na arte, formatos de dados usados por sistemas de distribuição de água diferentes podem diferir entre si. Por exemplo, a cidade de Londres pode colecionar e armazenar dados de rede em um formato completamente diferente da Cidade de Nova Iorque. Adicionalmente, Máquina de Preparação de Dados 204 prepara dados para análise removendo dados não refletindo o desempenho atual da rede ou refletindo um fenômeno transiente que projetistas de sistemas ou administradores de rede decidiram não tratar; métodos geralmente conhecidos na arte podem ser aplicados para "alisar" os dados colecionados da rede. Alguns destes métodos são LOWESS e limpeza heurística como aplicado para dia dados específicos sendo recebidos de uma dada rede de água. Máquina de Preparação de Dados 204 extrai os elementos de dados dos dados de rede e os formata em um formato consistente. Entre informação filtrada pode estar ruído associado com as transmissões de dados de aspectos do recurso, tal como por exemplo transmissão de dados ruidosa de um medidor, ou erros associados com as medições, transmissões ou coleção de dados. Máquina de Preparação de Dados 204 também pode produzir todos os dados recebidos de

Rede de Agua 200 e 201, depois que foram formatados, mas com menos ou nenhuma filtragem ou alisamento, para permitir ao sistema analisar dados que poderiam caso contrário ser descartados se uma das técnicas de alisamento fosse aplicada primeiro. Máquina de Preparação de Dados 204 envia dados pré-processados para Preditores 205 e Detectores de Anomalia 206. Alguém de habilidade na arte apreciará que elementos 203-214 podem ser contidos dentro ou residir no mesmo dispositivo, ou distribuídos entre múltiplos dispositivos.

Em uma concretização, Preditores 205 contêm número N de preditores individuais usando várias técnicas. Como descrito ademais abaixo, os Preditores 205 analisam conjuntos de dados e provêem predições de distribuições estatísticas dos valores de medidor atual esperados assumindo que nenhum evento anômalo está ocorrendo. Como conhecido geralmente na arte, preditores podem ser projetados usando uma estrutura de aprendizado de máquina para analisar estatisticamente os dados. Exemplos da estrutura de aprendizado de máquina são discutidos em Ethem Alpaydin, "Introduction to Machine Learning (Adaptive 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, por este meio incorporado por referência em sua totalidade. Descrições mais detalhadas da operação de algum preditores específicos são achadas nas Figuras 5-6 e nas descrições acompanhantes.

Detectores de Anomalia 206, que podem incluir número M de detectores individuais, recebem dados de predição estatística de Preditores 205 e dados pré-processados de Máquina de Preparação de Dados 204. Como discutido na Figura 5, o conjunto de dados recebidos dos Preditores 205 incluem uma distribuição com o valor provável, variância, e qualquer outro descritor estatístico dos valores. Alguém de habilidade na arte reconhecerá que o conjunto de dados pode conter múltiplos valores prováveis e reais para o medidor sendo analisado. Detectores de Anomalia 206 incluem detectores de anomalia para testar a probabilidade de nenhuma anomalia pelo medidor e para testar a probabilidade de nenhuma anomalia para o medidor e para testar a probabilidade de hipóteses alternativas tais como tipos de evento específicos. Detectores de Anomalia 206 enviam anomalias para Máquina de Decisão e Classificação de Evento 207. Algumas dessas anomalias representam eventos dentro e próprios, e algumas representam partes de eventos tal como o começo de um evento, o fim de um evento, mudança significativa em um evento, pico de um evento, e similar.

Detectores de Anomalia 206 são operativos para analisar a significação de qualquer desvio do valor esperado enviado dos Preditores e o valor real recobrado da rede. Para cada conjunto de dados, cada detector de anomalia determina, analisando a significação de desvios, a probabilidade estatística que nenhuma anomalia pertinente ocorreu dadas as leituras de medidor durante um dado período de tempo. Os Detectores de Anomalia 206 analisam a significação de desvios com o passar do tempo, por exemplo através de minutos, horas, dias ou mais tempo, desde que, por exemplo, a ocorrência continuada ou freqüente das desvios aumenta a significação de tais desvios. Como alguém de habilidade ordinária na arte reconhecerá, um projetista de sistema projetaria ou ajustaria os Detectores de Anomalia 206 para analisar desvios através de um período de tempo baseado, entre outras coisas, na sensibilidade desejada para pequenos eventos de escala de tempo, eventos recentemente começados, que são normalmente detectáveis quando eles têm magnitudes grandes ao invés de eventos de magnitude pequenos que requerem desvios contínuas através de um período de tempo mais longo para detecção. Assim, por exemplo, um pequeno desvio que só ocorre uma vez ou por um período de tempo curto tal como um minuto não seria detectado como uma anomalia, enquanto a mesma desvio pequena ocorrendo por um período de tempo estendido ou freqüentemente dentro desse período seria identificado como significante estatisticamente pelos Detectores de Anomalia 206 e detectado como anomalia.

Relativo a analisar a significação de desvios, por exemplo, uma leitura de medidor, quando comparada aos dados estatísticos históricos, pode ser significante devido aos dados estatísticos históricos. Por exemplo, uma diferença de três desvios-padrão ou um valor no topo percentual pode ser uma desvio significante. Em outras concretizações, a desvio estatística é medida pela distribuição de desvios como uma função de parâmetros. Um tal parâmetro pode ser a hora do dia, significando que a significação da desvio pode depender da distribuição de desvios que pode variar de acordo com hora do dia. Outros tais parâmetros podem incluir medições meteorológicas tais como temperatura ou umidade, boletins meteorológicos, feriados, ou eventos esportivos que podem mudar características de rede naquele dia ou hora do dia. Adicionalmente, o limiar significante de desvio de valores pode ser mudado pelo nível de confiança estatística desejada por projetista de sistema, usuário ou gerente de utilidade de água. Em várias concretizações, o limiar é: (1) um nível de confiança estatístico, computado baseado na distribuição de desvios da correlação nos dados históricos, tal como um múltiplo especificado do desvio-padrão, ou (2) uma constante, acima da qual o sistema detecta anomalia. Em algumas concretizações, a relação do valor real para o valor predito é analisada, em lugar de a diferença entre os dois. É para ser entendido que o termo "diferença" é usado para se referir igualmente, no caso de tais concretizações, a esta relação. Em uma concretização, um detector de anomalia acha uma anomalia quando existe uma grande desvio estaticamente consistente de valores esperados através de um dado período. Estatisticamente grande significa um salto relativo estatisticamente significante (tal como N desvios- padrão ou K vezes a gama inter-quartil, ou outras padronizações que levam em conta a distribuição atual dos dados, dependendo de implementações particulares). Além disso, ao comparar leituras "momentâneas" aos valores esperados, usando o desvio-padrão global (ou outro descritor estatístico) de diferenças de valores esperados pode produzir um alto número de falsos positivos, porque a comparação pode, por exemplo, misturar junto horas do dia de alta variância com horas do dia de baixa variância. Portanto, para reduzir este erro, o sistema compara uma leitura X(t) ao valor predito P(t) dividindo X(t)-P(t), por exemplo, no desvio-padrão de tais diferenças nessa hora do dia aproximada, nesse dia da semana. A magnitude do salto relativo e o comprimento do período são parâmetros do método, que habilita instanciações particulares para focalizar alternativamente em eventos mais curtos ou menores.

Em outra concretização, um detector de anomalia computa a área debaixo da curva (AUC) da diferença entre valores atuais e preditos através de períodos fixos particulares (ou, alternativamente, do valor absoluto dessa diferença - que afeta se ou não valores baixos podem cancelar com valores altos subseqüentes). Esta computação pode ser executada deste modo, por exemplo, todo quarto de um dia. O AUC não é em si mesmo uma quantidade estatística, mas desde que estes são períodos fixos, a distribuição pode ser medida empiricamente: se só 5% de valores de AUC do medidor X entre meia-noite e 6:00 horas em um dia de semana era maior que X0, então achando um tal valor de AUC é aproximadamente "5% provável". A duração dos períodos fixos (e a quais períodos eles são comparados) são parâmetros do método, que habilita instanciações particulares para focalizar alternativamente em eventos mais curtos ou menores.

Máquina de Decisão e Classificação de Evento 207 é operativa para comparar uma análise estatística dos M Detectores de Anomalia 206 para determinar a probabilidade estatística global da hipótese de não anomalia dadas leituras de medidor recentes. A Máquina 207 aumentaria a probabilidade estatística de um evento baseado na detecção de múltiplas anomalias, dos mesmos ou medidores diferentes e ao mesmo tempo ou através de um dado período de tempo, que tudo indica consistentemente a ocorrência do evento. Por exemplo, uma anomalia pode representar o começo de um evento e outra anomalia pode representar uma mudança no evento ou o fim do evento, e a Máquina de Classificação 207 reconhece essas anomalias como sendo relacionadas a um único evento. Como outro exemplo, duas anomalias de medidores diferentes relacionadas a fluxo aumentado, em um tempo semelhante e de locais relacionados, ambas indicariam o mesmo evento. Em uma concretização, heurística é usada para determinar a probabilidade estatística global de uma leitura de medidor, baseado ou uma combinação da probabilidade estatística de uma leitura dos dados estatísticos temporais, e a probabilidade estatística de uma leitura dos dados estatísticos espaciais. Por exemplo, se a comparação de dados estatísticos históricos indicar que a leitura atual do medidor é só 15% provável ser tão alta, mas a comparação de dados estatísticos espaciais indicar que a leitura atual do medidor é 95% provável ser tão alta, então a probabilidade de leitura global pode ser 75% provável ser tão alta. Veja, Por exemplo, Koziol, James e Tuckwell, Henry, "A Bayesian Method for Combining Statistical Tests", Diário de Planejamento Estatístico e Dedução 1999: 78(1 - 2), 317-323, aqui incorporados por referência.

Exemplos de eventos detectados pela máquina de análise são um vazamento de água, um estouro, um medidor defeituoso, um roubo de água, uma falha de comunicação, um assunto de qualidade de água, um aumento inesperado em consumo, uma mudança em padrão de consumo, maus funcionamentos de rede tais como níveis ou pressões anormais de reservatório, e outros. Detalhe adicional relativo a eventos pode ser incluído tal como a hora de começo do evento, a hora de fim do evento, uma magnitude do evento, uma perda de água total associada com o evento, por meio de exemplo.

Máquina de Decisão e Classificação de Evento 207 também gera dados adicionais considerando cada evento, tal como hora de começo, hora de fim, magnitude do evento, uma magnitude acumulada do evento tal como a água total perdida desde que o vazamento começou, tipo, estado, e unidades físicas do evento, tais como unidades de pressão, pH, ou concentração de cloro. Magnitude do evento é, em algumas concretizações, um valor representando o tamanho ou proporção do evento, tal como um cálculo de fluxo extra através de condições normais, erro de cálculo de medidor, ou mudança de cloro. Esta informação é armazenada em Banco de Dados 208 para ser enviada ademais para Interfaces 209. Certas saídas de anomalias são mapeadas a certos campos de eventos armazenados em Banco de Dados 208. Exemplos de campos associados com eventos são: tipo de evento (como determinado pela Máquina de Decisão e Classificação de Evento 207), hora de começo, hora de fim, magnitude e unidades físicas do tipo de evento.

Alguém qualificado na arte apreciará que usando múltiplos preditores e detectores de anomalia, comparando probabilidades estatísticas dos M Detectores de Anomalia 206 pode resultar tanto em uma confiança aumentada que um evento detectado é uma anomalia, ou pode resultar em uma confiança diminuída que um evento detectado é uma anomalia. Em uma concretização, a Máquina de Decisão e Classificação de Evento 207 pode ponderar os eventos ou partes de evento enviadas de cada M Detectores de Anomalia igualmente. Em outra concretização, a Máquina Decisão e Classificação de Evento 207 pode nomear pesos aos eventos ou partes de evento enviadas de cada M Detectores de Anomalia baseado em uma configuração predefinida.

Banco de Dados 208 recebe informação de Máquina de Decisão e Classificação de Evento 207 para armazenamento em Banco de Dados 208 e para recuperação de Banco de Dados 208 através de Interfaces de Saída 209.

Interface de Rastreamento de Evento 210 provê uma lista de eventos a usuários do sistema. Usuários podem ver eventos individuais e seus dados associados selecionando um evento listado. Eventos enviados para Interface de Rastreamento de Evento 210 podem ser filtrados pelo usuário do sistema. Por exemplo, um usuário atarefado só com reparar vazamentos pode ver só eventos de vazamento, enquanto uma administrador do sistema pode ver todo tipo de evento e os dados de evento ou uma visão agregada de eventos. Usuários diferentes vêem tipos diferentes de eventos, e as necessidades ou responsabilidades de um usuário podem ditar quais eventos que o usuário vê. Por exemplo, um gerente de vazamento pode eleger ver só eventos de vazamento de alta confiança, ou só vazamentos com magnitude acima de algum limiar fixo. Em outro exemplo, usuários atarefados com monitorar um bairro vêem eventos associados com dados de medidor localizados nesse bairro. Em outro exemplo, gerentes da Rede de Água 201 vêem todos os eventos associados com Rede de Água 201, enquanto os administradores de ambas as Redes de Água 200 e 201 vêem todos os eventos relacionados a ambas as redes. Alguém de habilidade na arte reconhecerá que interface de usuário baseada em papel padrão pode ser usada, controle de acesso, e métodos de administração de usuário, que podem ser administradas por administradores de sistema, podem ser usados para prover esta granularidade de acesso a dados e relatórios de evento.

Dados de evento representados na Interface de Rastreamento de Evento 210 podem incluir a hora de começo de evento, tipo, local, magnitude e estado. Adicionalmente, um usuário selecionando o evento pode ser ademais apresentado com informação mais detalhada tais como mapas, gráficos, comentários postados por usuários relacionados ao evento selecionado, e anotações para eventos selecionados, mapas, gráficos e similar feitos pela máquina ou usuários, como explicado abaixo. Como um exemplo mais detalhado, usuários de Interface de Rastreamento de Evento podem anotar eventos, ou incluir 'hiperlinks' a outros eventos ou objetos de interface de usuário. As anotações são comunicadas da Interface de Rastreamento de Evento como, por exemplo, campos de forma de HTML comunicados através da web e armazenados em Banco de Dados 208 no registro de evento associado para ser visto por outros usuários do sistema. Usuários também podem nomear propriedade ou responsabilidade de um evento ou de tarefas relacionadas ao evento para outros usuários do sistema. Por exemplo, um analista de vazamento pode nomear um vazamento suspeito particular ao engenheiro de água de uma zona adjacente, para examinar se manutenção recente poderia explicar uma anomalia de fluxo, ou para um gerente de sala de controle recomendar ou pedir uma pesquisa e conserto. A informação de evento detalhada apresentada a um usuário inclui dados que ademais ajudarão o usuário a tomar uma decisão informada sobre o evento e atuar nisso por conseguinte. Por exemplo, se o sistema detectar um vazamento e enviar um evento de vazamento para 210, o sistema provê os dados de evento do registro de evento e a visualização dos dados por mapas, gráficos e similar para mostrar, por exemplo, uma comparação dos valores reais presentes contra valores preditos ou passados. Por exemplo, uma visualização dos dados de evento pode estar na forma de um gráfico mostrando taxa de fluxo com o passar do tempo e uma porção realçada do aumento em taxa de fluxo indicativo de um vazamento, para ajudar o usuário a focalizar em aspectos importantes do evento. Tomadas de tela de amostra para a Interface de Rastreamento de Evento 210 são mostradas nas Figuras 11-15.

Interface de alerta 211 opera, de acordo com regras ou políticas predefinidas, para identificar certos eventos que precisam ser transferidos para usuários específicos pelos dispositivos computadorizados designados pelos usuários. Por exemplo, um usuário pode especificar, por regras ou políticas, que certos eventos de uma magnitude especificada sejam enviados em mensagens de e-mail dirigidas ao usuário enquanto outros eventos de tipos mais urgentes ou sensíveis a tempo ou de magnitudes especificadas maiores sejam transferidos para seu telefone móvel por texto, radiolocalização, ou similar. Os alertas gerados pela Interface de Alerta 211 contêm certos dados especificados sobre o alerta para ajudar o usuário a tomar uma decisão informada sobre o evento. O usuário pode configurar a Interface de Alerta 211 a quanto detalhe incluir nas próprias mensagens e quantos dados adicionais fazer disponíveis para o usuário recobrar por exemplo por uma ligação a um item na Interface de Rastreamento de Evento 210.

A Interface de Relatório 212 é um sistema de informação que recobra dados de evento do Banco de Dados 208 e gera vários relatórios, tabelas, quadros, gráficos e similar para ilustrar eventos ou agregações de eventos. Como será entendido por alguém de habilidade ordinária na arte, a Interface de Relatório 212 permite a usuários agregarem eventos e dados de evento por quaisquer campos ou parâmetros desejados, tais como geográfico, tempo, tipo de evento, e similar. Relatórios gerados na Interface de Relatório .212permitem a usuários tais como gerentes de rede de água planejar melhor consertos futuros ou melhorias a sua rede, a colocação de medidores, ou outras decisões relacionadas a considerações operacionais, projeto, inventário e outras.

Interface de Sistema de Proprietário 213 é um sistema que se conecta com outro programa de software usado pelos operadores do sistema de distribuição de água. Por exemplo, Interface de Sistema de Proprietário .213recobra dados de evento do Banco de Dados 208 e introduz tudo ou uma parte especificada disso em um sistema de tíquete de dificuldade para informar pessoal de manutenção de vazamentos ou outros eventos. Um exemplo de software de tíquete de dificuldade é Track-it® de Numara®. Como outro exemplo, os dados de evento podem ser enviados a um sistema de fluxo de trabalho ou sistema de administração de patrimônio (tal como o sistema de Máximo™ disponível de IBM Corp.), de forma que o evento possa ser atuado mais prontamente. Dados de evento, para informação de evento a usuários, é bem categorizado e pode ser adaptado para uso por qualquer interface padrão de indústria. Um exemplo de uma interface de sistema de fluxo de trabalho é a Bizflow® de Handysoft.

Ademais para quaisquer das concretizações previamente descritas, elementos 203 - 209 podem residir em um servidor ou conjunto de servidores tal como um servidor da web e podem utilizar um modelo de provedor de serviço de aplicativo ("ASP") para prover os usuários de Interfaces 209 com acesso a alertas e relatórios por uma interface da web.

Figura 3 apresenta um fluxograma ilustrando um método para monitorar uma rede de água de acordo com concretizações da presente invenção. Na etapa 301, o sistema recebe dados de ou sobre a rede de água, incluindo dados de Rede (por exemplo dados de SCADA), dados de GIS, dados de operação, e dados de evento externos do sistema de distribuição de água e outras fontes. O sistema é operativo para receber outros tipos de dados das mesmas ou outras fontes, e pode ser modificado para processar tais dados com a mesma abordagem analítica. Etapa 301 pode ser executada, em uma concretização, por elemento 100 na Figura 1, ou mais especificamente por elemento 203 na Figura 2. A seguir na etapa 302, o sistema analisa os dados recebidos usando modelos estatísticos e outros algoritmos descritos aqui. Etapa 302 pode ser executada, em uma concretização, por elemento 100 na Figura 1, ou mais especificamente qualquer combinação de elementos 204- .208 na Figura 2. Finalmente, na etapa 303, o sistema gera e exibe saída incluindo eventos, alertas, relatórios e gráficos. Etapa 303 pode ser executada, em uma concretização, por elementos 106-112 na Figura 1, ou mais especificamente por elementos 210 - 214 na Figura 2.

Figura 4 apresenta um fluxograma ilustrando em detalhe adicional um método para monitorar uma rede de água de acordo com concretizações da presente invenção. Na etapa 401, o sistema recebe dados da rede de água sob análise, os dados incluindo identificação e locais geográficos dos medidores na rede. A seguir na etapa 402, o sistema seleciona pelo menos um medidor a ser analisado. A seguir, na etapa 403, o sistema prediz uma distribuição provável de valores baseado nos dados recebidos na etapa 401. Concretizações para predizer uma distribuição provável de valores são discutidas com respeito à Figura 5. A seguir, na etapa 404, o sistema determina se existe um desvio estatisticamente significante de valores depois de comparar os valores preditos aos valores reais. Concretizações para determinar a significação de desvios são discutidas com respeito à Figura 2. Se não houver nenhuma desvio de valores, ou o desvio for insignificante, o sistema procede à etapa 402 e seleciona outro objetivo a ser analisado. Se, porém, o sistema determinar que o desvio de valores é significante, o sistema procede à etapa 405 e detecta uma anomalia. A seguir, na etapa 406, o sistema classifica o evento ou partes de evento. A seguir, na etapa 406a, o sistema determina se o evento ou evento relacionado existe no banco de dados. Se o evento ou evento relacionado não existir no banco de dados, o sistema procede à etapa 406b e cria um evento no banco de dados. Porém, se o evento ou um evento relacionado existir no banco de dados, o sistema atualiza o evento previamente armazenado no banco de dados na etapa 406c. Para determinar se o evento detectado existe no banco de dados, o sistema compara o evento detectado a eventos ativos que foram armazenados previamente no banco de dados. Um evento ativo pode ser um evento que ainda está em andamento, tal como um vazamento que foi detectado previamente, mas não foi ainda consertado. Em uma concretização, para determinar eventos que ainda estão ativos, o sistema determina se um evento, tal como um vazamento, terminou. O sistema determina se um evento detectado relaciona-se a um evento previamente armazenado olhando para a semelhança de tipos de evento, a hora de começo do evento detectado e o evento previamente armazenado, que o evento previamente armazenado não terminou, o local do evento detectado e o evento previamente armazenado, ou qualquer campo de dados que pode relacionar os dois ou mais eventos como detecções parciais ou alternativas do mesmo evento de mundo físico real. Em uma concretização, quando o sistema atualiza o evento na etapa 406c, o registro de evento permanece no banco de dados como o mesmo evento, de modo que usuários que monitoram o evento previamente armazenado observarão o evento detectado e seu impacto no estado do evento previamente armazenado. A seguir, na etapa 407, o sistema provê o evento e dados associados a uma interface ou outro sistema capaz de relatar ou armazenar os dados. Em uma concretização, os dados associados providos com o evento são dados associados com detectar o evento. Por exemplo, se o sistema detectar e classificar um vazamento, os dados associados providos a uma interface de usuário podem ser um mapa mostrando o local do vazamento, como também gráficos mostrando a diferença em taxa de fluxo com o passar do tempo que incitaram o sistema para emitir o evento.

Na etapa 408, o sistema seleciona o próximo objetivo para monitorar, e o sistema continua detectando anomalias para outros medidores na rede.

Figura 5 apresenta um fluxograma ilustrando um método para predição de valores na etapa 403 da Figura 4. O sistema na Figura 5 executa uma predição primeiro selecionando atributos na etapa 501. Atributos são, em geral, coleções de dados, tais como os dados históricos de um dado medidor. Dados históricos de medidor podem incluir uma leitura de medidor e a data e a hora correspondente para essa leitura de medidor. Em uma concretização, os atributos selecionados são dados históricos de medidor para um medidor correspondente, ou medidores, baseado em uma correlação íntima dos dados históricos do medidor a ser analisado com os dados históricos do medidor correspondente ou medidores selecionados. Figura 6 discute uma concretização de determinar medidores correspondentes baseado em uma correlação íntima com os dados históricos do medidor a ser analisado.

A seguir na etapa 502, o sistema pode determinar a combinação de melhor ajuste dos atributos selecionados de acordo com uma métrica de erro, por exemplo usando regressão linear e a métrica de erro de raiz quadrada média (RMSE). A combinação de melhor ajuste produz uma função dos atributos selecionados que aproxima o conjunto de dados a serem preditos.

A seguir na etapa 503, o sistema prediz a distribuição de valor provável dos atributos selecionados aplicando a função obtida na etapa 502 com dados dos atributos selecionados. O conjunto de dados resultante inclui uma distribuição de valor provável para o medidor. A seguir, o conjunto de dados resultante procede do Preditor em elemento 205 para um Detector de Anomalia correspondente em elemento 206 da Figura 2.

Geralmente, uma predição pode ser gerada selecionando vários atributos tais como conjuntos de dados de medidor e combiná-los para produzir uma aproximação íntima do conjunto de dados ao qual uma predição está sendo gerada. Em uma concretização, "seleção de atributo independente", seleção de atributo procede selecionando os N conjuntos de dados que cada, individualmente, tem o melhor ajuste com o conjunto de dados sob análise. Por meio de exemplo, se a métrica de erro usada for a raiz de erro quadrado médio (RMSE), e os atributos forem combinados exatamente, então os conjuntos de dados selecionados serão os conjuntos de dados que cada, individualmente, melhor aproxima o conjunto de dados sendo analisado, em termos do RMSE, sob a transformação mais bem ajustada. Para este fim, o sistema acha os melhores parâmetros de melhor ajuste para cada conjunto de dados individual (com respeito a aproximar o conjunto de dados sob análise), e registra o erro de aproximação alcançado por cada conjunto de dados com parâmetros ótimos, o sistema seleciona o conjunto de dados com erros mais baixos (melhor ajuste). Como alguém de habilidade na arte apreciará, achar os parâmetros de melhor ajuste pode ser realizado por métodos bem conhecidos, tal como regressão linear.

Em outra concretização, "seleção de atributo exaustiva", seleção de atributo procede selecionando os N conjuntos de dados que minimizam o erro de predição explorando todas as possíveis N tuplos de conjuntos de dados disponíveis para predição. Para cada N tuplo, o sistema acha os parâmetros de melhores ajuste (para aproximar o conjunto de dados sob análise, com respeito a uma métrica de erro específica tal como RMSE), registra o erro de aproximação alcançado, e seleciona o N tuplo com erro mais baixo (melhor ajuste).

Em uma concretização, "seleção de atributo incrementai", seleção de atributo procede selecionando os N conjuntos de dados um de cada vez, tal que cada conjunto de dados adicional proveja a maior redução em erro de aproximação, ao gerar a combinação de melhor ajuste de conjuntos de dados já selecionados com o novo conjunto de dados. Na etapa K+l, quando K conjuntos de dados já foram selecionados (Κ < Ν), o sistema determina o K+l conjunto de dados para adicionar a eles achando os parâmetros de melhor ajuste e registrando o erro de aproximação para todas as coleções de K+l conjuntos de dados incluídos dos K conjuntos de dados já selecionados e um dos outros conjuntos de dados disponíveis para predição; o sistema seleciona o conjunto de dados adicional que alcança o erro mais baixo (melhor ajuste).

Figura 7 provê um fluxograma para uma concretização da "seleção de atributo incrementai". Na etapa 701, o sistema seleciona o primeiro conjunto de dados, ou dados de medidor, para adicionar aos atributos selecionados. O primeiro conjunto de dados pode ser selecionado baseado em ter uma correlação alta aos dados de medidor sendo analisados. A seguir na etapa 702, o sistema determina se outra coleção de dados deveria ser adicionada ao conjunto de dados determinando se Ν, o número de conjuntos de dados na combinação, é menos que Κ, o número predefinido de conjuntos de dados que o projetista permitiu ser combinado. Se não, o sistema procede à etapa 708 e executa a análise. Se outra coleção de dados for para ser adicionada ao conjunto de dados, o sistema procede à etapa 703 e seleciona uma segunda coleção de dados para adicionar ao conjunto de dados. A seguir na etapa 704, o sistema acha os parâmetros de melhor ajuste para todas as coleções de dados no conjunto de dados, e então registra os erros de aproximação para todas as coleções de dados no conjunto de dados na etapa 705. A seguir na etapa 706, o sistema determina se o conjunto de dados adicionado alcança o erro mais baixo determinando o melhor ajuste. Se o conjunto de dados adicionado não alcançar o erro mais baixo, o sistema procede à etapa 702. Porém, se a segunda coleção de dados alcançou o erro mais baixo, o sistema procede à etapa 707 e adiciona a segunda coleção de dados ao conjunto de dados. O sistema então procede à etapa 702.

Seguindo cada uma destas concretizações de seleção de atributo, seleção de parâmetro então procede por quaisquer dos métodos familiares a alguém de habilidade na arte, tal como regressão linear, para gerar a combinação de melhor ajuste de todos os conjuntos de dados selecionados, em termos da métrica de erro sendo usada (por exemplo, o RMSE). Em uma concretização, várias regressões diferentes ou métodos de regressão são empregados em paralelo, e o resultado é a combinação mediana ou média ou semelhante de resultados de regressão individuais.

Como alguém qualificado na arte estará ciente, "Seleção de atributo independente" é computacionalmente a mais rápida, mas menos precisa destas concretizações, "Seleção de atributo exaustiva" é computacionalmente a mais lenta, mas mais precisa, e "Seleção de atributo incrementai" pode prover um nível intermediário de precisão com velocidade computacional intermediária.

Geralmente, os conjuntos de dados que estão disponíveis para uso em gerar predições incluem tudo ou algum dos conjuntos de dados de medidor recebidos pelo sistema, tais como a série de tempo de leituras de medidor e transformações desses conjuntos de dados tais como deslocamentos de tempo da séries de tempo de leituras de medidor. Em uma concretização, os conjuntos de dados que estão disponíveis para predição (os atributos de qual seleção de atributo deve escolher N conjuntos) são os conjuntos de dados para medidores diferentes de o medidor sob análise, e certos deslocamentos de tempo do conjunto de dados para o medidor sendo analisado e outros medidores. Os deslocamentos de tempo correspondem a múltiplos dos períodos de ciclo esperados nos dados, tal como um dia, uma semana, e um ano. Por meio de exemplo, os outros medidores cujos conjuntos de dados são considerados podem ser a coleção inteira de medidores disponíveis, ou a coleção de medidores que medem a mesma quantidade (por exemplo, medidores de fluxo, se o medidor sob análise for um medidor de fluxo), ou só medidores que estão localizados remotamente do medidor sob análise, tal que um evento local registrado pelo medidor sob análise seja improvável se propagar hidraulicamente pela rede para quaisquer dos medidores remotos.

Em algumas concretizações, os dados de medidor usados podem ser uma versão processada dos dados de medidor originais recebidos, e podem ser restringido ademais em tempo dos dados históricos inteiros. Por exemplo, os conjuntos de dados usados para a análise anterior podem ser os valores de medidor médios calculados através de períodos de 6 horas consecutivos (um valor médio para cada medidor durante cada 6 horas), começando 70 dias antes de tempo atual, e terminando 7 dias antes de tempo atual. Isto poderia, por exemplo, remover qualquer efeito indesejado de dessemelhança recente entre medidores, causados por um efeito em andamento que é para ser detectado, qualquer dessemelhança irrelevante que pode ter existido a muito tempo atrás (tal como durante outra estação), e diferenças em dia curtos.

Figura 6 apresenta um fluxograma ilustrando um método para seleção de dados correspondentes para uma predição de medidor correspondente. Figura 6 representa um subcaso simples dos algoritmos de seleção publicados acima, em que um único conjunto de dados de um medidor separado é selecionado como o conjunto de dados correspondente. Isto faz uso da observação que medidores distantes podem não ser normalmente afetados pelos mesmos eventos locais, tal como vazamento a jusante de um dos medidores, mas pode ser afetado semelhantemente por consumo mundial ou eventos de rede (tal como um dia quente ou evento de esporte), assim prevenindo muitos falsos alertas potenciais. Na etapa 601, o sistema seleciona um primeiro conjunto de dados incluindo dados históricos de um medidor. Os dados históricos incluem valores de pressão e fluxo e a hora associada com as leituras de pressão e fluxo. A seguir, na etapa 602, o sistema seleciona um segundo conjunto de dados, o segundo conjunto de dados incluindo dados históricos de um medidor. Em uma concretização, o segundo conjunto de dados são dados históricos de um dispositivo de rede fisicamente diferente e não fortemente conectados hidraulicamente ao dispositivo de rede representado pelo primeiro conjunto de dados. Por exemplo, o primeiro conjunto de dados está associado com um medidor localizado em Manhattan, e o segundo conjunto de dados está associado com um medidor localizado em Queens. Locais escolhidos podem ser remotos bastante ou caso contrário suficientemente removidos do medidor sendo analisado tal que os conjuntos de dados não sejam conectados hidraulicamente, e portanto não afetados pela mesma anomalia ou evento, por exemplo, seu fluxo de água não é afetado pelos mesmos vazamentos, mudanças de qualidade de água não afetariam o outro, e similar. Porém, embora o segundo conjunto de dados não será afetado pelo mesmo evento hidráulico local, ambos os conjuntos de dados ainda podem ser afetados pelo mesmo evento regional ou global, tal como um dia quente, ou um evento esportivo amplo municipal. Em outra concretização, o segundo conjunto de dados é um conjunto de dados de um período de tempo diferente do mesmo medidor representado pelo primeiro conjunto de dados. Por exemplo, o primeiro conjunto de dados é de medidor 1, e o segundo conjunto de dados também é de medidor 1, mas representa dados de três dias antes.

A seguir, na etapa 603, o sistema compara os dados históricos do primeiro conjunto de dados com dados históricos do segundo conjunto de dados para determinar se uma correlação íntima entre os dois medidores existe. Uma correlação pode ser determinada de acordo com técnicas de correlação padrão conhecidas na arte. Algumas técnicas de correlação existentes conhecidas na arte são descritas em Miles, Jeremy e Shevlin, Mark, "Ayplying Regression and Correlation: A Guide for Students and Researches", Sage Publications Ltd. (2000), ISBN 0761962301. Uma correlação pode ser considerada íntima se o valor de correlação exceder um limiar predeterminado, em qual caso o sistema procede à etapa 604. Por exemplo, se a métrica de correlação usada for R quadrada (também chamado o coeficiente de determinação), que varia de 0 a 1, então o sistema pode reconhecer o medidor como medidores correspondentes se o R quadrado calculado estiver acima de um valor predefinido tal como 0,9. Na etapa 604, o sistema determina se outro conjunto de dados correspondente pode ser requerido. Em uma concretização, outro conjunto de dados correspondente pode ser requerido para facilitar detecção de anomalia mais precisa, e o sistema procede à etapa 602. Se nenhum conjunto de dados correspondente for requerido, o sistema executa análise na etapa 605, e como discutido com respeito à Figura 5.

Porém, retornando à etapa 603, e em outro exemplo, se o valor de correlação for mais baixo do que o limiar, o sistema pode reconhecer que os conjuntos de dados não se correlatam de perto, em qual caso o sistema procede à etapa 602 e outro conjunto de dados é selecionado.

Em algumas concretizações, os dados usados por um preditor podem incluir outras formas de dados disponíveis para a Máquina de Análise de Rede, tal como Operação e Dados Externos, descrita acima. Tais dados podem ser usados, por exemplo, para ademais restringir, aumentar, ou categorizar os dados de medidor. Por meio de ilustração, um preditor pode usar tais dados de forma que só dados de feriados prévios (não dias de trabalho regulares) sejam usados para predizer valores para um feriado atual, ou cancelar os efeitos de tempos não sazonais, eventos de rede conhecidos, ou mudanças de rede temporárias.

Figura 8 apresenta um fluxograma ilustrando um método para detectar e registrar um evento de vazamento de água. Na etapa 801, o sistema obtém dados pré-processados do sistema de distribuição de água. A seguir, na etapa 802, o sistema executa número N de predições estatísticas de acordo com número N de modelos de predição estatísticos. A seguir, na etapa 803, e para cada preditor, o sistema compara os dados de predição aos dados atuais para determinar se existe um desvio estatisticamente significante. Se nenhuma desvio estatisticamente significante existir para o preditor particular, o sistema procede à etapa 807 e nenhum evento é produzido. Na etapa 807, o sistema procede à etapa 808 para selecionar outro conjunto de dados de medidor da rede de água para análise. Porém, na etapa 803, se um desvio estatisticamente significante existir para o preditor particular, o sistema procede à etapa 804 e detecta uma anomalia.

A seguir, na etapa 805, a anomalia pode ser classificada como evento de acordo com a discussão de exemplos providos com respeito à Figura 4. Por exemplo, se o sistema, de acordo com modelos de preditor diferentes, emitir uma anomalia de um aumento continuado estatisticamente significante em fluxo e uma anomalia de uma redução de curto prazo estatisticamente significante em pressão (seguida por uma correção de pressão), as anomalias são classificadas na etapa 805 como o começo de um evento de vazamento. A um momento posterior, se o sistema detectar uma anomalia de diminuição de fluxo correspondente de magnitude semelhante, a anomalia é classificada como o fim desse evento de vazamento. Outro método de classificar desvios na etapa 805 é o uso de dados externos para confirmar ou refutar as anomalias detectadas na etapa 804. Por exemplo, se o dia que a análise aconteceu era um feriado, em que, por exemplo, padrões de uso de água residenciais podem mudar significativamente, então grandes desvios estatísticas dos dados preditos podem aumentar o limiar estatístico precisado para identificar um evento de vazamento. Em outro exemplo, um evento esportivo pode ativar um consumo aumentado em uma área da rede, e o sistema pode ser equipado para utilizar esta informação como dados externos para confirmar ou refutar a existência de um evento. Em outras concretizações, o sistema pode refutar uma anomalia detectada aplicando limitações adicionais ou os dados que produzem a anomalia. Por exemplo, o sistema, ou os operadores de rede, podem decidir prover alerta só correspondendo a vazamentos cruzando um certo limiar de magnitude, tendo um desvio de valores esperados durando por mais que um período especificado de tempo, ou ocorrendo através de uma certa freqüência por um certo período de tempo. A sensibilidade do sistema para detectar vazamentos pode depender pelo menos em parte do limiar de magnitude determinado por usuário, ou tendo um vazamento durando pelo menos um período de tempo especificado.

A seguir, na etapa 806, o sistema registra um evento tal como um vazamento e ademais provê características de um vazamento detectado. As características podem incluir a magnitude do vazamento, a tendência ou taxa de aumento do vazamento e a quantidade total de água que vazou até agora. O alerta de vazamento e características do vazamento podem ser armazenados em um elemento como banco de dados 208 na Figura 2, e também podem ser reproduzidos em quaisquer das saídas 210-214 da Figura .2. Depois de registrar um evento na etapa 806, o sistema procede à etapa 808 para selecionar outro conjunto de dados de medidor da rede para análise.

Figura 9 apresenta um fluxograma ilustrando um método para detectar uma anomalia de medidor defeituoso. Na etapa 901, o sistema seleciona um conjunto de dados a ser analisado. Elementos 902 e 905-909 representam vário preditores e detectores de anomalia para determinar a significação estatística de qualquer desvio de valores atuais e preditos. Alguém de habilidade na arte apreciará que cada elemento 902 e 905-909 ou qualquer combinação dos elementos pode ser usado para determinar os valores prováveis e emitir uma anomalia. Além disso, o sistema pode proceder executando qualquer combinação dos elementos simultaneamente, ou seqüencialmente em qualquer ordem. Procedendo com a concretização ilustrada pelo fluxograma na Figura 9, o preditor e detectores de anomalia representados por elemento 902 determinam se ou não há um desvio significante estatisticamente do valor transmitido, além do que pode ser explicado por um evento de rede real, tal como um vazamento.

O preditor e detectores de anomalia representados por elementos 903-905 determinam se ou não desvio de deriva de relógio estatisticamente significante existe quando o primeiro conjunto de dados é correlatado com um segundo conjunto de dados. O preditor e detectores de anomalia procedem selecionando um conjunto de dados de referência ou múltiplos conjuntos na etapa 903, e então correlatando o primeiro conjunto de dados com o conjunto de dados de referência na etapa 904. O conjunto de dados de referência pode incluir um ou mais medidores que normalmente têm valores em correlação íntima com o medidor sob análise. A seguir, o sistema procede à etapa 905 para determinar se o medidor exibe uma deriva de relógio significante estatisticamente procurando o deslocamento de tempo que produz a melhor correlação. Se o medidor exibir deriva de relógio (quer dizer, se o melhor deslocamento de tempo for significativamente diferente de 0), o sistema procede à etapa 910 e emite um evento de medidor defeituoso.

O preditor e detectores de anomalia representados por elemento 906 determinam se um valor fixo foi transmitido. O sistema determina se um valor fixo, ou dados que não mudam com o passar do tempo, foram transmitidos na etapa 904. Se o medidor transmitiu um valor fixo, quase fixo, ou freqüentemente fixo, durante um tempo anormalmente longo, o sistema procede à etapa 910 e emite um evento de medidor defeituoso.

O preditor e detectores de anomalia representados por elemento 907 determinam se ou não a variabilidade de curto prazo é alta demais ou baixa demais. Se a variabilidade de curto prazo for alta demais ou baixa demais, o sistema procede à etapa 909 e emite um alerta de medidor defeituoso.

O preditor e detectores de anomalia representados por elemento 908 determinam se ou não há um desvio significante estatisticamente da quantidade de dados habituais transmitidos. Se consideravelmente menos ou mais que dados habituais foram transmitidos, então o sistema produz uma anomalia. Por exemplo, se nenhum valor foi transmitido pelo medidor durante três dias, o sistema produz uma anomalia. Porém, se o desvio entre a quantidade de dados predita a ser transmitida e os dados atuais transmitidos não for estatisticamente significante, nenhuma anomalia é produzida.

O preditor e detectores de anomalia representados por elemento 909 determinam se ou não os valores são não suportados por outros medidores de rede. Por exemplo, conservação de massa pode indicar que a leitura em um primeiro medidor de fluxo deve ser maior do que a leitura em um segundo medidor de fluxo a jusante disto, ou a soma de várias outras leituras de medidor. Se tais valores "impossíveis" forem achados, o sistema procede à etapa 910 e emite um evento de medidor defeituoso.

Depois de prover um evento na etapa 910, o sistema seleciona o próximo objetivo para analisar na etapa 911 e continua analisando a rede para outros medidores defeituosos.

Figura 10 ilustra um fluxograma descrevendo uma concretização para prover um consumo inesperado ou anomalia de roubo. Elementos 1003-1005 representam vários preditores e detectores de anomalia para determinar a significação estatística de qualquer desvio de valores atuais e preditos. Alguém de habilidade na arte apreciará que cada elemento 1003- 1005 ou qualquer combinação dos elementos pode ser usada para determinar os valores prováveis e emitir uma anomalia. Além disso, o sistema pode proceder executando qualquer combinação dos elementos simultaneamente, ou seqüencialmente em qualquer ordem. Na etapa 1001, o sistema seleciona um medidor ou uma rede de água para analisar para um consumo de água inesperado ou roubo de água. Em outra concretização, o sistema seleciona uma seção de uma rede de água, ou uma rede de água inteira para analisar para um consumo de água inesperado ou roubo de água. A seguir, na etapa 1002, se o sistema detectar um aumento em fluxo do medidor selecionado ou seção de rede, o sistema procede para ademais categorizar a anomalia, representada por elementos .1003-1005. Em uma concretização, o sistema pode detectar um aumento em fluxo através dos dados históricos de medidor e aplicar a análise estatística esboçada com respeito à Figura 2. Em outra concretização, o sistema pode detectar um aumento em fluxo analisando dados em tempo real do medidor.

O preditor e detectores de anomalia representados por elemento 1003 determinam se ou não há um casamento estatisticamente significante de aumento de fluxo para o padrão de consumo. Na etapa 1003, o sistema pode analisar o aumento de fluxo atual com um padrão de consumo previamente armazenado. O padrão de consumo previamente armazenado pode incluir dados de medidor ou rede durante o último ano, ou qualquer outro prazo para facilitar análise de determinar um padrão de consumo. Se o aumento de fluxo casar com o padrão de consumo, o sistema procede à etapa .1006 para determinar se o evento pode ser explicado por outro fator.

O preditor e detectores de anomalia representados por elemento 1004 determinam se ou não há um aumento estatisticamente significante ocorrendo novamente em fluxo em horas semelhantes. Por exemplo, o sistema analisa dados históricos para o medidor ou sistema para determinar a periodicidade do padrão de consumo. Se existir um aumento em fluxo ocorrendo novamente, e isto não ocorreu ademais no passado, o sistema procede à etapa 1006 para determinar se o evento pode ser explicado por outro fator.

O preditor e detectores de anomalia representados por elemento 1005 determinam se ou não há um fluxo recorrente estatisticamente significante tendo uma magnitude semelhante cada vez. Em uma concretização, o sistema compara os períodos de fluxo aumentado com outros dados históricos de fluxo do medidor ou rede para determinar um aumento quase constante na magnitude de baixo durante períodos recorrentes. Se o sistema detectar magnitudes semelhantes cada vez, e isto não ocorreu ademais no passado, o sistema procede à etapa 1006 para determinar se o evento pode ser explicado por outro fator.

Na etapa 1006, o sistema determina se um evento detectado pode ser refutado por dados de externos ou de operação. Em um exemplo, o sistema analisa dados de operação para determinar se houve uma entrada autorizada ao local sob análise. Em outro exemplo, o sistema refuta um evento detectado se um aumento de fluxo a um medidor e uma diminuição de fluxo correspondente de magnitude semelhante a outro medidor para a mesma região indicar uma mudança em fluxo, mas não uma mudança em consumo total nessa região. Se o sistema não refutar o evento detectado na etapa 1006, o sistema provê um consumo inesperado ou não autorizado ou evento de roubo na etapa 1007. Porém, se o sistema refutar o evento, o sistema procede à etapa 1008. A seguir, na etapa 1008, o sistema seleciona o próximo objetivo a analisar e continua analisando a rede para outro consumo inesperado ou não autorizado ou eventos de roubo.

Figura 11 ilustra um fluxograma descrevendo uma concretização para prover um alerta de anomalia de qualidade de água. Na etapa 1101, o sistema seleciona um conjunto de dados do primeiro local a ser analisado. Elementos 1103, 1104 e 1106 representam vários preditores e detectores de anomalia para determinar a significação estatística de qualquer desvio de valores atuais e preditos. Alguém de habilidade na arte apreciará que cada elemento 1103, 1104, e 1106 ou qualquer combinação dos elementos pode ser usada para determinar os valores prováveis e emitir uma anomalia. Além disso, o sistema pode proceder executando qualquer combinação dos elementos simultaneamente, ou seqüencialmente em qualquer ordem.

O preditor e detectores de anomalia representados por elemento 1103 determinam se ou não há uma mudança estatisticamente significante no cloro, turvação, ou pH em pelo menos dois locais selecionados na etapa 1102, a mudança sendo em excesso de um limiar predefinido fixado pelos gerentes de rede de água. O sistema pode selecionar pelo menos dois ou mais locais vizinhos na etapa 1102. O número de locais selecionados pode ademais ajudar o sistema a predizer mais precisamente uma anomalia de quantidade de água. Se o sistema detectar uma mudança na etapa 1103, o sistema procede à etapa 1105 para decidir se o evento deveria ser informado.

O preditor e detectores de anomalia representados por elemento 1104 determinam se ou não há um aumento de turvação estatisticamente significante no medidor selecionado do local selecionado, e nesse caso, o sistema procede à etapa 1105 para decidir se o evento deveria ser informado.

O preditor e detectores de anomalia representados por elemento 1106 determinam se ou não há uma diminuição de cloro estatisticamente significante no mesmo local. Se existir uma diminuição de cloro no local, o sistema procede à etapa 1105 para decidir se o evento deveria ser informado.

Na etapa 1105, o sistema recebe eventos de elementos 1103, 1104, e 1106 e determina se os eventos deveriam ser informados, ou desqualificados. Uma razão para desqualificar um evento é se existe um queda de pressão estatisticamente significante, aumento de fluxo, ou uma entrada autorizada ao local selecionado na etapa 1101. Em uma concretização, uma entrada autorizada ao local pode incluir um conserto ao local por uma equipe de construção, que pode resultar em um aumento de turvação temporário no medidor selecionado. Uma queda de pressão de curto prazo significante, por exemplo, pode indicar um evento de vazamento ou intervenção de rede, que deveria ser levada ser a causa de raiz do que parece ser caso contrário uma anomalia de qualidade. Porém porque um conserto pode ser relativamente breve, o sistema pode não desejar prover um alerta de anomalia devido a um conserto temporário, e o sistema procede à etapa 1108 para selecionar outro conjunto de dados para analisar. Se o sistema não detectar uma queda de pressão, aumento de fluxo, ou entrada autorizada ao local, o sistema procede à etapa 1107 e provê um evento de qualidade de água. Depois de prover um evento na etapa 1107, o sistema seleciona o próximo objetivo para analisar na etapa 1108 e continua analisando a rede para outros eventos de qualidade de água. Alguém de habilidade na arte apreciará aquelas outras concretizações podem processar semelhantemente outros parâmetros e indicadores de qualidade de água, levando em conta os eventos e atividades de rede que podem afetar temporariamente esses outros parâmetros.

Figura 12 ilustra uma tomada de tela da interface de usuário ("UI") gerada pela interface de rastreamento de evento de acordo com uma concretização da presente invenção. A tela na Figura 12 exibe eventos detectados e sua informação associada a um usuário. O usuário pode, por exemplo ser um trabalhador a uma rede de distribuição de água atarefada com monitorar a rede de água sob análise. Figura 12 inclui tomada de tela de UI .1201 que inclui seções para estado de atualização 1202, painel de lista de eventos 1203, gráfico 1204, informação de evento 1205, gráfico 1206 e mapa .1207.

Em uma concretização, UI 1201 é uma página da web visível a um usuário através de uma rede ou a Internet. Adicionalmente, estado de atualização 1202 informa o usuário da última data e hora que o sistema monitorou a rede de água para anomalias. Painel de lista de eventos 1203 provê o usuário com uma listagem de eventos previamente detectados, as datas, horas, locais, e estado dos eventos. Ademais para a concretização, o painel de lista de eventos 1203 ademais permite a pessoa vendo a interface de usuário 1201 selecionar um evento no painel de lista de eventos 1203. Informação detalhada associada com o evento selecionado é reproduzida como informação de evento 1205, gráficos 1204 e 1206, e mapa 1207. Informação de evento 1205 inclui, por exemplo, uma hora de começo da anomalia, uma hora de fim da anomalia, uma magnitude da anomalia, uma perda de água total associada com a anomalia, e qualquer comentário provido por usuários do sistema. Comentários providos por usuários ou pelo sistema também provêem 'hiperlinks' a outros eventos armazenados pelo sistema. Gráficos 1204 e 1206 incluem informação detalhada sobre o evento selecionado por usuário tal como uma comparação visual do fluxo de água atual e predito (rotina) a um medidor pertinente. Adicionalmente, a interface de usuário 1201 utiliza dados de GIS associados com o evento selecionado para mostrar o local do evento em mapa 1207. Em uma concretização, o evento está associado com um medidor específico, e o local do medidor é produzido no mapa 1207. O mapa de evento 1207 também pode ser habilitado a exibir uma área da rede afetada pelo evento detectado, ou uma área estimada dentro da qual o local de evento exato é provável estatisticamente estar contido.

Banco de Dados 208 ou Máquina de Decisão e Classificação de Evento 207 da Figura 2 pode hospedar um aplicativo de software interativo que associa dados de medidor, alertas, relatórios, análise estatística e um mapa da rede de água com uma interface de usuário para permitir a um usuário do sistema discernir facilmente o local de um vazamento de água ou outro evento. Uma interface de usuário pode ser hospedada em Banco de Dados 208, e apresentada a qualquer número de interfaces representadas por elemento 209. Em outra concretização, Máquina de Decisão e Classificação de Evento 207 é operativa para enviar informação diretamente para elementos .210,211,212,213,214.

Figura 13 ilustra um tomada de tela da UI gerada pela interface de rastreamento de evento de acordo com uma concretização da presente invenção. A tela na Figura 13 exibe eventos detectados e sua informação associada a um usuário. O usuário pode, por exemplo, ser um trabalhador a uma rede de distribuição de água atarefado com monitorar a rede de água sob análise. Figura 13 inclui UI 1301 que inclui painel de lista de eventos 1302, gráficos 1303 e 1304, mapa 1305 e informação de evento 1306.

Em uma concretização, UI 1301 é uma página da web visível a um usuário através de uma rede ou a Internet. Adicionalmente, painel de lista de eventos 1302 provê o usuário com uma listagem de eventos previamente detectados, a data, horas, locais de medidor, e estado dos eventos. Ademais à concretização, o painel de lista de eventos 1302 ademais permite a pessoa vendo a UI 1301 selecionar um evento no painel de lista de eventos 1302. Informação detalhada associada com o evento selecionado é reproduzida como informação de evento 1306, gráficos 1303 e 1304, e mapa 1305. A interface de usuário 1301 utiliza dados de GIS associados com o evento selecionado para mostrar o local ou local aproximado do evento em mapa .1305. Em uma concretização, mapa 1305 é operativo para exibir o local de múltiplos medidores registrando um evento.

Figura 14 ilustra uma tomada de tela de outra UI gerada pela interface de rastreamento de eventos de acordo com uma concretização da presente invenção. A tela na Figura 14 exibe dados associados com um evento detectado ou medidor ou região selecionada da rede. O usuário pode, por exemplo, ser um trabalhador a uma rede de distribuição de água atarefado com monitorar a rede de água sob análise, e mais especificamente, Figura 14 representa um módulo de gráfico descrevendo dados colecionados pelo sistema, e permitindo ao usuário ademais explorar, personalizar, e mudar os gráficos providos pelo sistema para cada evento, ou explorar independentemente os dados por várias visualizações e usar algumas das capacidades de pré-processamento do sistema. Figura 14 inclui UI 1401, painel de lista de medidores e controle gráfico 1402, gráfico 1403, e estado de atualização 1404. Em uma concretização, UI 1401 é uma página da web visível a um usuário através de uma rede ou Internet. O usuário de UI 1401 pode selecionar um ou mais medidores e uma variedade de tipos de gráfico de painel de lista de medidores e controle gráfico 1402. Dados associados com os medidores selecionados podem ser produzidos em gráfico 1403. Dados produzidos em gráfico 1403 podem ser qualquer informação obtida pelo sistema. Estado de atualização 1402 informa o usuário da última data e hora que o sistema monitorou a rede de água para anomalias.

Figura 15 ilustra um tomada de tela da UI gerada pela interface de relatórios de acordo com uma concretização da presente invenção. A tela na Figura 15 exibe um panorama agregado dos eventos detectados e sua informação associada a um usuário. O usuário pode, por exemplo, ser um trabalhador a uma rede de distribuição de água atarefado com monitorar a rede de água sob análise. Figura 15 inclui UI 1501, painel de seleção de panorama 1502, painéis de contagem de evento 1503 e 1504, mapa 1505, e gráficos 1506.

Em uma concretização, UI 1501 é uma página da web visível a um usuário através de uma rede ou a Internet. Adicionalmente, painel de panorama 1502 provê o usuário com opções para exibir uma agregação de eventos em através de um período de tempo selecionado. O usuário pode escolher a exibição de eventos baseado em valores de medidor, eventos, datas, e estado dos eventos. Informação detalhada associada com a seleção de usuário em painel de seleção de panorama 1502 é reproduzida como painéis de contagem de evento 1503 e 1504, mapa 1505, e gráficos 1506. Painel de seleção de panorama 1502 permite ao usuário ordenar e filtrar eventos pelos seus vários campos e características, por exemplo, para ver só eventos recentes e não resolvidos, eventos ordenados por tipo, e atualizar estados de evento e outras características de fluxo de trabalho. Isto segue padrões de indústria de software, bem conhecidos a alguém qualificado na arte.

Painéis de contagem de evento 1504 e 1505 exibem o número de eventos, tipos de evento, e locais de acordo com um período de tempo. Em uma concretização, painéis de contagem de evento 1504 e 1505 exibem eventos correspondendo a períodos de tempo diferentes, permitindo a um usuário comparar e contrastar o comportamento de rede com o passar do tempo. Mapa 1505 exibe o local e outra informação de eventos ocorrendo ou que ocorreram previamente em uma área. Em uma concretização, o mapa descreve eventos e realça áreas com múltiplos eventos: locais com poucos eventos podem ser coloridos verde, enquanto locais com muitos eventos podem ser coloridos vermelho. Gráficos 1506 operam para exibir a evolução do número e tipos de eventos através de um período de tempo. Em uma concretização, gráficos 1506 descrevem os tipos e números de eventos ocorrendo durante dois meses consecutivos, por exemplo permitindo ao usuário comparar e analisar tendências recentes. Alguém de habilidade na arte apreciará que qualquer informação colecionada pelo sistema pode ser reproduzida em gráfico 1506 para ajudar melhor um usuário atarefado com monitorar a rede de distribuição de água.

Figuras 1 por 15 são ilustrações conceituais permitindo uma explicação da presente invenção. Deveria ser entendido que vários aspectos das concretizações da presente invenção poderiam ser implementados em hardware, firmware, software, ou combinações disso. Em tais concretizações, os vários componentes e/ou etapas seriam implementados em hardware, firmware, e/ou software para executar as funções da presente invenção. Quer dizer, o mesmo pedaço de hardware, firmware, ou módulo de software poderia executar um ou mais dos blocos ilustrados (por exemplo, componentes ou etapas). Também deveria ser entendido que a invenção se aplica não só a redes de utilidade de água, mas a qualquer tipo de sistema de distribuição. Outros tipos de sistemas de distribuição podem ser: petróleo, água usada ou esgoto, gás, eletricidade, telefonia, ou outros sistemas de entrega de energia 5 que envolvem fluido ou recursos fluentes de uma área para consumidores. Realmente, a invenção pode ser aplicada a qualquer sistema de distribuição ou coleção tendo medidores ou sensores em locais arbitrários na rede medindo parâmetros de distribuição tais como fluxo, pressão, qualidade ou o próprio fluxo de dados.

Em implementações de software, software de computador (e. g., programas ou outras instruções) e/ou dados são armazenados em um meio legível por máquina como parte de um produto de programa de computação, e é carregado em um sistema de computador ou outro dispositivo ou máquina por uma unidade de armazenamento removível, unidade de disco rígido, ou interface de comunicação. Programas de computação (também chamados lógica de controle de computador ou código de programa legível por computador) são armazenados em uma memória principal e/ou secundária, e executados por um ou mais processadores (os controladores, ou similar) para fazer o um ou mais processadores executarem as funções da invenção como descrito aqui. Neste documento, os termos "meio legível por máquina", "meio de programa de computação" e "meio utilizável por computador" são usados para geralmente se referir a meios tais como memória de acesso aleatório (RAM); uma memória só de leitura (ROM); uma unidade de armazenamento removível (por exemplo, um disco magnético ou óptico, dispositivo de memória flash, ou similar); um disco rígido; ou similar.

Notavelmente, as figuras e exemplos acima não são significados limitar a extensão da presente invenção a uma única concretização, como outras concretizações são possíveis por meio de intercâmbio de alguns ou todos dos elementos descritos ou ilustrados. Além disso, onde certos elementos da presente invenção podem ser implementados parcialmente ou completamente usando componentes conhecidos, só aquelas porções de tais componentes que são necessárias para uma compreensão da presente invenção são descritas, e descrições detalhadas de outras porções de tais componentes conhecidos são omitidas para não obscurecer a invenção. Na especificação presente, uma concretização mostrando um componente singular não deveria ser necessariamente limitada a outras concretizações incluindo uma pluralidade do mesmo componente, e vice-versa, a menos que explicitamente declarado caso contrário aqui. Além disso, os requerentes não pretendem para qualquer termo na especificação ou reivindicações ser designado um significado incomum ou especial a menos que explicitamente publicado como tal. Ademais, a presente invenção cerca equivalentes conhecidos presentes e futuros para os componentes conhecidos referidos aqui por meio de ilustração.

A descrição precedente das concretizações específicas assim revela completamente a natureza geral da invenção que outros podem, aplicando conhecimento dentro da habilidade das artes pertinentes (incluindo os conteúdos dos documentos citados e incorporados por referência aqui), prontamente modificar e/ou adaptar para várias aplicações tais concretizações específicas, sem experimentação imprópria, sem partir do conceito geral da presente invenção. Tais adaptações e modificações portanto são pretendidas estarem dentro do significado e gama de equivalentes das concretizações expostas, baseado no ensinamento e orientação apresentados aqui.

Enquanto várias concretizações da presente invenção foram descritas acima, deveria ser entendido que elas foram apresentadas por meio de exemplo, e não limitação. Seria aparente a alguém qualificado nas artes pertinentes que várias mudanças em forma e detalhe poderiam ser feitas nisso sem partir do espírito e extensão da invenção. Assim, a presente invenção não deveria ser limitada por quaisquer das concretizações exemplares acima descritas, mas deveria ser definida só conforme as reivindicações seguintes e seus equivalentes.

Claims

1. Método computadorizado para monitorar uma rede de distribuição de água, a rede de distribuição de água incluindo pelo menos uma rede de tubos para entregar água a consumidores e uma pluralidade de medidores posicionados dentro da rede de distribuição de água, o método caracterizado pelo fato de incluir: receber dados de medidor, os dados de medidor representando uma pluralidade de parâmetros medidos pelos medidores, os parâmetros incluindo pelo menos fluxo ou pressão da água pelos tubos; receber dados secundários de uma ou mais fontes externas aos medidores, os dados secundários representando uma ou mais condições afetando fluxo ou consumo de água em uma região servida pela rede de distribuição de água; analisar os dados de medidor predizendo estatisticamente dados de medidor para um primeiro medidor baseado em segundos dados de medidor da rede de distribuição de água e dados secundários, em que os segundos dados de medidor incluem dados de medidor diferentes dos primeiros dados de medidor recebidos, e comparar os primeiros dados de medidor recebidos com os dados de medidor preditos para o primeiro medidor para identificar um ou mais eventos de rede de distribuição de água incluindo pelo menos um ou mais eventos de vazamento detectando uma anomalia se os primeiros dados de medidor recebidos desviarem dos dados de medidor preditos para o primeiro medidor por um desvio estatístico; e relatar o um ou mais eventos de rede de água a um usuário por uma interface de usuário.

2. Método de acordo com a reivindicação 1, caracterizado pelo fato de incluir armazenar os eventos de rede de água em um banco de dados.

3. Método de acordo com a reivindicação 1, caracterizado pelo fato de que receber dados de medidor inclui receber dados de Controle de Supervisão e Aquisição de Dados (SCADA).

4. Método de acordo com a reivindicação 1, caracterizado pelo fato de incluir classificar a anomalia como um evento de vazamento.

5. Método de acordo com a reivindicação 1, caracterizado pelo fato de que detectar a anomalia inclui determinar se uma duração da anomalia excede um limiar predefinido.

6. Método de acordo com a reivindicação 1, caracterizado pelo fato de que detectar a anomalia inclui determinar se uma freqüência da anomalia dentro de uma janela predefinida de tempo excede um limiar predefinido.

7. Método de acordo com a reivindicação 1, caracterizado pelo fato de que predizer estatisticamente dados de medidor para o primeiro medidor baseado em segundos dados de medidor da rede de distribuição de água inclui selecionar um ou mais segundos medidores como um ou mais medidores correspondentes e correlatar dados de medidor recebidos do primeiro medidor com dados de medidor recebidos do um ou mais medidores correspondentes.

8. Método de acordo com a reivindicação 7, caracterizado pelo fato de que selecionar um ou mais segundos medidores como o um ou mais medidores correspondentes inclui: correlatar dados históricos de medidor para o um ou mais segundos medidores com dados históricos de medidor para o primeiro medidor, e selecionar o um ou mais segundos medidores para quais uma correlação com o primeiro medidor existe.

9. Método de acordo com a reivindicação 7, caracterizado pelo fato de que selecionar o um ou mais segundos medidores como o um ou mais medidores correspondentes inclui identificar o um ou mais segundos medidores dentro da rede de distribuição de água que estão posicionados dentro da rede de distribuição de água para não serem afetados por anomalias afetando o primeiro medidor.

10. Método de acordo com a reivindicação 1, caracterizado pelo fato de que predizer estatisticamente dados de medidor para o primeiro medidor baseado em segundos dados de medidor da rede de distribuição de água inclui correlatar dados de medidor recebidos do primeiro medidor com pelo menos dados históricos de medidor armazenados para o primeiro medidor.

11. Método de acordo com a reivindicação 1, caracterizado pelo fato de que predizer estatisticamente dados de medidor para o primeiro medidor inclui calcular uma distribuição estatística de valores prováveis para o primeiro medidor.

12. Método de acordo com a reivindicação 20, caracterizado pelo fato de que receber dados de medidor inclui receber com o passar do tempo dados de qualidade de água representando turvação, cloro e pH da água entregues através da rede, e em que identificar um ou mais eventos de rede inclui detectar uma mudança nos dados de qualidade de água com o passar do tempo em excesso de um limiar.

13. Método de acordo com a reivindicação 1, caracterizado pelo fato de que receber dados secundários inclui receber pelo menos um de: dados meteorológicos representando condições meteorológicas na região da rede de distribuição de água; dados de calendário representando um ou mais fatores afetando consumo de água em uma dada data; dados de conserto representando um ou mais consertos executados na rede de distribuição de água; e dados estruturais representando uma estrutura da rede de distribuição de água.

14. Método de acordo com a reivindicação 20, caracterizado pelo fato de que o um ou mais eventos de informação incluem pelo menos um de: um aumento inesperado em padrão de consumo, uma mudança em padrão de consumo, um roubo de água, uma brecha de limite de zona, uma falha de medidor de utilidade, e um mau funcionamento de dispositivo de rede.

15. Método de acordo com a reivindicação 1, caracterizado pelo fato de incluir processar os dados de medidor antes de analisá-los incluindo filtrar fora ruído dos dados de medidor.

16. Sistema computadorizado para monitorar uma rede de distribuição de água, a rede de distribuição de água incluindo uma rede de tubos para entregar água a consumidores e uma pluralidade de medidores posicionados dentro da rede de distribuição de água, o sistema caracterizado pelo fato de incluir: um banco de dados de informação de rede para armazenar dados de medidor representando uma pluralidade de parâmetros medidos pelos medidores, os parâmetros incluindo pelo menos fluxo ou pressão da água pelos tubos, e dados secundários de uma ou mais fontes externas aos medidores, os dados secundários representando uma ou mais condições afetando fluxo ou consumo de água em uma região servida pela rede de distribuição de água; uma máquina de análise configurada para analisar os dados de medidor predizendo estatisticamente dados de medidor para um primeiro medidor baseado em segundos dados de medidor da rede de distribuição de água e dados secundários, em que os segundos dados de medidor incluem dados de medidor diferentes dos primeiros dados de medidor recebidos, e comparar os primeiros dados de medidor recebidos com os dados de medidor preditos para o primeiro medidor para identificar anomalias; uma máquina de classificação de evento configurada para identificar eventos de rede de distribuição de água baseados nas anomalias, os eventos de rede de água incluindo eventos de vazamento; e um banco de dados de evento para armazenar dados de evento de rede de distribuição de água representando o um ou mais eventos de rede de água identificados pela máquina de classificação de evento.

17. Sistema de acordo com reivindicação 16, caracterizado pelo fato de que a máquina de análise inclui uma pluralidade de módulos de preditor para gerar uma distribuição estatística de valores prováveis do dados de medidor para um dado medidor e uma pluralidade de módulos de detector de anomalia para comparar os dados de medidor ao dado medidor para a distribuição de valores prováveis para detectar anomalias no dados de medidor.

18. Sistema de acordo com reivindicação 16, caracterizado pelo fato de incluir uma pluralidade de módulos de interface para recobrar dados de evento de rede de distribuição de água do banco de dados de evento e informá-los a usuários.

19. Método computadorizado para administrar uma rede de distribuição de água, a rede de distribuição de água incluindo uma rede de tubos para entregar água a consumidores e uma pluralidade de medidores posicionados dentro da rede de distribuição de água, o método caracterizado pelo fato de incluir: enviar dados de medidor para uma máquina de análise, os dados de medidor representando uma pluralidade de parâmetros medidos pelos medidores, os parâmetros incluindo pelo menos fluxo da água pelos tubos; receber dos dados de máquina de análise representando eventos de rede de distribuição de água, os eventos de rede de água incluindo eventos de vazamento, os dados de evento de rede de distribuição de água tendo sido identificados como resultado de análise dos dados de medidor predizendo estatisticamente dados de medidor para um primeiro medidor baseado em segundos dados de medidor da rede de distribuição de água e dados secundários, os dados secundários representando uma ou mais condições afetando consumo ou fluxo de água em uma região servida pela rede de distribuição de água, em que os segundos dados de medidor incluem dados de medidor diferentes de os primeiros dados de medidor recebidos, e comparar os primeiros dados de medidor recebidos com os dados de medidor preditos para o primeiro medidor para identificar anomalias; e exibir os eventos de rede de distribuição de água recebidos a um usuário em um dispositivo de exibição computadorizado.

20. Método de acordo com a reivindicação 1, caracterizado pelo fato de que os eventos de rede de água ademais incluem identificar um ou mais eventos de informação relativos à quantidade ou qualidade de água fluindo pelos tubos e operação da rede de distribuição de água.