En nuestro artículo anterior vimos cómo puedes configurar una red de servicios públicos para realizar trazados de aislamiento para redes de gas y agua. En ese artículo vimos cómo el sistema puede identificar equipos que pueden usarse para aislamiento, junto con cómo configurar nuestra red para usar un campo de posición normal para identificar si una válvula está abierta o cerrada. En este artículo te mostraremos cómo configurar una red de servicios públicos para gestionar zonas de presión. Los ejemplos descritos en este artículo son para una red de gas, pero las técnicas y conceptos son aplicables a cualquier red presurizada.
¿Qué es una zona de presión?
Una parte importante de la gestión de la distribución de recursos a los clientes en un sistema presurizado es la creación y análisis de zonas de presión. Los ingenieros en una utility dependen de fórmulas complejas y software de ingeniería para asegurar que el sistema opere como se pretende, sin embargo, a menudo confían en el modelo de red almacenado en un GIS para construir estos modelos. Es responsabilidad del analista GIS asegurarse de que los datos en el GIS se mantengan actualizados y precisos para que ingenieros, planificadores y operadores de red puedan tomar decisiones informadas usando GIS.
Las zonas de presión juegan un papel importante en las responsabilidades diarias de operadores e ingenieros. Para que operaciones e ingeniería usen GIS, deben tener confianza en que contiene un registro preciso de las características que regulan y pertenecen a cada zona de presión. Lea el Entendiendo las Zonas de Presión artículo para aprender cómo usar GIS para gestionar y analizar zonas de presión.
Históricamente, los clientes han mantenido información sobre zonas de presión como un atributo en tuberías, o usando una capa poligonal en su GIS que muestra la extensión de cada zona. Esta información puede verse bien en un mapa pero no funciona en casos donde hay múltiples zonas de presión en la misma calle o cuando un usuario crea inadvertidamente una conexión entre tuberías en diferentes zonas de presión. Escenarios como este son donde una utility network proporciona valor, ya que puede configurarse para modelar y validar las extensiones de las zonas de presión.
La utility network creada usando la herramienta Migrate To Utility Network puede incluir un solo nivel para gestionar sistemas de distribución por defecto. Estos grandes grupos de tuberías comparten una fuente común de gas, agua o energía. Para asignar una zona de presión a una tubería, necesitamos configurar un nivel para representar las zonas de presión. Si tu domain network está configurado como partitioned cada característica solo puede pertenecer a un único nivel, por lo que debes elegir entre rastrear el nivel del sistema o las zonas de presión. Las domain networks de gas, agua y calefacción distrital suelen modelarse usando una red jerárquica por esta razón. Las redes jerárquicas permiten que cada característica participe en múltiples niveles dentro de la red. Esto no se limita solo a sistemas y zonas de presión. Algunos clientes también usan GIS para rastrear zonas de aislamiento, estructuras de protección catódica o incluso áreas con medidores distritales.
Al agregar un nuevo nivel a una utility network, debes hacerte las siguientes preguntas:
- ¿Cuál es el propósito de este nivel?
- ¿Qué características gobiernan o regulan (fuentes o sumideros) este nivel?
- ¿Qué características están permitidas pertenecer a este nivel?
- ¿Hay estadísticas que quiero calcular para las subredes en este nivel?
Con esta información en mano, estás listo para comenzar a configurar un nuevo nivel. El primer paso es configurar ciertas características para actuar como fuentes o sumideros en el nivel. En la utility network, estas características se llaman subnetwork controllers.
Configuración del Subnetwork Controller
Antes que una característica pueda actuar como subnetwork controller, su tipo de activo debe configurarse para actuar como subnetwork controller en un nivel dentro de la red. Puedes encontrar una lista completa de los pasos en la página set a subnetwork controller en la ayuda en línea, pero los cubriremos brevemente aquí.
- Asignar una configuración terminal
- (opcional) Eliminar reglas previas
- Agregar reglas
- Asignar una categoría de red
- (opcional) Agregar un nivel
- Establecer la definición del subnetwork
Si ya has identificado el equipo que impacta el flujo o la presión como subnetwork controllers cuando ejecutaste la herramienta Migrate To Utility Network, entonces tus tipos de activos ya están configurados para actuar como subnetwork controllers, y puedes avanzar directamente a agregar un nivel.
Para comenzar, necesitamos asignar una configuración terminal a los tipos de activos que queremos asignar como subnetwork controllers. Cuando una línea se conecta a un dispositivo con terminales, debe especificar a qué terminal está conectado. La capacidad para diferenciar entre conexiones es necesaria al crear subnetwork controllers. Por ejemplo, sin el uso de una configuración terminal y conexiones terminales, un regulador no podría distinguir entre las tuberías conectadas a su entrada y las tuberías reguladas conectadas a su salida.
La herramienta Migrate To Utility Network incluye tres configuraciones terminales genéricas:
- Fuente Direccional – Esta configuración terminal se usa cuando un dispositivo en una red basada en fuentes necesita terminales aguas arriba y aguas abajo.
- Sumidero Direccional – Esta configuración terminal se usa cuando un dispositivo en una red basada en sumideros necesita terminales aguas arriba y aguas abajo.
- Bidireccional – Esta configuración terminal se usa cuando no hay un terminal explícito aguas arriba o aguas abajo. Puede usarse tanto en redes basadas en fuentes como en sumideros.
Elegir la configuración terminal correcta es importante para asegurar que el trazado funcione correctamente. En un sistema presurizado, la mayoría de los controladores de red tienen una configuración terminal explícita aguas arriba y aguas abajo. Esto significa que agua, gas, etc., solo pueden fluir desde la tubería del terminal aguas arriba hacia la tubería del terminal aguas abajo. Sin embargo, si tienes equipo que puede configurarse para no regular el flujo en campo deberías usar la configuración terminal Bidireccional que permitirá que la presión no esté regulada mientras fluye a través del dispositivo. En nuestro ejemplo configuraremos nuestro dispositivo como Bidireccional porque varias estaciones reguladoras mantienen un circuito de alta presión en nuestro sistema de distribución.
Nota: Si esta herramienta se ejecuta usando ArcGIS Pro 3.5 o posterior, necesitarás eliminar cualquier regla existente asociada con el tipo de activo usando la herramienta Delete Rule antes de poder establecer su configuración terminal.
Una vez hayas cambiado la configuración terminal del dispositivo, necesitas crear reglas que te permitan definir qué tipos de tuberías pueden conectarse a cada terminal. En este ejemplo las estaciones reguladoras tienen tuberías distribuidoras tanto en el lado entrada como salida del dispositivo, por lo que agregarás reglas para cada lado.
Nota: Cuando una tubería puede conectarse a más de un terminal en un dispositivo, cada tubería debe especificar a qué terminal está conectada en el dispositivo. Si no lo hace, esto crea un error ambiguo de conectividad que debe resolverse usando la herramienta Modify Terminal Connections.
Si estuvieras agregando reglas para estaciones fronterizas municipales o medidores transferencia custodia, solo permitirías tubería transmisión en el terminal aguas arriba y tubería distribución en el terminal aguas abajo. Si no estás seguro qué reglas agregar, consulta con un ingeniero u otra persona con conocimiento del sistema para ayudarte a tomar la decisión correcta.
En el caso modelos hidráulicos (agua), bombas o válvulas reductoras tendrían tuberías distribuidoras tanto en los terminales aguas arriba como aguas abajo.
Ahora que el regulador en nuestro ejemplo tiene terminales que le permiten diferenciar entre las conexiones tubulares a cada lado, puedes comenzar a configurarlo como subnetwork controller. El siguiente paso es asignar una categoría de red al tipo activo para permitirle servir como subnetwork controller. Para esto usa la herramienta Set Network Category:
El siguiente paso es definir qué tipo(s) de subredes puede controlar el dispositivo usando la herramienta Set Subnetwork Definition. El dispositivo debería servir como subnetwork controller para subredes zona presión (pressure zone subnetworks), pero primero debe crearse un nivel que represente las zonas presión (pressure zones). Esto se hace usando la herramienta Add Tier.
Agregando un nivel zona presión (pressure zone tier)
Ahora que tus tipos activos tienen categoría red (network category), terminales y reglas para actuar como controladores red (network controllers) estás listo para agregar tu nivel (tier) a la red (network). Usa la herramienta Add Tier para agregar un nuevo nivel (tier) a la red (network).
Puedes aprender más sobre estas configuraciones en el tema Niveles (Tiers)en la ayuda online. Debido a que nuestra utility network ya contiene un nivel (tier) para el sistema distribución con rango predeterminado 1, establecemos rango 2 para las zonas presión (pressure zones). Esto significa que las zonas presión están más profundas en jerarquía red (network hierarchy) que nuestras subredes sistema (system subnetworks).
Como ya tenemos un campo que almacena nombre subred sistema (system subnetwork name), especificamos uno nuevo llamado PressureSubnetworkName para almacenar nombre zona presión (pressure zone). No te preocupes por crear este campo antes; la herramienta lo agregará automáticamente por ti.
Ahora que hemos agregado un nivel zona presión (pressure zone tier) a nuestra red necesitamos definir las características que actúan como controladores subred (subnetwork controllers) y participan en esa subred junto con reglas sobre cómo debe realizarse trazado subred (subnetwork trace). Para esto usamos herramienta Set Subnetwork Definition. Esta herramienta tiene muchos parámetros así que se recomienda leer página definición subred (subnetwork definition)en ayuda online antes ejecutar esta herramienta sobre tu red.
Para sección Características Válidas y Objetos Válidos especificamos todos los tipos activos (asset types) en nuestra red con solo unas pocas excepciones.
Para parámetro Controladores Subred Válidos seleccionamos solo nuestras estaciones reguladoras y cualquier otro equipo configurado para actuar como controladores subred (subnetwork controllers) para zonas presión.
El parámetro Aggregated Lines for Subnetline Feature Class se utiliza para identificar qué líneas se usan para crear la geometría de la línea de subred cuando se ejecuta la operación de actualización de subred. Debido a que esta línea se usa para visualizar zonas de presión cuando se aleja a escalas pequeñas, no queremos incluir ningún tipo de activo que contenga muchas líneas pequeñas. En el caso de nuestro sistema de tuberías, no queremos incluir servicios, ramales o líneas usadas exclusivamente para protección catódica.
Nota: Las entidades excluidas de la línea de subred aún se consideran al calcular resúmenes para la subred.
Debido a que su red no incluye estructuras ni contenido no espacial, querrá deshabilitar o desmarcar las opciones para incluir contenedores, contenido y estructuras. También querrá tratar los dispositivos abiertos como barreras usando una barrera condicional, tal como hizo con el nivel del sistema.
No se preocupe por completar los resúmenes al configurar inicialmente su definición de subred. Puede cambiar su definición de subred más adelante para incluir resúmenes sobre cosas como longitud de tubería, volumen y número de conexiones de servicio.
El parámetro aggregated lines for subnetline feature class se utiliza para identificar qué líneas se usan para crear la geometría de la línea de subred cuando se ejecuta update subnetwork. Debido a que esta línea se usa para visualizar zonas de presión cuando se aleja a escalas pequeñas, no queremos incluir ningún tipo de activo que contenga muchas líneas pequeñas. En el caso de nuestro sistema de tuberías, no queremos incluir servicios, ramales o líneas usadas exclusivamente para protección catódica.
Política de actualización de Subnetwork
La última sección principal para configurar en la definición de subred es la política update subnetwork. Esto le da control sobre cómo se actualiza la información de subred dentro de su utility network. Hacer cambios en estas configuraciones no es una decisión simple para muchos clientes, ya que implica hacer concesiones entre conveniencia y rendimiento. Aquí daremos una breve visión general de estos puntos decisivos y le referiremos a discusiones más detalladas donde estén disponibles.
Si eligió incluir contenedores, contenido y estructuras en su red, se mostrarán opciones adicionales para especificar si desea actualizar los contenedores structure/domain network. Esto determina si los campos Subnetwork name y Supported subnetwork name en sus estructuras y contenedores serán actualizados cuando contengan o soporten una entidad que pertenezca a una subred. Esto le permite usar la herramienta Select By Attributes para identificar entidades que soportan una subred sin ejecutar un rastreo. Aunque esto es conveniente para propósitos de informes, también significa que la operación update subnetwork tardará más en ejecutarse porque puede haber cientos de miles de entidades adicionales que necesitan ser actualizadas.
La siguiente opción a discutir es si el tier debe gestionar el campo IsDirty (Status), puede encontrar un análisis profundo sobre gestión del estado en el sitio Esri Community. Este campo se usa para indicar si ha habido ediciones validadas en su utility network que hayan impactado una subred particular. Esta opción está configurada en False por la herramienta Migrate To Utility Network porque puede tener impactos en el rendimiento.
Cuando esta propiedad está habilitada, el utility network debe realizar uno o más rastreos para identificar qué subnetworks están impactadas cada vez que valida ediciones. El costo en rendimiento es relativo al tamaño de su mayor zona de presión. Si tiene zonas de presión que contienen cientos de miles de entidades (tuberías, uniones y dispositivos), debería mantener este parámetro deshabilitado. Sin embargo, si todas sus zonas de presión son más pequeñas que eso, puede considerar esperar unos segundos adicionales durante la operación validate network topology como un costo relativamente pequeño comparado con los beneficios para el aseguramiento de calidad. Si no está seguro qué opción elegir, debería dejar esta propiedad deshabilitada hasta estar seguro sobre el tamaño e impacto en rendimiento de sus zonas de presión. Esta opción casi siempre debe estar configurada en false para system tiers, ya que pueden contener fácilmente todo su conjunto de datos.
Tener esta propiedad habilitada le permite enfocar sus esfuerzos de aseguramiento de calidad solo en las subnetworks que han sido modificadas y le permite identificar fácilmente qué circuitos han sido limpiados y están listos para ser extraídos a un sistema externo como un OMS.
La configuración más eficiente es dejar esta opción deshabilitada. La configuración más beneficiosa para aseguramiento de calidad e integraciones es habilitar la gestión del estado.
La última opción a considerar es qué modo eventing usar para su default y versiones nombradas. Esta decisión afecta el rendimiento del update subnetwork y si el campo subnetwork se completa durante ciertos flujos de trabajo. Hay un análisis profundo sobre modos eventing en el sitio Esri Community. A continuación sigue una versión muy simplificada de la discusión.
Cuando una subred se actualiza sin eventos correrá más rápido. Hay varios factores que contribuyen a esto, pero una razón es que las reglas atributivas y el seguimiento del editor no se activan. La mayor desventaja es que al actualizar update subnetwork en una versión nombrada, no todas las entidades garantizan tener actualizado su nombre de subred acorde a la subred a la que pertenecen.
Cuando una subred se actualiza con eventos, la primera vez que se ejecuta update subnetwork tomará más tiempo que las siguientes ejecuciones. Las actualizaciones subsecuentes también pueden tardar más si tiene reglas atributivas configuradas y está actualizando grandes cantidades de entidades. El beneficio al actualizar subnetworks con eventing habilitado es que cuando update subnetwork se ejecuta en una versión puede garantizarse que el campo nombre_subred esté correctamente completado para todas las entidades pertenecientes a esa subred.
Nota: A partir de ArcGIS Enterprise 11.4 y ArcGIS Pro 3.4, el costo en rendimiento por activar reglas atributivas puede mitigarse usando el nuevo comportamiento Triggering Fields en las reglas atributivas.
La configuración más eficiente es dejar el modo eventing en actualizar sin eventos. La configuración más útil para aseguramiento de calidad es habilitar el modo eventing cuando esté en versiones nombradas y asegurarse que tenga correctamente configurados los triggering fields en todas sus reglas atributivas. Cuando trabaja en un geodatabase móvil o archivo, la configuración recomendada es actualizar sin eventing, ya que esto permite que las primeras y subsecuentes ejecuciones del update subnetwork sean rápidas mientras trabaja con conectividad y problemas de aseguramiento de calidad.
Habilitando controladores de subred
Una vez hecho esto, el último paso restante es identificar los controladores de subred para cada zona de presión en su sistema. Para hacer esto necesitará visitar cada controlador de subred en su red (en este ejemplo estaciones reguladoras) y usar el panel Modify Subnetwork Controller para asociar cada terminal del dispositivo con la respectiva zona de presión a cada lado. Si tiene errores ambiguos de conectividad en su dispositivo, debe usar el panel Modify Terminal Connections antes de habilitar el controlador de subred para asegurar que está habilitando el terminal correcto como controlador.
Al comenzar este proceso puede ser difícil saber por dónde empezar, ya que puede tener docenas o cientos de zonas de presión. Esto se complica aún más cuando una zona está anidada dentro otra zona. La tentación suele ser comenzar por las zonas con mayor presión en el centro del sistema e ir hacia afuera; el problema con este enfoque es que tan pronto crea su primera zona consumirá todas las zonas anidadas aguas abajo porque esos controladores aún no han sido configurados para regular presión. En cambio, suele ser más fácil comenzar creando controladores en los bordes del sistema e ir hacia adentro. De esta manera no necesita preocuparse por zonas anidadas y si comete un error probablemente solo necesite investigar conexiones con una o dos zonas vecinas.
Si hace zoom en la estación reguladora al lado occidental del territorio del servicio puede ver que la entrada/salida del regulador no es inmediatamente obvia. Sin embargo, descifrar esto puede facilitarse activando etiquetas para las presiones establecidas en cada tubería.
De manera similar, ayuda observar el terminal al cual está conectada cada línea. De hecho, al crear controladores debe siempre verificar que las conexiones terminales entre su controlador y dispositivo sean correctas. Si no están correctamente configuradas causará problemas al rastrear sus subnetworks. Puede ver la conexión terminal usando el panel Modify Terminal Connections en cada línea conectada o, si es particularmente ingenioso, puede crear una clase etiqueta en la capa para mostrar esta información.
Debido a que asignó una configuración Bi-directional terminal, los terminales están especificados como Side 1 y Side 2. Si tuviera una configuración directional terminal querría ver la tubería 720 psi en el terminal upstream y la tubería 60 psi en el terminal downstream. Ahora que confía en las conexiones terminales del regulador puede crear las subnetworks(s). Use el panel Modify Subnetwork Controller en el regulador para crear una subred para la tubería 60 psi.
Asegúrese que el tier esté configurado como Pressure Zone y seleccione el terminal conectado a la tubería 60 psi. Debido a que una subred puede tener múltiples controladores necesita identificar este controlador único dentro dela subred. Si tiene un campo nombre único puede usarlo aquí; si no puede dejarlo vacío y el sistema usará el global id del feature. Finalmente ponga el nombre dela zona presión en el campo nombre_subred.
Una vez habilitado el terminal como controlador dela subred debe validar la topología dela red del feature antes deque pueda usarse.
Después de validar la topología, puedes usar la herramienta de rastreo para trazar la subred y validar que se devuelve el resultado correcto.
Una vez que hayas verificado que el rastreo es correcto, utiliza la herramienta Actualizar Subred para crear la subred por primera vez.
Una vez que la subred se haya actualizado con éxito, puedes usar el panel Encontrar Subredes para visualizar la subred. Este panel también puede usarse para rastrear, actualizar y revisar el estado de tus subredes.
Una vez que hayas repetido este proceso para todas tus zonas de presión, deberías repetir los procesos de aseguramiento de calidad que seguiste para los sistemas para garantizar que cada característica esté asociada con la zona de presión correcta.
Conclusión
En este artículo aprendiste cómo configurar tu utility network para modelar controladores de subred para zonas de presión. Aprendiste sobre la configuración requerida para permitir que una característica sea un controlador de subred, junto con cómo tus definiciones de subred afectan el comportamiento de tu sistema.
Ahora que has creado zonas de presión para tus datos, puedes usarlas para muchos tipos de análisis. Si buscas inspiración, consulta el artículo Understanding Pressure Zones. Tu viaje de configuración no tiene que terminar aquí. Si buscas más cosas para configurar, considera lo siguiente:
- Realizar rastreos de aislamiento usando las nuevas zonas de presión
- Crear configuraciones de rastreo usando tus zonas de presión
- Agregar funciones resumen a tus definiciones de subred (nivel de presión o sistema)
- Revisa las configuraciones de eventing y state management de tu nivel de presión
Si quieres saber más sobre cómo usar el utility network para gestionar redes presurizadas, como sistemas de gas y agua, por favor explora la serie Learn ArcGIS Utility Network for Water Utilities y serie Learn ArcGIS Utility Network for Gas and Pipeline. Esta serie incluye tutoriales y artículos que demuestran cómo abordar las necesidades de estas industrias usando el utility network.
Como siempre, si tienes alguna pregunta o comentario asegúrate de hacerla en el sitio Esri Community!
