No nosso artigo anterior, vimos como você pode configurar uma utility network para realizar rastreamentos de isolamento para redes de gás e água. Nesse artigo, vimos como o sistema pode identificar equipamentos que podem ser usados para isolamento, além de como configurar nossa rede para usar um campo de posição normal para identificar se uma válvula está aberta ou fechada. Neste artigo, mostraremos como configurar uma utility network para gerenciar zonas de pressão. Os exemplos descritos neste artigo são para uma rede de gás, mas as técnicas e conceitos são aplicáveis a qualquer rede pressurizada.
O que é uma zona de pressão?
Uma parte importante do gerenciamento da distribuição de recursos para clientes em um sistema pressurizado é a criação e análise de zonas de pressão. Os engenheiros de uma utility dependem de fórmulas complexas e software de engenharia para garantir que o sistema opere conforme o esperado, no entanto, eles frequentemente dependem do modelo da rede armazenado em um GIS para construir esses modelos. É responsabilidade do analista GIS garantir que os dados no GIS estejam atualizados e precisos para que engenheiros, planejadores e operadores da rede possam tomar decisões informadas usando o GIS.
As zonas de pressão desempenham um papel importante nas responsabilidades diárias dos operadores e engenheiros. Para que operações e engenharia usem o GIS, eles devem ter confiança de que ele contém um registro preciso dos recursos que regulam e pertencem a cada zona de pressão. Leia o Entendendo Zonas de Pressão artigo para aprender como usar o GIS para gerenciar e analisar zonas de pressão.
Historicamente, os clientes mantiveram informações sobre zonas de pressão como um atributo nos tubos, ou usando uma camada poligonal em seu GIS que mostra a extensão de cada zona. Essas informações podem parecer boas em um mapa, mas não funcionam em casos onde há múltiplas zonas de pressão na mesma rua ou quando um usuário cria inadvertidamente uma conexão entre tubos em diferentes zonas de pressão. Cenários como este são onde uma utility network oferece valor, pois pode ser configurada para modelar e validar as extensões das zonas de pressão.
A utility network criada usando a ferramenta Migrate To Utility Network pode incluir um único tier para gerenciar sistemas de distribuição por padrão. Esses grandes agrupamentos de tubos compartilham uma fonte comum de gás, água ou energia. Para atribuir uma zona de pressão a um tubo, precisamos configurar um tier para representar as zonas de pressão. Se sua domain network estiver configurada para ser partitioned cada recurso pode pertencer apenas a um único tier, então você deve escolher entre rastrear o tier do sistema ou as zonas de pressão. Redes domain gas, water e district heating são tipicamente modeladas usando uma rede hierárquica por essa razão. Redes hierárquicas permitem que cada recurso participe em múltiplos tiers na rede. Isso não se limita apenas a sistemas e zonas de pressão. Alguns clientes também usam GIS para rastrear zonas de isolamento, estruturas de proteção catódica ou até mesmo áreas com medição distrital.
Ao adicionar um novo tier a uma utility network, você precisa se fazer as seguintes perguntas:
- Qual é o propósito deste tier?
- Quais recursos governam ou regulam (fontes ou sumidouros) este tier?
- Quais recursos são permitidos pertencer a este tier?
- Existem estatísticas que quero calcular para as sub-redes neste tier?
Com essas informações em mãos, você está pronto para começar a configurar um novo tier. O primeiro passo é configurar certos recursos para atuarem como fontes ou sumidouros no tier. Na utility network, esses recursos são chamados subnetwork controllers.
Configuração do Subnetwork Controller
Antes que um recurso possa atuar como subnetwork controller, seu tipo de ativo deve ser configurado para atuar como subnetwork controller em um tier na rede. Você pode encontrar uma lista completa dos passos na página set a subnetwork controller na ajuda online, mas vamos cobri-los brevemente aqui.
- Atribuir uma configuração terminal
- (opcional) Excluir regras anteriores
- Adicionar regras
- Atribuir uma categoria de rede
- (opcional) Adicionar um tier
- Definir a definição da sub-rede
Se você já identificou os equipamentos que impactam fluxo ou pressão como subnetwork controllers quando executou a ferramenta Migrate To Utility Network, então seus tipos de ativos já estão configurados para atuar como subnetwork controllers, e você pode pular direto para adicionar um tier.
Para começar, precisamos atribuir uma configuração terminal aos tipos de ativos que queremos designar como subnetwork controllers. Quando uma linha conecta-se a um dispositivo com terminais, ela deve especificar a qual terminal está conectada. A capacidade de diferenciar entre conexões é necessária ao criar subnetwork controllers. Por exemplo, sem o uso da configuração terminal e conexões terminais, um regulador não conseguiria distinguir entre os tubos conectados à sua entrada e os tubos regulados conectados à sua saída.
A ferramenta Migrate To Utility Network inclui três configurações genéricas de terminais:
- Directional Source – Esta configuração terminal é usada quando um dispositivo em uma rede baseada em fonte precisa dos terminais upstream e downstream.
- Directional Sink – Esta configuração terminal é usada quando um dispositivo em uma rede baseada em sumidouro precisa dos terminais upstream e downstream.
- BiDirectional – Esta configuração terminal é usada quando não há terminal explícito upstream ou downstream. Pode ser usada tanto em redes baseadas em fonte quanto em sumidouro.
Escolher a configuração terminal correta é importante para garantir que o rastreamento funcione corretamente. Em um sistema pressurizado, a maioria dos controladores da rede tem configurações explícitas dos terminais upstream e downstream. Isso significa que água, gás etc., só podem fluir do tubo no terminal upstream para o tubo no terminal downstream. No entanto, se você tiver equipamentos que podem ser configurados para não regular o fluxo no campo, deve usar a configuração BiDirectional que permitirá que a pressão não seja regulada enquanto flui pelo dispositivo. Em nosso exemplo, configuraremos nosso dispositivo como BiDirectional porque várias das nossas estações reguladoras mantêm um loop de alta pressão em nosso sistema de distribuição.
Nota: Se esta ferramenta for executada usando ArcGIS Pro 3.5 ou posterior, será necessário remover quaisquer regras existentes associadas ao tipo de ativo usando a ferramenta Delete Rule antes que você possa definir sua configuração terminal.
Depois de alterar a configuração terminal do dispositivo, você precisa criar regras que permitam definir quais tipos de tubos podem conectar-se a cada terminal. Neste exemplo, as estações reguladoras têm tubos de distribuição tanto na entrada quanto na saída do dispositivo, então você adicionará regras para cada lado.
Nota: Quando um tubo pode conectar-se a mais de um terminal em um dispositivo, cada tubo deve especificar a qual terminal está conectado no dispositivo. Caso contrário, isso cria um erro ambíguo de conectividade que deve ser resolvido usando a ferramenta Modify Terminal Connections.
Se você estivesse adicionando regras para estações fronteiriças da cidade ou medidores de transferência custódia, permitiria apenas tubos de transmissão no terminal upstream e tubos de distribuição no terminal downstream. Se estiver incerto sobre quais regras adicionar, consulte um engenheiro ou alguém com conhecimento do seu sistema para ajudá-lo a tomar a decisão correta.
No caso dos modelos hidráulicos (água), bombas ou válvulas redutoras teriam tubos distribuidores tanto nos terminais upstream quanto downstream.
Agora que o regulador em nosso exemplo tem terminais que permitem diferenciar entre as conexões dos tubos em ambos os lados, você pode começar a configurá-lo como subnetwork controller. O próximo passo é atribuir uma categoria da rede ao tipo do ativo para permitir que ele sirva como subnetwork controller. Para isso use a ferramenta Set Network Category:
O próximo passo é definir quais tipos de sub-redes o dispositivo está autorizado a atuar como subnetwork controller usando a ferramenta Set Subnetwork Definition. O dispositivo deve servir como subnetwork controller para sub-redes da zona de pressão, mas primeiro deve ser criado um tier representando as zonas de pressão. Isso é feito usando a ferramenta Add Tier.
Adicionando um tier da zona de pressão
Agora que seus tipos ativos têm categoria da rede, terminais e regras para atuar como controladores da rede você está pronto para adicionar seu tier à rede. Use a ferramenta Add Tier para adicionar um novo tier à rede.
Você pode aprender mais sobre essas configurações no tópico Tiers na ajuda online. Como nossa utility network já contém um tier para o sistema de distribuição com rank padrão 1, definimos o rank das zonas de pressão como 2. Isso significa que as zonas de pressão estão mais profundas na hierarquia da rede do que nossas sub-redes do sistema.
Como já temos um campo que armazena o nome da nossa sub-rede do sistema, especificamos um novo campo chamado PressureSubnetworkName para armazenar o nome da zona de pressão. Não se preocupe em criar esse campo antecipadamente; a ferramenta adicionará automaticamente esse campo para você.
Agora que adicionamos um tier da zona de pressão à nossa rede, precisamos definir os recursos que atuam como subnetwork controllers e participam da sub-rede junto com as regras sobre como o rastreamento da sub-rede deve ser realizado. Para isso usamos a ferramenta Set Subnetwork Definition. Essa ferramenta possui vários parâmetros; portanto recomenda-se ler a página subnetwork definition na ajuda online antes de executar essa ferramenta na sua rede.
Para a seção Valid Features and Objects especificamos todos os tipos ativos na nossa rede com apenas algumas exceções.
Para o parâmetro Valid Subnetwork Controllers selecionamos apenas nossas estações reguladoras e qualquer outro equipamento configurado para atuar como subnetwork controllers das zonas de pressão.
O parâmetro Aggregated Lines for Subnetline Feature Class é usado para identificar quais linhas são usadas para criar a geometria da linha da sub-rede quando a operação de atualização da sub-rede é executada. Como essa linha é usada para visualizar zonas de pressão quando ampliadas para escalas pequenas, não queremos incluir nenhum tipo de ativo que contenha muitas linhas pequenas. No caso do nosso sistema de tubos, não queremos incluir serviços, ramais ou linhas usadas exclusivamente para proteção catódica.
Nota: As feições excluídas da linha da sub-rede ainda são consideradas ao calcular resumos para a sub-rede.
Como sua rede não inclui estruturas ou conteúdo não espacial, você vai querer desabilitar, ou desmarcar as opções para incluir contêineres, conteúdo e estruturas. Você também vai querer tratar dispositivos abertos como barreiras usando uma barreira condicional, assim como fez com o nível do sistema.
Não se preocupe em preencher resumos ao configurar sua definição de sub-rede pela primeira vez. Você pode alterar sua definição de sub-rede mais tarde para incluir resumos sobre coisas como comprimento do tubo, volume e número de conexões de serviço.
O parâmetro aggregated lines for subnetline feature class é usado para identificar quais linhas são usadas para criar a geometria da linha da sub-rede quando a atualização da sub-rede é executada. Como essa linha é usada para visualizar zonas de pressão quando ampliadas para escalas pequenas, não queremos incluir nenhum tipo de ativo que contenha muitas linhas pequenas. No caso do nosso sistema de tubos, não queremos incluir serviços, ramais ou linhas usadas exclusivamente para proteção catódica.
Política de Atualização da Sub-rede
A última grande seção a configurar para a definição da sub-rede é a política de atualização da sub-rede. Isso lhe dá controle sobre como as informações da sub-rede são atualizadas dentro da sua utility network. Fazer alterações nessas configurações não é uma decisão simples para muitos clientes, pois envolve fazer concessões entre conveniência e desempenho. Vamos dar uma visão geral breve desses pontos de decisão aqui e referenciá-lo a discussões mais detalhadas quando disponíveis.
Se você escolheu incluir contêineres, conteúdo e estruturas em sua rede, opções adicionais serão exibidas para você especificar se deve atualizar contêineres de estrutura/rede de domínio. Isso determina se os campos de atributo Subnetwork name e Supported subnetwork name em suas estruturas e contêineres serão atualizados quando eles contiverem ou suportarem uma feição que pertença a uma sub-rede. Isso permite que você use a ferramenta Select By Attributes para identificar feições que suportam uma sub-rede sem executar um traçado. Embora isso seja conveniente para fins de relatório, também significa que a operação update subnetwork levará mais tempo para ser executada porque pode haver centenas de milhares de feições adicionais que precisam ser atualizadas.
A próxima opção a discutir é se o nível deve gerenciar o campo IsDirty (Status), você pode encontrar um mergulho profundo sobre gerenciamento de estado no site Esri Community. Este campo é usado para indicar se houve edições validadas em sua utility network que impactaram uma sub-rede específica. Esta opção é definida como False pela ferramenta Migrate To Utility Network porque pode ter impactos no desempenho.
Quando esta propriedade está habilitada, a utility network deve realizar um ou mais traçados para identificar quais sub-redes são impactadas toda vez que você valida edições. O custo de desempenho é relativo ao tamanho da sua maior zona de pressão. Se você tem zonas de pressão que contêm centenas de milhares de feições (tubos, junções e dispositivos), você deve manter este parâmetro desabilitado. No entanto, se todas as suas zonas de pressão forem menores que isso, você pode considerar esperar alguns segundos adicionais durante a operação validate network topology como um custo relativamente pequeno comparado aos benefícios para garantia de qualidade. Se você não tem certeza qual opção escolher, deve deixar esta propriedade desabilitada até estar confiante sobre o tamanho e impacto no desempenho das suas zonas de pressão. Esta opção quase sempre deve ser definida como false para níveis do sistema, já que eles podem facilmente conter todo o seu conjunto de dados.
Ter esta propriedade habilitada permite que você concentre seus esforços de garantia de qualidade apenas nas sub-redes que foram modificadas e permite identificar facilmente quais circuitos estão limpos e prontos para serem extraídos para um sistema externo como um OMS.
A configuração mais performática é deixar esta opção desabilitada. A configuração mais benéfica para garantia de qualidade e integrações é habilitar o gerenciamento de estado.
A última opção a considerar é qual modo de eventos usar para suas versões padrão e nomeadas. Essa decisão afeta o desempenho do update subnetwork e se o campo da sub-rede é preenchido durante certos fluxos de trabalho. Há um mergulho profundo sobre modos de eventos no site Esri Community. Uma versão muito simplificada da discussão segue abaixo.
Quando uma sub-rede é atualizada sem eventos ela será executada mais rápido. Existem vários fatores que contribuem para isso, mas uma razão é que regras de atributo e rastreamento do editor não são acionados. A maior desvantagem desse comportamento é que ao atualizar a sub-rede em uma versão nomeada, nem todas as feições têm garantido que seu nome da sub-rede seja atualizado para corresponder à sub-rede à qual pertencem.
Quando uma sub-rede é atualizada com eventos, na primeira vez que a operação update subnetwork é executada ela levará mais tempo do que as seguintes. Atualizações subsequentes também podem levar mais tempo se você tiver regras de atributo configuradas e estiver atualizando grandes números de feições. O benefício de atualizar sub-redes com eventos ativados é que quando update subnetwork é executado em uma versão você pode garantir que o campo nome da sub-rede está corretamente preenchido para todas as feições pertencentes àquela sub-rede.
Nota: A partir do ArcGIS Enterprise 11.4 e ArcGIS Pro 3.4, o custo de desempenho ao acionar regras de atributo pode ser mitigado usando o novo comportamento Triggering Fields das regras de atributo.
A configuração mais performática é deixar o modo de eventos definido para atualizar sem eventos. A configuração mais útil para garantia de qualidade é habilitar o modo de eventos quando em versões nomeadas e garantir que você tenha campos triggering configurados corretamente em todas as suas regras de atributo. Quando estiver trabalhando em um mobile ou file geodatabase a configuração recomendada é atualizar sem eventos, pois isso permite que a primeira execução e execuções subsequentes do update subnetwork sejam rápidas enquanto você trabalha nas questões de conectividade e garantia de qualidade.
Habilitando controladores da sub-rede
Depois disso, o último passo restante é identificar os controladores da sub-rede para cada zona de pressão no seu sistema. Para fazer isso você precisará visitar cada controlador da sub-rede na sua rede (neste exemplo estações reguladoras) e usar o painel Modify Subnetwork Controller para associar cada terminal no dispositivo com a respectiva zona de pressão em cada lado. Se você tiver erros ambíguos na conectividade do seu dispositivo, precisa usar o painel Modify Terminal Connections antes de habilitar o controlador da sub-rede para garantir que está habilitando o terminal correto como controlador da sub-rede.
Ao iniciar esse processo, pode ser difícil saber por onde começar, já que você pode ter dezenas ou centenas de zonas de pressão. Isso fica ainda mais complicado quando uma zona está aninhada dentro de outra zona. A tentação geralmente é começar pelas zonas com maior pressão no centro do seu sistema e trabalhar rumo às bordas; o problema com essa abordagem é que assim que você cria sua primeira zona ela consumirá todas as zonas aninhadas e downstream porque esses controladores ainda não foram configurados para regular pressão. Em vez disso, geralmente é mais fácil começar criando controladores nas bordas do seu sistema e trabalhar rumo ao centro. Dessa forma você não precisa se preocupar com zonas aninhadas e se cometer um erro provavelmente só precisará investigar as conexões com uma ou duas zonas vizinhas.
Se você ampliar na estação reguladora no lado oeste do território do serviço verá que a entrada/saída deste regulador não é imediatamente óbvia. No entanto, decifrar isso pode ser facilitado ativando rótulos para as pressões definidas em cada tubo.
Da mesma forma, ajuda olhar qual terminal cada linha está conectada. De fato, ao criar controladores da sub-rede, você sempre deve verificar se as conexões dos terminais entre seu controlador e dispositivo estão corretas. Se não estiverem configuradas corretamente isso causará problemas ao traçar suas sub-redes. Você pode ver a conexão dos terminais usando o painel Modify Terminal Connections em cada linha conectada ou, se for particularmente esperto, pode criar uma classe de rótulo na camada para mostrar essa informação.
Como você atribuiu uma configuração Bi-directional terminal, os terminais são especificados como Lado 1 e Lado 2. Se tivesse uma configuração directional terminal gostaria ver o tubo 720 psi no terminal upstream e o tubo 60 psi no terminal downstream. Agora que está confiante nas conexões dos terminais do nosso regulador, pode criar as sub-redes(s). Use o painel Modify Subnetwork Controller no regulador para criar uma sub-rede para o tubo 60 psi.
Certifique-se que o nível está definido como Pressure Zone e selecione o terminal conectado ao tubo 60 psi. Como uma sub-rede pode ter múltiplos controladores, você precisa identificar unicamente este controlador da sub-rede. Se tiver um campo único nome que possa usar coloque-o aqui; caso contrário deixe em branco e o sistema usará o global id da feição. Finalmente coloque o nome da zona de pressão no campo nome da sub-rede.
Uma vez que o terminal foi habilitado como controlador da sub-rede, você deve validar a topologia da rede para a feição antes dela poder ser usada.
Após validar a topologia, você pode usar a ferramenta de rastreamento para rastrear a sub-rede e validar se o resultado correto é retornado.
Depois de verificar que o rastreamento está correto, use a ferramenta Atualizar Sub-rede para criar a sub-rede pela primeira vez.
Uma vez que a sub-rede tenha sido atualizada com sucesso, você pode usar o painel Encontrar Sub-redes para visualizar a sub-rede. Este painel também pode ser usado para rastrear, atualizar e revisar o status das suas sub-redes.
Depois de repetir este processo para todas as suas zonas de pressão, você deve repetir os processos de garantia de qualidade que seguiu para sistemas para garantir que cada recurso esteja associado à zona de pressão correta.
Conclusão
Neste artigo, você aprendeu como configurar sua utility network para modelar controladores de sub-rede para zonas de pressão. Você aprendeu sobre a configuração necessária para permitir que um recurso seja um controlador de sub-rede, juntamente com como suas definições de sub-rede afetam o comportamento do seu sistema.
Agora que você criou zonas de pressão para seus dados, pode usá-las para muitos tipos de análise. Se estiver procurando inspiração, confira o artigo Understanding Pressure Zones. Sua jornada de configuração não precisa terminar aqui. Se estiver procurando mais coisas para configurar, considere o seguinte:
- Executar rastreamentos de isolamento usando as novas zonas de pressão
- Criar configurações de rastreamento usando suas zonas de pressão
- Adicionar funções resumo às suas definições de sub-rede (nível de pressão ou sistema)
- Revisar as configurações de eventing e state management do seu nível de pressão
Se quiser saber mais sobre como usar a utility network para gerenciar redes pressurizadas, como sistemas de gás e água, explore a série Learn ArcGIS Utility Network for Water Utilities e Learn ArcGIS Utility Network for Gas and Pipeline. Esta série inclui tutoriais e artigos que demonstram como atender às necessidades dessas indústrias usando a utility network.
Como sempre, se tiver alguma dúvida ou comentário, não deixe de perguntar no site Esri Community!
