I hope to post an initial draft of thoughts on chiller plants this week. As part of this effort, I think there is one important side issue that requires some discussion.

Today we have what amounts to a structural three level "tree"

• site
• equip
• points

Equip and points are associated with a site via the siteRef tag. Points may or may not be associated with a piece of equip via the equipRef tag. This doesn't mean that other "trees" and navigation models aren't important. For example I might want to associate AHUs with their VAVs, central plants with the their AHUs, submeters with their main meters, etc. But having the fundamental site/equip/point hierarchy has proven extremely useful.

With the notion of central plants, we are soon to have a concept of chillerPlant entity that contains equip like chillers, cooling towers, pumps, etc. It also has its own "plant-level" points like chilled water supply temp/setpoint. But you wouldn't really call a plant an equip itself.

And we also have the notion of what I call "site-wide" points like OAT, occupancy, etc that don't really get associated with a specific piece of equipment either.

That said, I think we've found in SkySpark that no matter how good your navigation and search features might be, it is really quite convenient to at the minimum be able to group everything into this three level tree:

• provides basic out-of-the-box navigation that works for most smaller projects
• provides basic structure to use for more sophisticated navigation/search model
• provides simple rules for naming conventions/import scripts

So specifically, what I want to propose is that we make it a hard requirement that every point have a equipRef tag. This means that the term equip will become a little most loose to include things like site-wide point groups and central plant. But this seems preferable to trying to coin another term that could handle that abstraction.

Here at Cornell we also have a tree. The site is excluded because we are only dealing with the Ithaca campus for now, but the others expand to...

• facility
• [sub-facility]
• system
• [sub-system]
• point
• [attribute or condition]

Facilities are buildings, and in the case where we are working with distribution systems that aren't specific to a building we substitute campus (or just leave it off like OAT). Sub-facilities are things like dining areas within a building that are supervised (and billed!) to separate departments. In some cases (fortionately pretty rare) where there is more than one AHU-1 in the building, the Pent or Bsmt will be stuffed in to the sub-facility slot.

Systems are the usual, like AHU-1, and sub-systems might be things like preheat or cooling coils, or in many cases there is a supply fan and a return/exhaust fan that are considered sub-systems.

Points are points.

Attributes or conditions might be things like whether or not the point is in alarm, or what the alarm limits are. So if DTEMP is the discharge temperature, then DTEMP.ALARM means there is a problem, DTEMP.HIGHLIMIT has some value, and DTEMP.HIGHLIMIT.ALARM is a more specific description of the problem.

These name components are separated by . or / depending on the context, and what would be an equipRef tag is implicit in the hierarchy.

The scheme has it's problems (a fan system in one building serving rooms in a different building, subsystem groups of lead/lag pumps and/or fans, etc. But it has worked very well for us (200+ facilities, 9 protocols, 6,000+ devices, 460K points). We restrict names to be URL friendly and mash the stuff together into a hierarchical semantic wiki.

@Brian

I admire your interest in keeping the three level tree for flexibility and simplicity's sake however I'm afraid of the equip tag turning into a confusing catch-all which some instances being actual physical equipment and many others being just points categories.

I admit that I haven't come up with a better alternative yet that still does a good job of preserving the issues you outlined - an option might be to have an alternate second level tag such as pointGroup with similar intent.

@ Joel

I like the logic behind the tree that you guys have used in the past - any extra insight on the challenges that implementation of the Haystack tags would have (is having) in conforming to your existing system?

I can imagine that the site tag could be used interchangeably with the facility label in your tree.

There are two basic problems to overcome.

The first one that hits you in the face building a tree is as simple as the distinction between AHU and AC for fan systems. It doesn't matter how formal and rigorous our naming and classification scheme is, if the only opportunity to put the right name on something comes after it has already been installed, it's way to late. We have stuff labeled HV (heating ventilating) units that have chilled water coils in them (so they are actually conditioning) and AC units that do not. The labels on the sides of the equipment match the labels on the engineering drawings, where the first one is labeled "1" and the second is "2" and of course the engineer has no idea and doesn't really care if there is already a "1" and "2" in the same facility.

Just like system names have to match the sticker on the side of the device, point names need to match the labels in the code, or the people that maintain the system will be extremely frustrated. If the point is called STAI14 (supply temperature, analog input 14) then a unified system has to store that someplace. If that point "goes into alarm" then the techs are going to want "it's trend data", so the system has to store that. From dealing with systems that have constrained names for so many years, techs have become very adept at holding on to the label only as long as conceptually necessary, then immediately transition to thinking about what the point is rather than its name, which is just a poor symbol.

The second biggest problem is classic problem from mereology, where a hierarchical name implies there is some dyadic predicate that supposes a strict partial ordering of components, where some symbol like . (dot) or / (slash) is used as a universal wild card for that function, without actually telling you the function. Which is exactly why most XML encodings are huge piles of guano, the designers are attempting to pack all of their notions of parthood into a two axis system (child element and attribute) and there's no guidance on which one is "correct" (and there can't be, which is why when there's a problem they're not using enough XML). But I digress... :-)

