I want to focus on one key aspect of the discussion from topic 23. Many different things are discussed under that topic, but there one key issue I want to pull out into its own topic for discussion and resolution.

At question is the fundamental philosophy of whether to use one tag to model a given role or use a set of tags. A couple of use cases:

1. should stages of cooling be tagged cool2 or cool + stage: 2
2. should a sensor and setpoint be tagged as zoneTempSp or zoneSetpoint + setpoint
3. should 3-phase electrical readings be tagged as voltA or volt + phaseA

In the case of scenario 1 we already use multiple tags, in scenario 2 we use a single tag, and scenario 3 awaits a formal proposal.

For the purposes of discussion I would like to focus on the notion of a sensor and its related setpoint. Let's consider the zone temp which has several aspects:

• zone temp sensor
• zone temp effective setpoint
• zone temp cooling/heating setpoint

Let's consider what the model looks like using a single tag versus multiple tags:

Single Tag         Multiple Tags
----------         ----------------------
zoneTemp           zoneTemp, sensor 
zoneTempSp         zoneTemp, setpoint
zoneTempCoolSp     zoneTemp, setpoint, cool
zoneTempHeatSp     zoneTemp, setpoint, heat

Let's say we want to get the cooling setpoint of a given VAV:

// with single tag
zoneTempCoolSp and equipRef==<xxx>

// with multiple tag
zoneTemp and setpoint and cool and equipRef==<xxx>

The single tag is bit more concise, although I don't think the multiple tag version is hugely verbose (one could argue it is clearer). Where the multiple tag beats the single tag is if we want to query all points related to zoneTemp:

// single tag
(zoneTemp or zoneTempSp or zoneTempCoolSp or zoneTempHeatSp) and equipRef==<xxx>

// multiple tags
zoneTemp and equipRef==<xxx>

But if you consider configuration time, the single tag solution is potentially easier to configure and more robust. In the case of multiple tags if you forget to add the sensor or setpoint tags, then the queries such as the one above might be ambiguous or return the wrong result.

So to me the trade-off really boils down to this: multiple tags are more elegant, easier to document, and more flexible to work with. However they require more upfront work to configure when building the model.

So I would put the following questions to the community:

1. which design pattern would you prefer: single tag vs multiple tags?
2. if you vote for multiple tags are you willing to make a breaking change to the sensor vs setpoint pattern?

I would encourage the support of multiple tags. A single tag can be used for configuration leaving the rest of the appropriate tags can be easily constructed by rules. For example, if "Dave <is the uncle of> Tom", then the facts like "Dave <has gender> Male" and "Tom <has some parent> X" and "Dave <is a sibling of> X" can all be built automatically. You don't give up anything by using a tag like "zoneTempCoolSp" during configuration if the back end can infer that things of this type (a.k.a., "class" in RDF and OWL) are also members of other classes.

Support for (or at least recognition that tools can or will support) inference rules is what changes a "tag soup" into an ontology.

I think I like the multiple tag approach. It is more elegant, more flexible, and easy to understand.

Although here is some food for thought when it comes to applying this in a real world scenario: Sibling points on a device typically need to have unique names, so whomever is naming these points will probably be using a naming scheme like the single tag approach already. Perhaps I shouldn't be mixing point naming with tagging though... Often with a good naming scheme, tags can be easily inferred. I guess what I'm getting at is if we go with a single tag approach, than tags can be point names and vice versa, which isn't the case with the multiple tag approach. However with the multiple tag approach, the tagging and point naming are decoupled... That would be great in a scenario where you have an existing system where the naming scheme is a complete mess and going through and changing the point names either isn't an option or not feasible, but tagging the points with a Haystack convention suddenly makes the system much easier to integrate with and make sense of the points.

So I still feel multiple tags is the better approach here.

3-phase power stuff might warrant a separate thread for discussion... when you're talking about voltage, kinda need to make a distinction between phase-to-phase vs. phase-to-neutral. Everything else (current, power factor, power, etc.) you just use a, b, & c when referring to phase. There also phase average measurements as well...

