There has been quite a bit of discussion around enhancements to the heating plant points, which includes boilers, storage tanks, pumps and other equips.

The first thing that needs to be decided is at the plant level, and we have a couple of choices.

It has been suggested that we adopt hotWaterPlant and steamPlant markers for the plant as opposed to using boilerPlant since boilers are really just one piece of equipment that makes up the plant. However, this deviates slightly from what has been done previously for "chillerPlant". The recommendation is to change chillerPlant to chillerWaterPlant in addition to adding the new heating plant tags, hotWaterPlant and steamPlant.

As far as the points, they would closely parallel what has already been done for the chilled water points, such as hot water leaving temp sensor or steam leaving pressure sensor.

In summary:

1. add hotWaterPlant tag
2. add steamPlant tag
3. change chillerPlant to chilledWaterPlant
4. model the other hot water and steam plant points to parallel what has been done on the cooling side of the central plant.

At this time we would like your input on this idea with a more detailed list of new plant and equip points to follow.

@Paul These descriptions for the tags make sense to me.

hotWaterPlant models the entire system of equipment used to generate hot water. steamPlant models the entire system of equipment used to generate steam. chilledWaterPlant models the entire system of equipment used to generate chilled water.

It may also be appropriate to bring a point from Topic #127 into the conversation at this time.

Michael Reining raised the example of multiple chiller plants throughout a district chilled water system…….and asked......."what would be above the chiller plant to bring it to a district wide level?"

I propose interConnected as a tag to model a group of chilledWaterPlants, hotWaterPlants or steamPlants.

interConnected plants may be located (1) in separate buildings, or (2) in separate parts of the same building.

interConnected plants stage equipment such as boilers, chillers, pumps on/off to meet the demands of equipment connected to a common steam, hot-water or chilled-water loop.

Thanks, @Dennis.

I understand and agree with Michael's need for a district plant / central plant type tags. The more detailed proposal does include these once we have agreement on the initial plant concepts. I will give your other proposal some thought.

This is perhaps the biggest topic we have moving along right now: flushing the model for boiler/heating plants.

Paul's proposal is summarized as follows:

1. Plant terminology is based on their output, not their primary equipment (chiller, boiler, etc)
2. There are three types of plants:
   1. chilledWaterPlant outputs chilled water
   2. hotWaterPlant outputs hot water
   3. steamPlant outputs steam
3. This is a breaking change from existing terminology and will replace existing chillerPlant tags with chilledWaterPlant

Unless there is more discussion on this top-level terminology, I'd like to move this model along by having Paul propose more details related to the equip and points of heating plants.

Here is the rest of the proposal for the Heating Plant. Many people from the community have contributed to this list over the past few months.

Included are Tags for the Heating Plant and points, Boiler equip and points, and Storage Tank equip and points. They are all fairly self-explanatory following the existing Haystack methodology.

Plants

hotWaterPlant
steamPlant 
chilledWaterPlant //included in this proposal due to the change as noted above.
centralPlant 
districtPlant

Heating Plant Points

hot water leaving temp sensor 
hot water leaving temp sp 
hot water entering temp sensor 
hot water leaving flow sensor 
hot water leaving pressure sensor 
hot water entering flow sensor 
hot water entering pressure sensor 
hot water delta pressure sensor 
hot water delta flow sensor 
hot water delta temp sensor 
hot water bypass valve cmd 
hot water mixing valve cmd
steam leaving temp sensor
steam leaving temp sp
condensate entering temp sensor 
steam leaving flow sensor
steam leaving pressure sensor
steam entering flow sensor
steam entering pressure sensor
steam delta pressure sensor
steam delta flow sensor
steam delta temp sensor
steam bypass valve cmd
steam mixing valve cmd
pump run cmd
pump run sensor
combustion outside air damper cmd
steam header pressure sensor
vacuum entering pressure sensor
vacuum riser pressure sensor
steam EOL temp sensor  //End of Line
makeup water flow sensor 
stack temp sensor
coil entering temp sensor
coil leaving temp sensor
coil entering pressure sensor
coil leaving pressure sensor
coil leaving temp sp
aquastat reset low sp 
aquastat reset high sp 

Boiler Equip Tags

hotWater
steam
oil
gas
modulating
staged

Boiler Points

run cmd 
run sensor
lowWater alarm sensor
lowPressure alarm sensor
emergency shutdown alarm sensor
summary alarm sensor
circ pump run cmd
circ pump run sensor
condensate pump cmd
condensate pump sensor

Storage Tank Equip Tags

condensate
hotWater
domesticWater
glycol

Storage Tank Points

temp sensor
pressure sensor
level sensor

Thanks Paul

I have included a few more for consideration below:

HEATING PLANT POINTS

• stack O2 sensor
• combustion efficiency sensor
• entering combustion air temp sensor
• deaerator tank level sensor

VALVE POINTS

• oneThird steam valve cmd
• twoThird steam valve cmd

BOILER EQUIP TAGS

• Propane

HEAT EXCHANGER EQUIP TAGS

