I propose the following tags for pumps, compressors etc that are intended to operate in a Lead/Lag sequence for the purpose of generating equivalent equipment operating hours:

1. leadLag
2. leadLagLag
3. leadLeadLag

leadLag - is for two pieces of equipment that alternate run times

leadLagLag - is for three pieces of equipment that alternate run times with only one piece of equipment intended to operate normally

leadLeadLag - is for three pieces of equipment that alternate run times with two pieces of equipment intended to operate normally

What if we did this. We use leadLag:3, which tells you that there are 3 things that will be in leadLag.

IE...

Secondary Pumps would have a tag called leadLag:3

Then the actual pumps would have a ref to the leadLagRecord. We could call it leadLagRef


---
name:Secondary Pumps
id: secondaryPumps
leadLag:3
---
name:Pump-1
id: secPump1
leadLagRef:secondaryPumps
---
name:Pump-3
id: secPump2
leadLagRef:secondaryPumps
---
name:Pump-3
id: secPump3
leadLagRef:secondaryPumps


This would work for anything. 

Could this be done in a way that makes it is obvious whether normal operation is with one or two of the Secondary Pumps?

I think if you wanted to do that, then that would be a custom tag.

I wouldn't recommend making that a haystack standard, but you could name it leadLagNormlOp:2

@Jason, Unless you have had any other thoughts on this I change my proposal to the simpler:

leadLag

tag to be used as a marker for equipment that will alternate run times for the purpose of generating equal operating hours

@denis I agree with you let's make it leadLag is a marker tag that describes the equipment group to being able to be rotated somehow.

IE... This would be for a group of pumps, or fans, chillers, etc... You would have to have more than 1, but you couldn't have any number above that.

In FIN Stack we standardized on leadLagStages:3 (numeric tag), and we have a leadLagRef:@1234. I propose that we also do that here as a standard in Haystack.

So If you have 2 pumps, each pump would need a leadLagRef to something that has the leadLag marker tag. If there are only 2 pumps than the leadLagStages tag is not required, it's optional.

If you have more than 2 pumps, let's say you have 4 pumps, then each pump would need a leadLagRef, and that record should have a tag called leadLagStages:4.

@jason I am wondering if your initial idea to use leadLag:3 might be better than leadLagStage:3

The reason I ask this question is because the leadLag reference does not indicate "stages" of heat/cool etc, but is a reference for equipment that is rotated for the purpose of generating equal operating hours.

Jason,

I am using your recommendation in the following way:

I put the leadLag marker on a group of pumps (and now I realize I don’t need to specify how many pumps are in the leadLag group).

If the group is tagged with leadLag only, there should never be more than one pump operating at once and we should see equal run times on the pumps over time.

On a current project, there there are 3 secondary pumps of equal size and I use leadLagStage:2 to indicate 1 or 2 pump operation is expected under normal conditions.

Denis.. I like that solution. This is really helpful in FIN Stack for people that want to automate their programming. All they do is add those tags, and everything starts working.

Brian... Any ideas on when we will have all of these as a standard.

Hi Jason and Denis,

interesting conversation, it really is a tough nut to crack given all the different combinations of plant equipment that are around.

Just before this gets adopted I was wondering if one of you could post a little more detail on the problem(s) you are trying to solve with this model?

It seems as if the conversation started with pumps and compressors and run-hours and has now expanded out chillers and fans.

It would be good to know, for example, if these tags would be used in a control/optimisation situation, or analytics to do fault diagnosis or even graphics.

I'm sure in Jason's case he'll say "yes" to all of the above! :)

Is this proposal confined to pumps and compressors still or is it being made more generic? When we say compressors are we talking compressor staging on a chiller or on a rooftop packaged air conditioning unit?

Looking forward to your thoughts.

Cheers, Richard

Richard,

My experience with this approach has been to drive reporting and analytics for groups of hot water and chilled water pumps in central plants.

It is applicable for groups of "equally sized" equipment such as

• air compressors
• domestic water pumps
• process water pumps
• exhaust fans
• boilers
• chillers etc.

serving common loads where it is desired to generate equal operating hours.

When I create a group of this type equipment, I tag it so I know it is expected to operate either:

• In a basic “Lead/Lag” mode with only one piece of equipment operating at once
• In a Lead/Lag mode that incorporates Staging to meet a fluctuating demand.

@Richard - Sorry to take so long to get back to you.

Here are my thoughts.

1. by the leadLag tag one wants to know that there are multiple somethings, and what the order of those somethings are.
2. Some times those somethings are always in the same order, and some times they aren't. For example if you have a Package unit, maybe compressor1 always is stage-1, and compressor-2 is always stage-2. But for most everything else, like Exhausts fans, pumps, boilers, chillers, etc.. the order that they run in changes. 3.I think some people think lead/lag is just 2 things, in my mind lead/lag means more than 1 thing, and that those things are staged some how.
3. Typically there are 3 ways that people decide the order of these. A. Manually, they just set pump1:1, pump2:2,pump3:4, and pump4:3. B. once a month or some time interval the system orders them based on the least amount of runTime, so the pump that runs the longest goes to the end of line, and so on. C. The same idea as B except that it uses starts instead of runTime.