I think we should target a kind of mix between single and multiple tags. In fact, I strongly think that the only good way of building a BAS system is to start with "good names" for points. When programming, you have to think twice when you name your variables, classes, methods, etc... It's the same when you're building a HMI.

I'm sure that majority of systems are made in a way that when you list what's under a controller, you will get a point list. That's the first thing you, or the client will see. If Haystack offers some kind of "standard" to name points (wich we already have ex. zoneTempSp, dischargeTemp, etc...) we will have a quick way of building well named points lists, readay for some database requests. So, first step : find good names for your points.

Second, tags added to points are a nice feature because you can "document" your points. The hard part is to know where to stop. Do I really need to know that my zoneTemp is a sensor ? Maybe if I want to list all my sensors... maybe not. Does the standard will invite us to add all tags for all points ? I'm pretty sure we'll end with a bunch of points with a few tags.. another bunch with no tags at all, and another bunch with "forgotten" tags, cause we forgot to add the Cool tag to one setpoint... It's hard to maintain in real life applications.

In the best of all world, well made/not forgotten/globally set/[...] multiple tags are clearer, easier to make databse request, etc. But in the reald world, when you don't have too much time to create your database and you need to be effective, rapidly you cannot forget begginning with naming your points correctly.

Adding multiple tags to points can then be taken as a additional way of adding details to your systems.

In existing systems, if it's impossible to rename points, we'll have the possibility to add a nameTag that could tell the standard name of the wrongly named point...

Typically, I would see something like that :

Controller XYZ-01 (something like brand + address on BUS) Tags :

• Unit -> AHU-1
• Sector -> 1st Floor
• etc... more tags if needed

Thermostats XYZ-02 (ex. brandname + address)

• Unit -> AHU-1 (air comes from AHU-1)
• Local -> L-010
• Description -> Office of Mr.X
• Other tags if needed (ex. type of box,etc.)

Under thermostats XYZ-02 you would find zoneTemp

• Description : Zone Temperature zoneTempCoolSp
• Description : Cooling Setpoint zoneTempHeatSp coolingDemand heatingDemand occupancyCommand etc...

Description tags can be used on graphics to describe points, or in histories or alarms...brings more clearer terms for users...

Finally, on the first page of Haystack, we can read : Project Haystack is an open source initiative to develop naming conventions and taxonomies for building equipment and operational data. -A good naming convention -A standard way to add tags where it's needed to add clarity to a database.

With that, I think we cover most of the situations. Leading to a well done database even if not all tags has been set.

My vote is for multiple tags. The main reason being greater flexibility within queries.

There have been a few comments about initial setup or the chances of missing tags on certain points. I don't think this is as big of an issue as some people think. The initial setup ideally should not be done by hand, 95% of the time this should be an automated process. Missing tags in an automated process should not happen and if it does minor changes can be made to adjust with little time or effort. Today some basic tags are identified as missing through the Lint Tool. My initial thoughts is that this would evolve around the standard tag library to have sufficient checks for tags as well as the possibility in the future to write custom checks.

@Brian - Yes, I am willing to make this breaking change.

Okay, it sounds like the multiple tags approach is the right way to go. Here is my specific proposal to tag library changes:

Remove these tags from library:

• outsideFlowSp
• zoneTempSp
• zoneTempCoolSp
• zoneTempHeatSp

Add the following tags:

• sensor: Marker tag applied to an input point which reads a process or environmental condition. Sensor points may be paired with a command or setpoint point.
• command: Marker tag applied to a "hard" point which outputs a command state to a switch or actuator. Commands may be paired with a feedback sensor point.
• setpoint: Marker tag applied to a "soft" point being used by the control process. Setpoints are often paired with their process variable with a sensor point.
• cooling: Marker tag used to associate a point or equip with the cooling system. Specifically it may be used with the zoneTemp and setpoint tags to model the cooling setpoint temperature.
• heating: Marker tag used to associate a point or equip with the heating system. Specifically it may be used with the zoneTemp and setpoint tags to model the heating setpoint temperature.

