What defines subnetwork limits beyond controllers?

[Andy_Morgan]

I have not yet deployed a UN to production environment. Currently working in test environment and trying to establish the subnetworks for our Water UN (Hierarchical tier). In many ways, the schema is very close to the ESRI Water UN Foundation database, which is what I'd like to point to for this question.

For creating subnetworks, I realize you must assign one or more subnetwork controllers as the point of entry, but what I'm not understanding with the ESRI UN foundation shown below is how System Valve / Pressure Zone features are the barrier points for defining a pressure plane subnetwork. In the network properties (2nd screenshot), it's Pressure Valve / Pressure Reducing features that are controllers. So where is it defined in the network to indicate that System Valve / Pressure Zone can also be a start/end subnetwork barrier? I don't think "Isolating" category is relevant for a pressure subnetwork. I don't see anything else, and cannot find any documentation, to know exactly how this works.  

[RobertKrisher]

Features with that subnetwork categories are capable of being controllers, but to make them controllers you must use the Modify Subnetwork Controllers pane.

The barriers are defined in the subnetwork definition for that tier. Any feature that meets the condition barriers defined for that subnetwork will be treated as a barrier. In the water utility network foundation a pressure zone treats features that are closed or features that are proposed as barriers. A system valve between pressure zones is typically kept closed, meaning it will act as a barrier, but if you set the pressure zone system valve to be open it will no longer act as a barrier (which will likely result in inconsistent subnetwork names between the pressure zones on either side of it).

[Andy_Morgan]

Right, I understood how to set subnetwork controllers and the general concept of barriers, but my problem was that I didn't know specifically where/how exactly it was defined and how it could be updated. I was expecting the barriers to be defined in the network properties with explicit references to System Valve / Pressure Zone (and maybe a few other asset group/type combos), whereas after reading more documentation and digging around I now realize the P: Device Status attribute ("presentstatus" field) being set to "Closed" is how the pressure subnetwork's configuration is defined. Maybe these things are obvious if you already know every in and out of a UN, but it took some piecing together for me. It's so easy to forget such details if you took a training course 6 months ago and are just now focused on this part of UN design.

I removed the normal and present status fields, so I guess those should be added back into my UN. At least present status. Is there an alternative way to define the barriers that might make things simpler if we don't want to track current valve status of open/closed? 

Instead of "P:Device Status = Closed..." what about this type of where clause below?

(Asset Group = System Valve and Asset Type = Pressure Zone) or (Asset Group = Pressure Valve and Asset Type = Pressure Reducing)

Is that a terrible idea? Here's my rationale. We know the System Valve / Pressure Zone valves are pretty much always closed. Sure, they might be opened temporarily for a rare emergency, but I'm thinking our subnetworks are better off being defined with the normal case (99.9% of the time) as a static type definition. We aren't using the UN for water modeling level accuracy. As long as we can build the subnetworks to delineate pressure planes and run isolation traces, that's the main goal. 

[PierreloupDucroix]

Hello, you cannot create where clauses with nested conditions like in your example.

But the proper way to do this is to set up a new Network Category and apply it to the two assetGroup/assetType you mentioned and use "Category = specific value 'YourCategory'".

This way with only one clause you can have multiple barriers

[Andy_Morgan]

Hi @PierreloupDucroix, thanks for the tip. While that certainly does help for accomplishing the goal of changing the barrier criteria, I guess my final question for anyone reading this is about defining the subnetwork boundaries. Putting aside the where clause syntax and thinking from an overall best practice for UN design, is there any important reason we cannot change our condition barriers to be dependent on asset group / type combinations (more static in nature) instead of open/closed status of the valves (more dynamic)?

I assume it's just a question of how realistic you want to be, right? If our engineers define the pressure planes by valve function rather than what's closed/open at any given second, then it seems like I need to define it by Water Device belonging to certain Asset Group / Asset Type values. 

This is a totally subjective call by the organization, right? We may be limiting ourselves somewhat, but that's how our engineers have delineated it for us until now. Some of our Geometric Network "Division / Pressure Plane" valves are showing as CurrentPosition = "Open". Whether the valve is open or closed in real-life right now doesn't matter. Neither does the attribute value. I just know we've been told where one pressure plane stops and another begins, and it's dependent on the location of "Division / Pressure Plane" valves, nothing to do with open/closed status of valves. I need to be consistent when moving to the UN.

[PierreloupDucroix · Accepted solution]

"is there any important reason we cannot change our condition barriers"

Defining the condition barriers and so the subnetwork definition is up to you. You can define this the way your network works in real life or in terms of pure network management.

Utility Network has this flexibility so that you can easily change subnetwork definition, but remember that once you are in production you should not change that, so you have to think about it during your migration process.

Note that if you choose to use the assetType as the condition barrier, then every pressure zone or pressure reducing valve will stop the subnetworks' propagation. If you want only certain valves to act as barriers, then you will have to either create a new assetType that will apply only to these valves, or to create a field with a network attribute (like open/close) that will reflect the specific type of valve (ex : isPressureBarrier True/False) and use it in the subnetwork definition.