I am in the process of writing a DDC programming specification for my company, which is an MEP consulting firm. I am interested in adopting Haystack for the purpose of a point structure/naming convention for the DDC Contractor to implement.

Is there a simple, relatively brief description of the Haystack convention that just addresses the naming of points? I'm looking for something that I could (ideally) paste directly into my spec, or adapt for inclusion in the spec.

I am new to Haystack but its scope appears to extend beyond just point naming. There's a lot too digest here and far to much to put in a spec, so I'm wondering if there is a relatively self-contained explanation of just the point naming convention.

Thanks!

Brent

Haystack is there to solve the naming convention. But not by creating a naming convention.

Depending on the technology you use, you will not be able to use certain names, characters, length... etc....

Lon vs BACnet is a good example.... where in Lon everything has to begin by nvo, nvi, nci, etc... Not in BACnet where it's a real mess sometime...

And when you will face OEM devices with their own BACnet (or Lon) interface... point names cannot be changed...

I guess you can work on something and expect the majority of the points be named by a "certain" standard. But from experience, it will be a hard path.

Some manufacturers have their standard. I use one where every point use always the same kind of name... like DA-T (discharge air temperature), SF-C (supply fan command) but then again, if you mix with different devices... good luck. You can rename in a supervisory device point list... but the point names in the device will never change and it will make things harder when you will try to know what has been renamed how.

Actually, there is nothing broadly accepted as the way to go in naming convention.

And honestly, if we chose tagging and metadata over a naming convention, also reside in the power given by this method. We'll never get as much information in a naming convention than in metadata added to points. Whatever their name is.

Brent, The Haystack Docs section is a good reference to start. The tagging for common equipment and points is described there: http://project-haystack.org/doc

Christian,

Thanks for the reply. I probably should have mentioned that this is a BACnet spec. It's actually pretty demanding about it - BTL listing is required as well as specific BIBBs and support for certain objects and methods, in an effort to circumvent various tactics used by vendors to create vendor lock-in despite being "BACnet compatible".

It's also worth mentioning that this spec is for new construction projects, so interfacing with legacy systems is generally not going to be a concern.

I'd like to have you expand on your comment "You can rename in a supervisory device point list... but the point names in the device will never change". A programmable BACnet device treats points as editable object, doesn't it? I know there are some configurable controllers that limit how much you can change their internal logic, but those are excluded by my spec. Or are you talking about something else?

Jerry,

Yes, I reviewed some of that material. That's where I got stuck. It's far too extensive to include in a spec, or to ask a contractor to understand. What I'm looking for is a relatively contained summary, no more than a page, which explains how the point references are constructed.

This is where the rubber meets the road - implementation by contractors in the field. I'm eager to adopt a system like Haystack and see it actually used in projects, but first it needs to be accessible to contractors who are mostly not programmers and who are always jammed for time. I can't just direct them to this site and hope they'll figure it out. I have to give them a formula to follow. Is there no such thing for Haystack?

The closest thing to a a page of standards would be http://project-haystack.org/tag . Haystack is about the tags and not about the names.

Brent,

Let's say you buy a boiler. That communicates bacnet. You won't be able to modify the point names inside the unit. It's been decided by the manufacturer for all their devices. I'm not referring to legacy device at all.

Excluding configurable controllers is not a good idea from my own opinion... you are excluding VAV, thermostat, VFD, condensing units, energy meters, etc... All those devices comes with their own variables names.

If you integrate a BACnet device in a supervisory system (a BAS), you will probably be able to name the points the way you want BUT. this can lead to some interpretation problem. You make a discover to get the device object list you get names.... and those are different in the BAS... not optimal.

Or let say you talk with the manufacturer for a problem : what's the value of "Unit Alarm" ? Hummm... how did we renamed it.... it's BinaryValue:1....

2 years after the project, you're trying to figure out what'S going on with a device. The instruction manual tells you to watch for a variable named "Really Important Variable"... but we renamed everything... A simple verification suddenly turns into a full time research for point names conversions.

Variable names, from my perspective, don't need to be standardized. Metadata is there to document everything.

On the other hand, controller names, device IDs, BACnet network numbers requires a strong structure.