What I propose is that a point must be accompanied by the sensor, command, or setpoint tag. I think without that requirement it will be too easy break models. In SkySpark we will of course add that to the Lint tool.

Also point of debate: we have cool / heat tags which model the cooling/heating coils/valve themselves. Those tags are the primary point role tag, and so I'm thinking we probably shouldn't reuse them as auxiliary tags for zone temp setpoints which would result in ambiguous queries. I'm proposing we keep cool / heat as is, and add new cooling / heating as the auxiliary tags. Can anyone think of better design pattern?

After a few more conversations, I'm thinking that we need to take the multiple tags philosophy all the way. In the AHU model, most of the tags are a combination of where in the duct work the sensor is located and what is being measured. For example dischargeTemp, dischargeHumidity, dischargeFlow, etc. This combination also seems to cause an explosion in documentation of tags which can be more elegantly handled by declaring a discharge tag for all data associated with equip discharge and another suite of tags for temp, humidity, etc.

In addition, another looming problem is what is being measured. In an AHU or VAV the only element which is an input or output of the equip is air. But in the case of chillers and boilers we actually have multiple types of liquids/gases entering/leaving the equip so we will have additional tags for that. To keep things consistent, I'm thinking that we go ahead and mark AHU and VAV points with the air tag to indicate input/output for consistency with future chiller/boiler work.

So in addition to the proposed changes specified above, I'd also like to expand my proposal to these tags:

Current Tags           Proposed New Tags
------------           -----------------
dischargeFlow          discharge, air, flow, sensor
dischargeHumidity      discharge, air, humidity, sensor
dischargePressure      discharge, air, pressure, sensor
dischargeTemp          discharge, air, temp, sensor  
exhaustDamper          exhaust, damper, command
exhaustFan             exhaust, fan, command
fan                    discharge, fan, command  // tricky one but we have to add something
fanDiffPressure        discharge, fan, diff, pressure, sensor
filterDiffPressure     filter, diff, pressure, sensor
mixedTemp              mixed, temp, sensor
outsideDamper          outside, air, damper, command
outsideFlow            outside, air, flow, sensor
outsideFlowSp          outside, air, flow, setpoint
outsideHumidity        outside, air, humidity, sensor
outsideHumidityRef     outside, air, humidity, sensor, pointRef // new pattern
outsideTemp            outside, air, temp, sensor
outsideTempRef         outside, air, temp, sensor, pointRef  // new pattern
returnCO2              return, air, co2, sensor
returnDamper           return, air, damper, command
returnFan              return, air, fan, command
returnFlow             return, air, flow, sensor
returnHumidity         return, air, humidity, sensor
returnPressure         return, air, pressure, sensor
returnTemp             return, air, temp, sensor
weatherCond            cond (with existing weatherPoint)
weatherHumidity        humidity (with existing weatherPoint)
weatherSunrise         sunrise (with existing weatherPoint)
weatherTemp            temp (with existing weatherPoint)
zoneCO2                zone, air, c02, sensor
zoneDamper             zone, air, damper, command
zoneHumidity           zone, air, humidity, sensor
zoneTemp               zone, air, temp, sensor
zoneTempCoolSp         zone, air, temp, cooling, setpoint
zoneTempHeatSp         zone, air, temp, heating, setpoint
zoneTempSp             zone, air, temp, setpoint

This is a fairly massive change, but I think it provides a lot more flexibility for building really sophisticated models without tag explosion.

I agree with going all the way with multiple tags. I like the idea that it will reduce tag explosion and allow for more precise querying of points. Even from this starting point above we can model a different system with only adding few extra tags.

With regards to your new pointRef, I understand the concept, but do not believe I fully understand outsideHumidityRef and outsideTempRef. Would these be internet data compared to outsideHumidity and outsideTemp being actual sensor data at the location?

I agree with the multi-tag system but we have to have the following:

• Lint tool would have to check the tags for inconsistencies
• Folio tag edit menu should not allow duplicate/inconsistent tags.