Yes Richard for sure we should design this to be able to work with Control Logic too, not just Analytics :}

Where do you guys see the holes with just have the main equip have a marker tag called leadLag, and have the things that are being staged, each have a leadLagStage tag?

Also Richard I don't think it's confined to compressors or anything, I think it could be used for anything and everything. For Example you could use this to do a soft start for package units. Or you could use it to stage lighting etc.. You could also have multiple items have the same leadLagStage too. For example let's say you had 50 lights, and you wanted to have 5 stages for those lights, the 1st 10 lights could have a leadLagStage:1, and the 2nd 10 could have leadLagStage:2, etc...

I think also the leadLagStage tag could be on a point, or equip. Most of the time we don't trend that value anyways, so we prefer to put the leadLagStage on the equip, but in the case that you want to trend that point, you would want the leadLagStage to be a point.

I would like to throw out a scenario that relates to both the lead/Lag concept as well as several other concepts which have been in discussion to try to understand how these concepts may come together.

Let's say we have 5 heating pumps named P1 through P5. P1, P2, and P3 provide hot water to say a group of fan coils and are connected directly off the primary loop of a group of boilers. P4 and P5 provide hot water to a group of make up air units and are also connected to the same set of boilers, however they are connected through a heat exchanger and this loop contains 40% propylene glycol. P1, P2, and P3 are designed to always run 2 pumps in parallel and have 1 on standby. P4 & P5 run one at a time with the other on standby. All pumps are connected to VFDs and are set to maintain a constant loop head pressure.

Available Points

• P#- run sensor
• P#- run cmd
• P#- speed cmd
• makeup loop- delta pressure sensor
• makeup loop- delta pressure sp
• makeup loop- lead pump select
• fan coil loop- delta pressure sensor
• fan coil loop- delta pressure sp
• fan coil loop- lead pump select

So correct me if I'm wrong, but with the current standard each pump would reference the same boilerPlant or hotWaterPlant and I suppose each of the loop related tags just fall under the boiler plant? So if a leadLag or leadLagStage tag was added to each pump how would the pumps related to the makeup loop be differentiated from the pumps that are related to the fan coil loop?

One concept which had been discussed on several other threads was to model a loop as it's own entity. I think that concept ties in well with both the leadlag issue as well as the antifreeze issue. I would think that this would end up looking something like this:

Plant

• dis: Boiler Plant
• id: plant1
• boilerPlant

Makeup Loop

• dis: Fan Coil Loop
• id: Makeup_Loop
• secondaryLoop
• boilerPlantRef: plant1
• leadLagStage: 1
• water
• antifreeze: propylene 40%
• heat
• equip

Points

• delta, pressure, sensor, equipRef: Makeup_Loop, loopRef: Makeup_Loop, boilerPlantRef: plant1
• delta, pressure sp, equipRef: Makeup_Loop, loopRef: Makeup_Loop, boilerPlantRef: plant1
• dis: lead pump select, enum: P4 Lead, P5 Lead equipRef: Makeup_Loop, leadLadRef: Makeup_Loop, loopRef: Makeup_Loop

Pump Example

• pump, index: 4, id: P4 equip, leadLagRef: Makeup_Loop, loopRef: Makeup_Loop, boilerPlantRef: plant1

Points

• run, sensor, equipRef: P4, leadLagRef: Makeup_Loop, loopRef: MakeupLoop
• run, cmd, equipRef: P4, leadLagRef: Makeup_Loop, loopRef: MakeupLoop
• speed, cmd, equipRef: P4, leadLagRef: Makeup_Loop, loopRef: MakeupLoop

I'm sure I missed some tags, but I think it shows the concept of grouping loop related traits and points to the loop entity and having the individual pieces of equipment reference to the loop for those common pieces of information.

Any thoughts?

@Leroy

I agree that loops such as these naturally end up becoming their own entities that can be described/reported on based on the "loop related traits" and "loop controls".

For smaller residential radiant systems I always model the loop as its own piece of equipment. It has its own circulation pumps, set point, drawdown and actual temperatures. I even model the buffer tank on the loop as it is integral to maintaining the loop temperature.

For control purposes, the loop monitors zones to determine if the loop pumps should be running and if temperatures should/are being maintained. For combined radiant heating and cooling systems, the loop determines the overall mode. The loop makes a general call for heating or cooling from the "plant". The plant determines the best way to supply that heating or cooling request. This could be geothermal, heat pump or boiler.

I think it is essential to model loop as its own piece of equipment, especially for control purposes.