nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Beste Praxis für die Verwaltung von Gas-Messpunkten (oder Verbindungs- oder Abfangpunkten) und Ventilen als Subnetzwerk-Controller im Utility Network

CoronaGis

Hallo zusammen,

ich arbeite mit einem Esri Utility Network für ein Gasverteilungssystem und habe eine spezifische Frage zur besten Vorgehensweise im Umgang mit Gas-Messpunkten (PM) - (oder Verbindungs- oder Abfangpunkten) - und Ventilen als Subnetzwerk-Controller.

In unserem aktuellen System (geometrisches Netzwerk) werden Bezirke durch diese drei Objekte definiert:

Ventile
Messpunkte
Verbindungs- oder Abfangpunkte

Hier ist eine vereinfachte Darstellung des Szenarios:

Die grüne Linie stellt Bezirk A dar.
Die blaue Linie stellt Bezirk B dar.
Das Ventil (dargestellt als Schmetterlingssymbol) befindet sich an der Grenze zwischen Bezirk A und Bezirk B.
Der Messpunkt (PM) ist sehr nahe am Ventil (etwa 1 Meter entfernt) und gehört zu Bezirk B.

Wenn wir sowohl das Ventil als auch den PM als Subnetzwerk-Controller konfigurieren, führt dies zu Problemen bei der Subnetzwerk-Validierung, da das mittlere Rohr (X), das tatsächlich zu Bezirk B gehört, als neuer Mini-Bezirk definiert würde.

Meine Zweifel und Fragen sind:

Ist es empfehlenswert, nur Ventile als Subnetzwerk-Controller zu verwenden und Messpunkte (PM) als reguläre Assets zu behandeln, die logisch mit Ventilen verbunden sind? In welcher fcl/Asset-Gruppe/Asset-Typ ist es besser, die PM zu platzieren? Welche Regeln können wir verwenden (Junction-Edge oder den Messpunkt vom Rohrleitungssystem entfernen)?
Ist es empfehlenswert, nur Ventile als Subnetzwerk-Controller mit einem Attribut zu verwenden, das angibt, dass sie auch als PM verwendet werden?
Alternativ, gibt es eine beste Praxis, um Messpunkte und Ventile beide als Subnetzwerk-Controller zu modellieren, wenn sie so nah beieinander liegen und zum selben Bezirk gehören?
Wie haben andere Utility Network Implementierungen solche Situationen gehandhabt?
Gibt es spezifische Subnetzwerk-Regeln oder Konfigurationen, die Validierungsfehler in diesem Fall verhindern können?

Vielen Dank im Voraus für Ratschläge oder Beispiele!
Astrid

Finde mehr Beiträge mit dem Tag

Gas

Pipeline

Accepted answers

Ayan Palit

@CoronaGis Thanks for posting your use case with details and drawing. I encourage organizations to conceive the best way to model the network, rather than duplicate what a legacy system used to do. Utility Network has much broader modelling capabilities with greater possibilities.

Here are my comments:

Start at identifying the subnetworks for your gas distribution system. A great resource for this is: Managing Gas and Pipeline Networks: Creating Subnetworks
Is District similar to a pressure zone? If so, Compressor or Regulator are the prime candidates to act as the subnetwork controller for Pressure tier.
Controllable valves are the prime candidates to act as the subnetwork controller for isolation tier.
Measurement points do not impact network behavior and therefore not good choice for 'device' and hence 'subnetwork controller' (only devices can act as controllers).
Assuming use of the Gas and Pipeline Referencing Utility Network Foundation , PipelineDevice has a yes/no flag field, that can be used to indicate Measurement or SCADA indicator. Note this is simply an attribute, and doesn't impact network behavior.

Utility companies often have unique business requirements that drive the modelling decisions. Hoping others in the community will share their implementation advice.

All comments

Ayan Palit

Here are my comments:

Start at identifying the subnetworks for your gas distribution system. A great resource for this is: Managing Gas and Pipeline Networks: Creating Subnetworks
Is District similar to a pressure zone? If so, Compressor or Regulator are the prime candidates to act as the subnetwork controller for Pressure tier.
Controllable valves are the prime candidates to act as the subnetwork controller for isolation tier.
Measurement points do not impact network behavior and therefore not good choice for 'device' and hence 'subnetwork controller' (only devices can act as controllers).
Assuming use of the Gas and Pipeline Referencing Utility Network Foundation , PipelineDevice has a yes/no flag field, that can be used to indicate Measurement or SCADA indicator. Note this is simply an attribute, and doesn't impact network behavior.

Utility companies often have unique business requirements that drive the modelling decisions. Hoping others in the community will share their implementation advice.

RobertKrisher

It depends on the kind of valve between the two districts and what tier the subnetworks belong to. I'll call out @TomDeWitte for the final design intention of the model since it doesn't contain any definition of a district metering area. At the end of the day, it is your model, and you should configure it to meet your needs.

If we interpret your question through the way the model comes configured, I have to assume that the district is either a system, pressure zone, or isolation zone. You can look at the data model to see what devices are allowed to control subnetworks to infer how the model was designed to be used:

System - If these districts represent different systems and the PM is actually a meter, then this could be represented as a system subnetwork where the PM is a Custody Transfer Meter.

Pressure Zone - If the valve regulates pressure, this could be represented as a pressure subnetwork where the valve is a regular and the subnetwork controller. The PM would be a Pressure Monitoring Device.

Isolation Zone - If the valve is a Controllable Valve between two arbitrary areas of your network that you want to be isolation zones (it seems unlikely, but I'll mention it here). The

If it's some kind of metering district, then we'd be talking outside of the current configuration, and I'd want to defer to Tom before I exercise too much creativity.

TomDeWitte

When I looked at your diagram, I interpreted it to be at least 2 OVERLAPPING subnetworks. The Gas Measurement Meter (PM), I would guess to be what we call a custody transfer meter, which is one of the types of device our gas and pipeline industry model uses as a subnetwork controller to distinguish between two system subnetworks. The valve at the edge of your districts could be a pressure regulating valve, which our gas and pipeline industry model uses as a subnetwork controller to distinguish between two pressure subnetworks, or the valve could be an controllable valve used for emergencies, in which case we use that type of valve as a subnetwork controller to distinguish between two isolation zones. The pipe between the two devices can belong to more than one type of subnetwork. That pipe will participate in a system subnetwork, a pressure subnetwork and a isolation subnetwork.

Tom

Nimm an der Diskussion teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.