For example when we fill web forms, forms have JavaScript checks whether the email entered is correct. It would be beneficial to have a similar system for adding multiple tags so we won't go crazy finding the bugs with inconsistent tags during the function executions.

If we have a sensor tag attached to the point, it should not allow us to insert command tag. vs.

I agree with the Lint tool checks, so we have a place to look and see inconsistent tagging. The Rec Editor already does not allow duplicates on a single record, but I'm not sure if I agree that it should not allow you to add tags based on these Lint checks.

The Rec Editor is allowing direct manipulation to the database and this should not be restricted to a user. In the Rec Editor the user should be allowed to do whatever they wish, but then verify their database through the Lint Tool. The Rec Editor is a little different than a Web Form that has validation. The Rec Editor is not a specific entry form for an end-user and needs to allow complete flexibility to create, update and delete records in the Folio database.

What I meant is if the following...

Let's say we have these tags on a point

Assigned tags
------------        
discharge, air, flow, sensor

We try to add the tag
-------------        
command

The editor would pop up an alert box and say "sensor marker is attached!" Are you sure you would like to add "command"?

This way, a programmer that does not have the expertise on the tags on certain points would not make a mistake. We will have tags that will cover broad spectrum from HVAC, Electriciy, Gas, Demand Repsonse, to DataCenters, etc. I am sure only a few will learn all of the tags.

It is not to restrict the user rather to warn them during implementation. I am sure, Brian could make a parameter where we can turn off the warnings.

@Alper - I agree with your warnings concept.

I like the multiple tags approach. We have a large inventory of heat pump buildings. Multiple tags will allow us to distinguish between discharge and return air and water temperatures in a heat pump unit. Water coming into a heat pump unit is typically refered to as "supply" temperature. The primary water loop in a building also refers to "supply" and "return" water temperatures. Has any consideration been given to standardizing on a "supply" tag? This tag could also be applied to cooling towers and boilers.

With regards to your new pointRef, I understand the concept, but do not believe I fully understand outsideHumidityRef and outsideTempRef.

In the case of AHUs (or other equip) it might be common to share one outside temp or humidity sensor. So the question is how we model this many-equip-to-one-sensor relationship? Because the model is becoming more sophisticated, I don't think a single ref tag on the equip will suffice as a design pattern. Instead I think we need what I would call a "join point": an entity with all the tags to fully model the relationship, but instead of being a point itself, it references another point (for example you would never want to duplicate the history data).

There are other options here which may warrant its own separate topic for a full discussion. Should we tackle this now? Or maybe just ignore this problem for now as part of this proposal?

Lint tool would have to check the tags for inconsistencies

Regarding SkySpark support: we will obviously update the Lint tool to verify proper tagging. And in general all these changes can be done in a backward incompatible manner. The problems arise in that simple tags like fan will now be overloaded. It is highly unlikely we would place any restrictions on generic RecEditor as that is a general purpose database editor. However, build 1.0.32 will have a specific Site Builder app which can make appropriation sanity checks. If further discussion on how SkySpark handles these rules, I would suggest we spin that off as a separate topic since it is sort of parallel to the core modeling discussion here.

Water coming into a heat pump unit is typically refered to as "supply" temperature.

In the case of AHUs and VAVs, I have explicitly avoided the term "supply" since it is ambiguous in terms of your perspective. I think final choice of terminology for boilers, chillers, pumps, etc really requires a holistic treatment of the model (discharge, return, leaving, entering, input, output, supply, etc). Until you try to model the big picture trying to bite off "point sized chunks" of the model will not lead us down the right path. I would suggest further discussion on new tags like this be done in a separate topic. At some point soon we really need to do chillers and boilers because they might effect our terminology we use for AHUs and terminal units.

As general feeling it seems like everyone is on board with this direction. I haven't heard any nays.

Is everyone on board with tagging the RTU/AHU main fan as discharge, fan, command? It is often called other things like supply fan, but I was thinking that terms of consistency with overall duct work it is best associated with discharge of air.

