#941 Modelling Standard for Sub-Loops in a Water Plant

Donald Fisher Wed 21 Jul 2021

I am currently working on tagging some sites and have come across some water plants in which the common piping diverges to then feed multiple zones/air handlers. In each of these separate piping loops, there are the typical temperature and pressure sensors. I think it would be useful to be able to identify which points belong in which loop.

Is there already a pre-defined way to model this in Haystack4? I have not found anything in the documentation so far.

Thank you in advance for your feedback!

Brian Frank Wed 21 Jul 2021

Currently we don't model "loop" as an first class equipment entity (although certainly its been discussed in various ways many times). What we do is specify how to model a "pipe" using something like this:

secondaryLoop pipe equip

Then if there are multiple secondary loops the question would be is there some model difference between them you would tag? Or is it just that they are different entities that differ by display name only.

And then the points would be associated with that via the equipRef relationship. That is probably the most accurate way to model it today. Although I've seen other techniques and hopefully others can chime in.

Coen Hoogervorst Thu 22 Jul 2021

Hi Donald / Frank,

We are also trying to model the same type of equips. We also think the pipe equip does not really cover the situation. This because in our situation these equips can contain quite some points like:

  • (multiple) pump commands
  • temperature, pressure and flow sensors
  • valve cmd etc.

This means they have one or more actuators where the pipe suggest a more static equip. Further is the plantLoop choice tag a bit limitative because of the fixed number (3) of options and it does not register relationships. That is why we for now created our custom def for a distribution equip that looks like this:

def: ^distribution
is: ^equip

and create conjunct defs for example:

def: ^hot-water-distribution
is: [^distribution, ^hot-water]
inputs: ^hot-water
outputs: ^hot-water

(sorry: I am not 100% sure about the format, hopefully the example is clear enough)

This enables to use hotWaterRef / chilledWaterRef both:

  • from the distribution equip to the plant equip, and
  • from the consumer equip (for example an AHU) to the distribution equip, or
  • even from a distribution equip to another distribution equip.

Based on the refs we are able te create a tree view from the plant, to the distribution equips to the consumer equips.

  • @Donald: Maybe this can help you as a solution?
  • @Brian: we were wondering if this is a valid solution conform Haystack? We saw your proposals and assume this still should be working with the redesigned ref definitions. Are we correct?

Further we are interested if more people are feeling the same need for this type of equip. If so, we could think of giving this a bit more attention with more people from community.

Laurie Reynolds Fri 23 Jul 2021

This is an important function from a control system perspective and crops up in many situations. It's incorrect to think about it as primary/secondary unless the loops are completely independent. In order to optimise this system we have to model the overall flow and energy balance as a virtual entity consisting of multiple equipment IDs with interactive relationships. I've not seen a way of doing this in Haystack yet and am interested to understand how others have implemented.

Login or Signup to reply.