So the label A.B.C only makes sense to one set of customers, X.Y.C might make more sense. This is presented in some systems as a distinction between a "network tree" and "geographic tree" or "asset tree". Every one of those trees is particularly good at describing some parthood relationship, but none of them are good at describing all of them.

Your example of a site as part of a hierarchy is classic. We have lots of sites (New York City Medical College, Geneva Experiment Station, Arecibo Observatory, Ithaca main campus, Appledore Island) and within them we have sub-sites (North Campus, East Campus) and overlapping those is maintenance management zones. Ah, which to choose? One of them? All of them?

Our solution is to put it in a wiki and let the users build whatever tree they want. There is generally some cooperation that the Imogene Powers Johnson Center for Birds and Biodiversity can be called OrnithologyLab. But there's trouble when Academic II is built before Academic I and then renamed to Comstock Hall where there already was a Comstock Hall. The same goes for AC 2-1.3 on the engineering drawings, the weasels used both dots and spaces in the formal name, which isn't just on the side of the fan, but buried in maintenance management asset records.

Sorry for the rant, there are lots of challenges, but it's clear that this project is struggling with the same issues as every other taxonomy project (or XML Schema design project). I would take some cues from http://schema.org/, specifically the Data Model, where the design makes some pragmatic decisions and isn't so concerned with strict hierarchies and abbreviated names.

I love the site -> equip -> point heirarchy for about 90% of most BAS systems. I don't know why equipRef needs to be a mandatory tag on all points tho?

I agree with Clayton, I'm a little concerned about this turning into a catch-all group. This is what I originally did in the early releases of SkySpark to have global points displayed in navigation and Apps. When the equipToPoints function was introduced in 1.0.29 this allowed easier access to determine what points will also be viewable on equipment types.

I also do agree that not sticking to some sort of a "standard" heirachy makes OOTB navigation tough. Why can't points reside only under the Site? What about equipment under equipment as talked about in the chiller plant proposal? This puts more of a twist on standard navigation as well.

immediately transition to thinking about what the point is rather than its name, which is just a poor symbol.

Good comment - I think this is why Haystack does well by modeling the point as a general entity that might be tagged a dozen different ways to fully describe the characteristics of that point (and the systems it exists in).

Ah, which to choose? One of them? All of them?

Yes, the tag model is designed explicitly to let you model things using multiple dimensions. That isn't the primary issue here though - the core of this proposal is that given you might have 100 different "trees", should we standardize that at least one tree (site/equip/point) is always available to use as one known navigation technique.

I agree with Clayton, I'm a little concerned about this turning into a catch-all group.

I think experience has proved that having at least one definitive three-level navigation model is sorely needed so that we can build UIs around something. Not to say that you don't allow or use alternate UIs. But not forcing every point into at least one "group" under sites is turning out to be a UI nightmare. In SkySpark this problem manifests itself all over the place in RecPickers, SiteBuilder, SiteApp, etc. It is just a huge complication that be solved by a simple model rule.

an option might be to have an alternate second level tag such as pointGroup with similar intent.

I am pretty sure we need a required group level between site and points for reasons listed above. The issue is do we coin a new term and change the model - such as using a tag like pointGroup. Or do we just hijack the existing tag and term equip. Since the common case is equipment, I lean towards hijacking equip so we can continue to use equipRef to associate a point with its equip. If we pick another tag like pointGroup, does that mean we should change every equipRef tag to pointGroupRef? Don't like that!

The issue is do we coin a new term and change the model - such as using a tag like pointGroup. Or do we just hijack the existing tag and term equip. Since the common case is equipment, I lean towards hijacking equip so we can continue to use equipRef to associate a point with its equip

One of the biggest challenges haystack has is that balance between simplicity and clarity - in this case I concede that the simplicity gained in hijacking the equip is more valuable than clarity lost by someone having to get used to equip not exclusively being an piece of equipment

I've talked to a few people on the phone about this issue and I think hijacking the "equip" term is the most pragmatic decision. Most points are associated with a piece of equipment, two common odd ball cases:

• what I would call "site wide" points like occupancy, outside air sensors, and things like that
• system level points like points on the chiller plant level (for example leaving and entering temp of the entire plant itself)

Although not perfect, I think just using the equip tag to group these points and force them into an "equip" grouping is the simplest design route. It gives us clean, basic three levels of organization (not there can't be more).

One other thing I'm going to suggest is that equipment can be "nested" by applying the equipRef tag on an equip entity itself. That lets you model something like a chiller or boiler plant as an equip, but still contain sub-equipment.

We have prototyped both of these ideas in next SkySpark build and they seem to work really well.

This issue has been open for a while now, so I'm going to consider it decided unless there is strong disagreement:

1. all points must have an equipRef
2. catch all groups of points should just be modeld with equip tag to allow compliance with previous rule