I'm excluding configurable controllers (e.g. VAV or ASC) because they cannot run the sequences I want to use (ASHRAE Guideline 36). However, I am not excluding equipment gateways, as long as they are used to connect just a single piece of equipment to the BAS. (i.e. gateways are allowed as protocol translators, but having a whole separate non-BACnet control sub-network is not.)

Many of the devices you listed (VFD, condenser units, meters) either require a gateway or have one built in. My understanding of gateways is that there is a mapping table between the device's variable names in its native protocol (frequently Modbus) and its BACnet point name. The native/local name is fixed by the manufacturer, but I thought that the BACnet name was something that could be programmed when setting up the gateway. Obviously you need documentation of the gateway point mapping, but that's a required part of the systems manual.

I agree that the scenario you outline is a concern, but I'm trying to figure out to what extent it is likely to actually be a problem.

The reason, incidentally, to impose a rigid point naming structure is to make trend data manageable. I've tried to do trend analysis of a project with several thousand points where the contractor did not follow a consistent convention, and it's a total nightmare.

I agree that metadata is the path forward, but it's not supported by most of the extant control systems. I'm trying to figure out how to apply some structure within the context of existing platforms.

"Many of the devices you listed (VFD, condenser units, meters) either require a gateway or have one built in."

A lot of those devices come with native BACnet support. No need for a gateway.

I guess you could ask for a rigid structure in the case of histories names. On the platform I use, no need to have a relationship between the history name and the point name... We often use something like :

• System/Information
• System/sub-system/information

ex.

UnitA/Return_Temp

Some system even allow the usage of metadata directly on histories... but not on points.

Brent

I have tried to force contractors to use a strict naming structure without much luck.

If they use "consistent" naming convention, commissioning becomes manageable.

Items I put in my specifications are below (Items #8, #9 and #10 are critical and need to be understood by all mechanical contractors on the project):

1. The Contractor’s initial proposal will identify (a) which BAS points are available for trending and (b) a consistent naming convention to be used throughout the project that includes an explanation of all abbreviations used. Names for items such as VAV boxes must identify which Air Handler they are associated with.
2. The Contractor’s initial proposal will include sample trend files in an electronic format so they can be evaluated for structure and size.
3. Point names on drawings are the same as point names used in trend files.
4. Trends will be made available during the construction process when equipment is under automatic control of the BAS. If the trend files are not available, the equipment, it is not considered “substantially complete”. Adequate time will be allowed for the Customer to review the trend data prior to being asked to accept the equipment as “Substantially Complete”. Setting up “all of the trends” for “all of the equipment” at the end of the construction phase is not acceptable.
5. When text strings are capable of being reported as data, the contractor’s initial proposal will submit all text strings available, and identify which ones are planned on being utilized. The Customer will approve the acceptable text strings.
6. The contractor guarantees the specified points are trended and the "open" access to all trend data will continue to work as specified during the warranty period.
7. Values of temperature, pressure, speed, Hz. etc. will be recorded as instantaneous values. Meter pulses (or values represented by meter pulses) will be recorded as the total occurring during the interval prior to the recorded date/time stamp. Change of state reporting will not be utilized without prior approval and if it is approved it will only be used for Boolean points such as 1/0 on/off, open/close and set-points not utilizing a reset schedule.
8. The equipment warranty period for new/upgraded BAS and new equipment controlled by the BAS will not begin until the trend files are completed and automatically transferred to the designated, folders or FTP sites.
9. Due to the challenges involved with determining the (1) BAS hardware, (2) software and (3) mechanical equipment is working properly in Heating, Cooling and Shoulder seasons; the Customer has 6 months after the expiration of the warranty period to identify items that did not work correctly during the warranty period when it is demonstrated with trend data that the (1) BAS hardware, (2)software and (3) mechanical equipment provided did not work as intended.
10. There will be an adequate amount of trend data collected for all equipment in the Heating, Cooling, and Shoulder season temperature bins to verify the intended Occupied, Unoccupied and Standby sequences of operation in each season. If there is not adequate data collected during the warranty period to verify equipment and control strategies are working as intended, the warranty period will be extended as necessary.