• plateFrame
• shellTube

I have also found Storage Tank Temp Sensor location to be helpful: top middle bottom

In a Domestic Hot Water application I use a math operation (usually average) to determine when to regenerate the tank. I have to be able to distinguish between the two sensor locations.

Also, on the Intellastar platform where I'm doing more control logic, it is helpful to create points for system configuration. In the same Domestic Hot Water application I have a point for drawdown degrees. This is the temperature drop allowed in the tank below set point before regenerating back to the set point. I also have a temperature set point on the tank which is not modeled above.

I use the same kinds of points and logic on a "boiler buddy" type of hot water tank. I don't care so much about the temperature coming out of the boiler(although I still want to know) as I am the temperature in the tank which is the immediate source to the load. In a "boiler buddy" type of tank I also have set point and drawdown degrees.

As a general comment, I think more thought should be given to tag names for control logic purposes rather than just analytics. Newer controllers like Intellastar are tag driven on the control logic side.

The stack, temp, sensor is an interesting point

HEATING PLANT

• When the temp sensor is located in the stack reflecting a measurement from multiple boilers, it could be tagged as stack, temp, sensor

BOILER POINT

• When the temp sensor is located so it is measuring the temperature of the products of combustion of an individual boiler, it could be tagged as flue, temp, sensor

What do you think?

The stack, temp, sensor brings up the opportunity to discuss multiple sensors of the same type in a duct, pipe, stack, etc. that don't have a separate function like the top, middle, bottom tank level sensors Paul refers to. (The duplicate sensor may be used as backup).

In a tall stack where there may be more than one stack, temp, sensor; we could use the following:

• stack, temp, sensor1:2
• stack, temp, sensor2:2

to indicate "sensor 1 of 2" and "sensor 2 of 2".

@Paul I am wondering about the new reset tag in the following groups

• aquastat reset low sp
• aquastat reset high sp

Is the intent to trend a value that is representative of the reset amount?

As an example; would there be tags for

• aquastat low sp
• aquastat high sp

that may be fixed values of 120F and 180F ......and reset points trended that might be 0, +1 or -1 to show the reset amount?

I have seen Siemens trend the reset amount separately from the set point with Discharge air pressure and I am wondering if that it the intent of the proposal.

I have a radiant heating system that does a dynamic loop temperature reset depending on the outside temperature. The loop temperature can vary by up to 30 degrees and is recalculated every 5 minutes. This loop can be used for heating or cooling so it has a default heating and cooling set point depending on the system mode (loop, temp, heating/cooling, sp). I only model and track history for the effective set point (effective, sp) as the result of the system mode and any dynamic reset logic applied to either the heating or cooling set point. I can always derive the delta when needed but I don't complicate the model with a bunch of extra points.

This simplifies the equipment app UI and also makes rule writing simpler as I always know the effective set point was the current target trying to be achieved.

If the controller can not create an effective set point, then you are at the mercy of the controller which could return separate absolute reset values or offset values to the default set points. From a modeling perspective you probably need to handle both. I would suggest absolute values have no extra tags since most values are absolute and an offset tag be added it the value represents a difference or delta from the default value. For example:

aquastat reset low sp
aquastat reset low sp offset

I'm not sure I understand the purpose of the aquastat tag. Wouldn't it be better to use tags to indicate the location of that set points measured variable?

Leroy

The term stack appears to be used pretty widely in the fuel cell industry.

I am wondering if we should save the stack tag for fuel cells and use flue and chimney to differentiate between measurements that are reflective of a single boiler vs. multiple boilers.

Here are my notes attempting to formalize this into the documentation. I want to capture what I did, didn't do, and questions/problems while it is fresh in my mind.

1 - Plant Level

First off I like the idea of using terminology for the plant's output:

• chilledWaterPlant
• hotWaterPlant
• steamPlant

Its a little bit of duplication for heating plants, but seems like it worked out well.

2 - Central/District

I did not formalize centralPlant and districtPlant, although Paul and I discussed exactly what the distinction was and decided that district is multiple customers and central plant is single customer. Also it wasn't clear whether those should be parent entities that contain cooling/heating plants or tags flatten into the existing plant model. So more discussion is needed.

3 - Hot Water/Steam Plant Points

Because hot water plants and steam plants are two different entities I split up the point list for based on which ones I thought made sense (but will need to be reviewed).

4 - Combustion Damper

We tweaked combustion outside damper to remove the combustion tag which would be a new tag, and not sure it is needed to quality since my understanding is that there is only one type of outside damper.

5 - Stack vs Flue

I used the tag flue instead of stack which seems almost as good and is much safer from conflicting terminology.

6 - Plant Points Unfinished

I did not add the following to the documentation because the seems a little more esoteric and not easily defined:

vacuum entering pressure sensor
vacuum riser pressure sensor
steam EOL temp sensor  //End of Line
coil entering temp sensor
coil leaving temp sensor
coil entering pressure sensor
coil leaving pressure sensor
coil leaving temp sp
aquastat reset low sp 
aquastat reset high sp 