Also what is feeling around modeling of shared outside sensors for many RTUs/AHUs? Maybe we should punt on this issue for right with the other changes on our plate?

I am fully on board with the proposed tagging change and am willing to modify our existing code to see it realized.

I think the shared sensor issue should be a separate topic, but just for clarification on this thread: Are you proposing a new type of history? IE: The record with outsideHumidityRef will not have any historical data of its own, but use the pointRef to get data on demand like a hisFunc tag on a computed history?

Sorry, Ive been lurking a while but I'm really glad to see this notion of multiple tags as it brings back in the parent child heirarchy that I was missing in the initial tag designs. Could a device also be described in a nested manner that also lends itself quite well to querying? A basic example:

airHandler
->physicalLocation
->servedLocation
->brand
->model
->serialNumber
->values
-->temperature
--->supply
---->value
---->setpoint
--->return
---->value
-->pressure
--->supply
---->value
---->setpoint

so that an ahu can be described as airHandler.brand or airHandler.values.temperature.supply.setpoint etc. Could this allow querying of all airHandler..temperature as well (returning all 3 terminal points in the tree that are described as airHandler and temperature)?

Okay, this proposal has been out there over a month for everybody to chew on and I think it makes sense to proceed. I will be updating the haystack library and also our SkySpark software with the new multi-tag model this week.

But there is tweak to the proposal I would like to suggest. With this new model it is a requirement that all points are tagged as sensor, command, or setpoint. This will avoid confusion and ambiguity b/w sensors and their setpoint or command point. But since these tags will be so fundamental to the model, I was thinking about how to ensure that a) they are generic and b) they are abbreviated or short to use. So to make them short and generic, I would like to propose these tag names:

• in: a control input, AI/BI, sensor
• out: a control output, AO/BO, command, actuator
• sp: setpoint, internal process control variable

With those tags and proposals above, here would be some queries:

• AHU discharge temp sensor: discharge temp in
• AHU main supply fan: discharge fan out
• Zone temp sensor: zone temp in
• Cooling zone temp setpoint: zone temp cool sp

@Brian - I'm okay with in, out and sp. They are short and to the point for what was previously proposed. Couldn't think of a 2 letter tag name for command?? HaHa, I can't either.

The queries appear to be logical as well with the multiple tag philosophy, besides you need to add in air and cool should be cooling ;-).

The queries appear to be logical as well with the multiple tag philosophy, besides you need to add in air and cool should be cooling

Right - we said the verbs cool and heat are the actual cooling and heating elements/coils/valves. The tags cooling and heating for mode associations like cooling setpoint.

In modeling fans, I was thinking of doing this:

• fan out: the fan command status as true/false (on/off) or 0% to 100%
• fan in: the input sensor of a fan as true/false (on/off) or differential pressure across the fan measured in "inH₂O" or "kPa"

Is there any other input sensor technique for a fan's status other than differential pressure? If not then that seems a pretty clean way to model it.

And if we do that, then I will make differential pressure across the filter as:

• filter in: the status of air flow across a filter as as true/false (good air flow/bad air flow) or differential pressure measured in "inH₂O" or "kPa"

Your modelling seems good. The fan in could also be an analog current sensor measured in amps, typically current sensors are just digital though like you already have covered.

Working on the chiller model offline with a few people, it is becoming clear that the terms "in" and "out" are really confusing. For a given point on something like a pump there are two dimensions:

• I/O: sensor versus the command (AI vs AO)
• Flow: entering versus leaving

So let's say we were modeling the chilled water leaving sensor and its setpoint, we might have these tags:

leaving chilled water temp in  // sensor 
leaving chilled water temp sp  // setpoint

Or a pump on that pipe:

leaving chilled water pump out  // command output
leaving chilled water pump in   // proof of flow sensor

Is the terms "in" and "out" confusing enough to change? Should we change them to "sensor" and "cmd"?

If we did that would anyone consider "in" and "out" better tags to use for "entering/leaving"?

The tags as you had them:

leaving chilled water temp in   // sensor

