Quando a utility network foi lançada pela primeira vez, ela introduziu um novo conceito no ecossistema e vocabulário da Esri, o Subnetwork. Essa abstração foi criada para descrever as diferentes formas como os usuários separam e gerenciam suas redes em zonas de rede sem usar termos específicos da indústria como ‘Circuit’ ou ‘Pressure zone’.
Mas por que usamos o termo “subnetwork”?
Todos os dados usados para gerenciar a conectividade de um conjunto de recursos para uma utility são armazenados em uma utility network (por exemplo, a rede). Então, quando essa rede é subdividida em áreas menores, topologicamente contíguas (circuitos, zonas de pressão, etc.), cada uma dessas zonas pode ser descrita com precisão como uma sub-rede. Com essa abstração em vigor, foi criado um framework para gerenciar cada subnetwork como seu próprio objeto GIS que pode ser visualizado, analisado e até usado para fins de relatório. Um componente importante desse framework é a capacidade de rastrear metadados em cada subnetwork para que os usuários possam entender como seu sistema está mudando ao longo do tempo.
Esses metadados fornecem informações básicas como campos de rastreamento de editor ou podem ser expandidos para incorporar valores definidos pelo usuário, como o número de clientes, número de dispositivos de proteção, etc. Os metadados também permitem que os usuários respondam à pergunta mais comum e importante que uma pessoa de GIS recebe: esses dados estão corretos?
Essa é uma pergunta surpreendentemente difícil porque correto significa coisas diferentes para pessoas diferentes. No entanto, dividindo a pergunta original em questões mais específicas, torna-se muito mais fácil responder:
- Quando a subnetwork foi atualizada pela última vez?
- Quando a subnetwork foi extraída pela última vez para outro sistema?
- Esta subnetwork está atualizada?
- As feições na subnetwork foram modificadas desde a última atualização?
- Existem erros conhecidos que precisam ser corrigidos nesta subnetwork?
As duas primeiras perguntas são fáceis de responder por meio de vários campos de data mantidos na subnetwork, nomeadamente os campos Last Update Subnetwork e Last Ack Export Subnetwork. As últimas três perguntas podem ser respondidas olhando para o campo Status de uma subnetwork (em modelos anteriores isso era chamado de campo ‘Is Dirty’) que inclui os valores de status Clean, Dirty e Invalid. Veja o que esses valores significam:
- Clean – Uma subnetwork que não tem erros conhecidos e está pronta para ser usada em análises.
- Dirty – Uma subnetwork que foi modificada e precisa ser atualizada.
- Invalid – Uma subnetwork que tem um ou mais erros conhecidos que precisam ser resolvidos.
Com a base estabelecida, o restante deste artigo focará em como o sistema gerencia o campo Status e como interpretar cada um dos diferentes valores de status.
Marcando Subnetworks como Dirty
A chave para gerenciar o status das subnetworks na utility network é que o sistema precisa ser capaz de determinar quando uma subnetwork é afetada por uma edição para que possa ser marcada como dirty. Embora existam muitas maneiras de realizar isso, o software atualmente usa a operação validate network topology para descobrir e marcar subnetworks como dirty. Como determinar qual subnetwork foi afetada por uma edição requer rastreamento, isso introduziria muita sobrecarga no processo de edição se o sistema realizasse essa análise após cada edição. Finalmente, porque todos os fluxos de trabalho de edição que afetam a rede devem ser validados, isso permite ao sistema garantir que o estado das subnetworks não fique fora de sincronia com os dados enquanto são editados.
Mas como o sistema determina quais subnetworks foram modificadas?
O sistema realiza um trace do controlador da subnetwork para todas as feições validadas para descobrir quais subnetworks foram afetadas pelas edições. O comportamento exato difere ligeiramente dependendo se as edições validadas pertencem a uma partitioned ou hierarchical utility network. O que esses termos significam e por que isso importa? Vamos discutir abaixo.
Em uma subnetwork partitioned, cada feição pode pertencer no máximo a uma única subnetwork. Isso significa que o sistema analisará cada tier da rede para determinar se alguma das feições editadas pertence àquele tier. Uma vez que uma feição tenha sido associada a uma subnetwork específica, ela pode ser removida da análise nos tiers subsequentes e, assim que todas as feições forem associadas, a análise estará completa, mesmo se todos os tiers não tiverem sido analisados. Você pode ver um exemplo simplificado de uma rede partitioned abaixo:
No caso de uma rede hierarchical, cada feição pode pertencer a múltiplas subnetworks porque os tiers da rede estão aninhados uns nos outros. Como resultado, o sistema deve sempre analisar cada tier na rede para todas as feições editadas. Você pode ver um exemplo simplificado de uma rede hierarchical abaixo:
Agora que examinamos os diferentes tipos de topologia em alto nível, vamos analisar vários cenários de edição para cada um desses tipos e observar como o sistema se comporta.
Partitioned
Quando a topologia da rede é validada em uma rede partitioned, o sistema precisa identificar a subnetwork afetada por cada edição. Para fazer isso ele identifica todos os tiers na rede que têm subnetworks e analisa cada tier para determinar quais subnetworks em cada tier, se houver alguma, foram afetadas pela edição. O sistema repete esse processo com cada tier até ter descoberto fontes da rede para todas as feições editadas ou até todos os tiers na rede terem sido analisados. Vamos ver alguns exemplos desse comportamento em ação.
No primeiro exemplo abaixo, uma única edição é feita na utility network (polígono roxo com hash). Quando validate network topology é executado ele encontra uma única fonte da rede para a edição no primeiro tier analisado, o tier de distribuição. Isso permite ao validate pular qualquer análise no tier de transmissão já que o sistema já descobriu um controlador da subnetwork que abrange todas as edições.
Neste segundo exemplo, múltiplas edições em várias áreas diferentes da rede são validadas. O sistema deve realizar múltiplos traces para descobrir fontes para todas as edições porque elas ocorreram em múltiplos tiers da rede.
No terceiro exemplo, o sistema valida uma edição feita em uma feição que não está conectada a nenhuma subnetwork. Nesse caso, o sistema deve rastrear todos os tiers na rede para confirmar que nenhuma subnetwork foi afetada.
Como você pode ver, a operação validate network topology pode identificar mais rapidamente as subnetworks modificadas em redes partitioned quando as edições são limitadas a um único tier e quando as subnetworks modificadas são menores. À medida que o número de tiers e o tamanho da subnetwork aumentam, o sistema levará mais tempo para identificar as subnetworks modificadas durante validate network topology porque deve realizar mais traces e esses traces levarão mais tempo.
Hierarchical
Porque toda feição em uma rede hierarchical pode pertencer a múltiplos tiers, o sistema deve considerar todos os tiers na rede que têm subnetworks ao tentar identificar as subnetworks afetadas durante validate network topology.
Abaixo você pode ver um exemplo simples de uma rede hierarchical que tem uma única system subnetwork contendo duas subnetworks menores.
Neste primeiro exemplo abaixo, uma feição pertencente a uma das subnetworks menores é editada. O sistema primeiro identifica a subnetwork menor à qual a edição pertence. No entanto, porque esta é uma subnetwork hierarchical o sistema deve analisar todos os tiers restantes na rede e neste caso identifica uma segunda subnetwork em um tier diferente para marcar como dirty.
No segundo exemplo, uma feição que pertence exclusivamente à maior subnetwork é editada. Nesse caso, as subnetworks inferiores não são marcadas como dirty. Isso ocorre porque a edição não afetou nenhuma das subnetworks inferiores. Essa lógica é a mesma independentemente se a rede é baseada em source ou sink porque a network com maior hierarquia é sempre o contêiner externo na hierarquia (a fonte final ou sumidouro final da rede).
No terceiro exemplo, uma feição que não pertence a nenhuma subnetwork é editada. Nesse caso nenhuma subnetwork é marcada como dirty. No entanto, a utility network deve rastrear cada tier da rede para confirmar que essa feição não pertence a nenhuma subnetwork.
Como as system subnetworks são tão grandes elas podem adicionar um custo maior de desempenho ao validate network topology do que subnetworks menores. Além disso, porque essas subnetworks contêm tantas feições elas têm maior probabilidade de serem marcadas como dirty durante validate e como resultado cada system subnetwork frequentemente precisa ser atualizada várias vezes por dia para permanecer clean. Por causa disso é comum os tiers do nível mais alto em uma rede hierarchical serem configurados para não gerenciar o campo status e ao invés disso apenas serem atualizados diariamente à noite. Além de reduzir com que frequência essas subnetworks são atualizadas essa configuração também melhora o desempenho do validate network topology porque permite à utility network pular esse tier durante validação. A próxima seção deste artigo discute como você pode determinar se um tier está configurado para gerenciar o campo status.
Configuração
Embora manter o campo Status seja o comportamento padrão das subnetworks na utility network existem alguns usuários e indústrias inteiras que não utilizam status da subnetwork como parte dos seus fluxos de trabalho. Para suportar essa configuração a seção Update Subnetwork Policy da ferramenta Set Subnetwork Definition contém uma opção para determinar se o tier correspondente na subnetwork deve ‘Manage IsDirty’.
Usuários que optam por não ativar esse comportamento (desabilitar o gerenciamento de estado) geralmente o fazem por uma de duas razões:
- Seus fluxos de edição resultam em sub-redes que estão sempre sujas, ou...
- Impactos no desempenho
Lembre-se de que essa configuração é feita separadamente para cada nível na sua rede, então você pode optar por deixar essa configuração ativada para alguns níveis da sua rede (distribuição, zonas de pressão, etc.) enquanto desativa para outros níveis maiores (transmissão, sistema, etc.).
Independentemente de como sua rede está configurada atualmente, você sempre pode alterar essa configuração depois. Se seu modelo atualmente tem essa configuração ativada, essa opção pode ser desativada se você não achar útil gerenciar o campo de status. Se, por outro lado, você tem um modelo que não gerencia o campo de status, mas depois decide que quer aproveitar o campo de status em seus fluxos de trabalho, ele pode ser ativado.
Validar Consistência
Toda a discussão até este ponto analisou como, quando e quais sub-redes são marcadas como sujas quando uma área suja é validada. Isso, claro, levanta a questão; como o sistema responde ou identifica sub-redes que contêm edições que não foram validadas? É aqui que entra a ideia de validar a consistência durante a análise.
O comportamento padrão ao realizar um trace na utility network é validar a consistência do resultado do trace. Na prática, isso significa que o sistema verifica se há áreas sujas associadas aos seus resultados do trace. Se não houver áreas sujas associadas aos seus resultados, então seus resultados são considerados consistentes.
No entanto, se houver áreas sujas associadas aos seus resultados do trace, o trace falhará e você receberá um erro informando que uma ou mais áreas sujas foram encontradas durante o trace. Se quiser ignorar as áreas sujas e ver os resultados do trace, potencialmente produzindo resultados incorretos, você pode desmarcar a opção Validar Consistência.
Como isso se aplica ao status da sub-rede? Se áreas sujas forem encontradas durante a atualização da sub-rede, a sub-rede será marcada como suja. No entanto, uma sub-rede limpa pode ser consistente ou inconsistente, dependendo se ela possui edições pendentes e não validadas desde a última atualização. Se houver áreas sujas não validadas no seu banco de dados, o sistema não sabe qual sub-rede (se houver) marcar como suja até que a edição seja validada. Uma vez que todas as suas áreas sujas sejam validadas, as sub-redes correspondentes são marcadas como sujas e todos os traces serão consistentes.
Qual impacto isso tem no gerenciamento das sub-redes? Significa que você não pode necessariamente olhar para o status de uma sub-rede e saber se ela é consistente. No entanto, você pode ter certeza de que se fizer um trace em uma sub-rede, receberá um erro se tentar analisar ou exportar uma sub-rede inconsistente, mesmo que a sub-rede indique estar limpa.
Conclusão
Agora que você terminou de ler este artigo, deve ter uma melhor compreensão dos benefícios e fluxos de trabalho associados ao gerenciamento de sub-redes e como o campo de status ajuda a guiá-lo nesses fluxos. Você também deve entender como o sistema gerencia esse campo e por que certas indústrias podem optar por gerenciar o campo de status apenas para alguns dos níveis na sua utility network.