7 - Boiler Tags Unfinished

I did not add modulating/staged tags yet - I think both have more widespread applicability that needs discussion.

8 - Pumps (equip vs point)

Because of the ways pumps are modeled in boilers, it seems like there was a clear case to relax the existing rules that pumps always be modeled as equip entities. As part of this process I reworked pump tag to work like fan (can be equip or point level entity).

9 - Boiler Points Unfinished

I did not tackle these boiler points which resulted in some questions about what the alarm tag would mean, and also if all of these points actually model a shutdown condition:

lowWater alarm sensor
lowPressure alarm sensor
emergency shutdown alarm sensor
summary alarm sensor

10 - Tanks

I added a whole new Tanks chapter which I believe will get used for lots of stuff, especially in the industrial space.

11 - Glycol

I did not add the glycol tag because its tied into the unresolved discussion per topic 344.

12 - Heat Exchangers

Paul's proposal didn't address heat exchangers, but I stubbed out a section. Its a little tricky if you have a hot-water to hot-water exchanger. What we tenatively discussed in that case is that the primaryLoop and secondaryLoop tags should be used to quality your points (but might warrant further discussion)

I like it

Hi Brian,

I have a couple of additional thoughts.

1 - Plant Level

How do you account for plants that provide both heating and cooling but are based on heat recovery machines? i.e. they might have boilers but have heat recovery machines, these types of machines can simultaneously produce heating water and chilled water through efficient heat recovery techniques. These systems can't be easily categorised as hotWaterPlant or chilledWaterPlant unless you used both of those tags together to describe the 1 plant system. There isn't effectively a heating plant and then a cooling plant that are separate. There is 1 plant that produces heating and cooling. If that makes sense!!

These machines are more and more common now and are used with and with out boilers. So the categorisation of hotWaterPlant and chilledWaterPlant is really a bit specific and in my opinion dated. Should it not just be a plant tag that can be augmented with cooling, heating, domestic or something else depending on the capabilities of the plant.

Furthermore, and I know this is definitely an edge case so I don't expect it to be taken into account, but for the sake of the argument there are now machines available that can produce chilled water, hot water and high temperature hot water and do it all simultaneously, so the plant can have 3 capabilities in 1.

2 - Central/District

I'm curious to know what happens in a high-rise building with a central plant where the building is multi-tenanted. Isn't that also a multi-customer situation. I think the definition of district plant needs to be more specific and move away from the idea of "customers" but to the idea that the plant is located in 1 building and it serves multiple remote building that are physically separated. Where a central plant is defined as a plant within a building that only serves the building it is located in.

Anyway, just my 2 cents...

Cheers,

Richard

Hi Richard, I don't see any problem with tagging a plant as both chilledWaterPlant and hotWaterPlant if its one entity that provides both. You would have the full set of points for both, so logically you might want model them as separate. But I think the two cleanly mix-in together if you wanted to flatten them together.

But maybe that leads into what abstractions sit "above" plants. Regarding definition of central plant, my understanding is that a plant for a college campus would be termed a "central plant", not a "district plant", and yet it would serve multiple buildings

In your example of the college campus I think that we would call that a district plant. I guess it's problematic, there could be hundreds of different opinions on the definition of a districtPlant depending on the circumstance.

So do I go back to one point I made above.

Do we really need to specify chilledWaterPlant, hotWaterPlant, centralPlant and districtPlant?

Is it not better to just specify a plant with capabilities such as cooling, heating, domesticHotWater and the plant could be a system within a site or a site itself. Other sites could then do a plantRef to a plant in another site.

I realise all of that is a huge breaking change but to my thinking it's simpler, flatter, more extensible because you can just add capabilities to a plant through Marker tags.

A "central plant" to indicate a plant that serves one building and a "district plant" serving multiple buildings could be a good path forward.

In this model, I would consider using interconnected when the “district plant" contains chillers or boilers located in separate buildings that are dispatched as needed to feed the secondary loop.

Another tag to consider

• tertiaryLoop - indicates equipment and points which are associated with delivering hot water or chilled water from the secondary loop.

It seems to me that the definition of a plant is coming together as a group of equipment which conditions water in one way or another. With that type of definition I think Richard has a good point of using plant and adding additional appropriate tags to define the plants output. Other examples were that could be useful would be:

1) Condenser water loops serving water source heat pumps which would often consist of pumps, cooling towers, and boilers.

2) Dual temperature loops which have both boilers and chillers which share all other infrastructure.

That flexibility would allow all these scenarios to easily be defined with existing tags; otherwise there would need to be discussions of new tags to handle those system types as well (Adding both chilledWaterPlant and hotWaterPlant would work for #2, but would we need condenserWaterPlant for #1? and are there others we have not yet thought of?).

In a lot of cases, I think that a tag made of multiple words should not be a tag. I'm not referring to xyzRef tags which are valid in this context.

But plant, loop, water, hot, chilled, should be acceptable tags.

A possible transition could be to still accept chilledWaterPlant (for example), but suggest to use a more generic tagging syntax with multiple markers chilled water plant