in my experience represent a contradiction in terms, leaving versus in. I understand where you're coming from though in wanting to model the position in the equipment being described.

It might make things clearer to designate something as a sensor explicitly. I suppose the trade off is being able to model equipment in explicit detail versus generalising a model and having easy to understand terminology a difficult task.

My other concern is that the example shown is a little verbose.

chilled water temp in   // to represent a sensor

is one tag less. This may or may not be a concern for the community, and if its already been discussed previously I apologise.

Seting aside the modelling of commands again status/sensors, I would think that input and output are fairly clear when talking about plant equipment, therefore in and out as tags for sensor positions work for me.

This might be a slightly naive question, but is there any reason why the tags in and out can't have a different meaning in different scenarios? For example in Skyspark we would combine the in tag with a temp or pressure tag to do analytics. You could likewise combine the out tag with a pump tag to describe a command output.

Playing devils advocate on my own argument though for a minute, I guess by modelling things we are trying to steer clear of ambiguities.

In the end I'm +1 for:

chilled water temp in

Brian: as we discussed offline, we have a lot we can contribute for plant modelling. So when you're ready to kick off that discussion, perhaps in a separate thread I'll post our ideas in more detail there.

Richard, in this example:

chilled water temp in

Are you using the terms "in" and "out" to mean "entering" or "sensor"? Because we also have a sensor on the chilled water leaving.

Just to recap original discussion, the problem is that often we pair a sensor with either a setpoint or a command:

• zone temp sensor + setpoint
• fan/pump/damper command + proof of flow/position sensor

In order to pair up the sensor and its command/setpoint, we decided on using one of three tags to model each of these point classifications (previously we had used a suffix like zoneTemp and zoneTempSp).

In an ideal world the "primary" wouldn't require a tag and we could do this:

zone air temp               // sensor
zone air temp sp            // setpoint

discharge air temp          // command
discharge air temp sensor   // status sensor

But without that extra tag, queries on those types of tags would be ambiguous. So by forcing one of the three tags (in/out/sp or sensor/cmd/sp) on each point we can make it just a required part of configuration and unambiguous.

@Brian - Your examples do prove to show some confusion regarding in/out tags with I/O and equipment orientation (water flow in your examples).

So let's say we were modeling the chilled water leaving sensor and its setpoint, we might have these tags:

leaving chilled water temp in  // sensor 
leaving chilled water temp sp  // setpoint

Or a pump on that pipe:

leaving chilled water pump out  // command output
leaving chilled water pump in   // proof of flow sensor

It may be better to change our current tags of in to sensor and out to cmd, regardless of what we decide on for entering/leaving tags.

It leaves a question as to what to use for the orientation of flow on a piece of equipment (i.e. pump, chiller, boiler, etc...)? I really would not mind either suggestion; in/out or entering/leaving, I think both are clear and straight forward. Although I'm not a chiller/boiler guru, so what does everyone else think?

@Joe - I think thats a reasonable suggestion designating a sensor and a cmd.

So the examples would turn into:

leaving chilled water temp sensor
leaving chilled water temp sp 

entering chilled water temp sensor
entering chilled water temp sp

Or alternatively using the in/out instead or entering/leaving:

chilled water temp sensor in
chilled water temp sp

chilled water temp sensor out
chilled water temp sp

Applying this idea to AHUs:

discharge temp air sensor
return temp air sensor

discharge air fan cmd      // command that tells fan to run
discharge air fan sensor   // to verify fan is running

Some examples of chiller commands might be:

chiller cmd              // chiler run/call cmd
chilled water pump cmd   // pump run/call cmd

Just some example/thoughts off the top of my head. The fan command/feedback issue came up with us recently as we had some AHUs that had a fan call point to tell it to run, but also a fan status to give feedback. So I think this is an important area to get right.

Not sure if the debate is still ongoing but I would prefer the use of cmd and sensor as opposed to in and out due to the clarity of intent of the label.

I'm definitely thinking we should make the switch from in / out to sensor / cmd. Let's consider this an official proposed change. Please comment if you dissent.