Hi all!

At Datakwip we are using only the Haystack tags (not the driver(s)) in a schemaless database and indexing the tags so we can group by, filter, etc. One issue we have is enforcing consistency when importing points from various BAS systems on points that, to be properly described, require multiple tags. As an example, "discharge" "air" "temp" "sensor". We are relying on the implementer/integrator to remember that all four of these tags need to be associated with the point, not to mention equipRef, siteRef, etc. The nhaystack module offers some templates and tools that assist with this, but that of course only applies to Niagara. This topic was partially addressed in the following posts:

http://project-haystack.org/forum/topic/25 http://project-haystack.org/forum/topic/473

...but I didn't see a resolution.

One solution would be to create templates of our own for our integrators, but we want to maintain consistency with the community. Anyway, getting to my questions:

1) How have other people handled this? We do not actively use Skyspark (but have a high degree of respect for it), is there a pattern that Skyspark or other Haystack compliant devices/software employ that we could use for solving this issue? Is there something already in Haystack that I'm missing to handle this situation?

2) If the answer to number one is "no" across the board, does it make sense for the community to provide higher level abstractions for the data model? Others have suggested this in a previous post, but not sure how to get this off the ground or it is already happening? These could be "tag sets" where each tag set has a "situation". Ex.

Discharge, Supply, Leaving Air, of an RTU, AHU, CRAC unit -> "discharge" "air" "temp" "sensor".

These tag sets themselves could then be indexed by the key words in their "situation". That way, someone unfamiliar with haystack could "search" the descriptions and find all the tag sets associated with CRAC units.

To clarify, none of this is meant to be a criticism of the existing design paradigms in haystack, I fully recognize the advantages of having individual tags and maintaining them as such. This is more of a workflow issue.

Thanks in advance for your thoughts, Cory Perdue

Hi Cory,

This is a good topic for discussion, here are my thoughts...

Just a review of what I consider the basic problem. Haystack formally defines tags with explicit types - for example geoCity must be a string, with the additional human documentation that it should be a city name. Formalizing name/value attributes is fairly easy and straight forward.

But when we look at the site tag, it carries with it a bunch of implicit assumptions which could be formally captured with a more sophisticated type system. Entities with the site tag must have tz, dis tags, might have area, geoAddr tags, etc. I'd call this "compound type" problem because there is a concept of a "Site type" which combines many tags together. That compound type information is not machine readable today, just written up for humans.

Typing atomic tags is pretty easy, but compound type systems are difficult. Which is why we have mostly avoided tackling in Haystack. Some examples:

• XML/JSON Schema: atomic types pretty simple, compound types can get complex
• RDFS, RDFa, microdata: compound type system based on classes with multiple inheritance
• Programming languages: almost all have pretty simple definitions of String, numbers, etc; but compound types get complicated (OO classes, interfaces, mixins, prototype inheritance, structures, etc);

Compound typing solutions require thinking about namespace, indirection, reuse thru inheritance/composition, etc. Furthermore Haystack has gone down a path of "typing" with marker tags. For example site marker is easy to map to a classic type, but discharge is not. Maybe you could say discharge air temp sensor is a type that inherits from point? And if you give that a combination of tags its own name, then can you use that as a level of indirection instead of the individual markers? Tough problems!

So most of what I would consider compound typing today in Haystack is captured in human documentation. What is available in machine readable format is the "point lists" of various equip types such as elecMeter.

I've seen various vendor solutions use concepts such as templates and tag sets. At SkyFoundry we have an internal data driven template solution. But its more for populating and validating forms, and doesn't address some of the tricky type system issues.

But as we see Haystack getting more traction with different vendors and other standard organizations, I think we are probably quickly approaching a point where Project Haystack needs to tackle this issue and provide a standard solution. So now is a good time to get the discussion rolling

Hi Cory,

Internally, we use defined point tagging "collections", which look similar to the points sections in the Haystack docs. For example, on AHUs, we would have a discharge air temp sensor tag collection that, when "attached" to a point, applies the discharge, air, temp, and sensor tags, similar to here.

This has been useful in reducing training required to correctly implement haystack tagging, speeding up haystack tag implementation, ensuring data quality, and making it easy to update existing databases to follow changing Haystack standards. However, it does cause quite a bit of redundancy. One example of this is having to have separate point tag definitions for discharge air temp sensor and return air temp sensor on AHU points, and even duplicating the discharge air temp sensor definition for VAV points. I think we currently have over 520 point tag "collections" defined. The atomic approach is much more flexible and succinct, but harder to implement.

We are very interested in other approaches that have been taken.

Our usage has definitely been focused on SkySpark so far.

Hi All,

Interesting topic, my 2 cents...

Part of the problem mentioned by Brian is that the implicit assumptions and knowledge required for tagging is not explicitly documented in a machine readable format. If software could use and enforce this info, it would improve user experience and ensure consistency between implementations. I acknowledge it does not solve Cory's entire problem of wanting to speed up users adding tags, but it's a step towards ensuring tagging consistency and prevent users forgetting siteRef is required with point.

At VRT when we implemented CRUD ops, we found it necessary to implement some basic features to solve the problem e.g. elementary tag rules, and tag sets.

I'd be willing to help tackle the issue, but we'd first need to establish the best way forward. To start, I think we should work on a method that describes tag rules. As an example, the haystack-validator had defined a rule for discharge here

Regards,

Patrick

Thanks all for the thoughts. I think what we may do is create a document database that has a searchable description for a "tag set", so one document might have to following:

description: "Discharge, Supply, Leaving Air, of an RTU, AHU, CRAC unit" tagSet:["discharge", "air", "temp", "sensor"] shortName: Discharge

We could also import the existing haystack dictionary with those descriptions as well. I like the idea of being able to augment/clarify in the description that is searchable by the user. We also have a need for a short human readable name, hence the shortName attribute.

I recently was sent this academic paper which has some great discussion of some of these issues:

Brick: Towards a Unified Metadata Schema For Buildings

It builds on both Haystack and RDF and explicitly addresses some of the areas of weakness in Haystack right now, include sets of tags and a formal ontology.

Although it seems pretty academic to me (and maybe clunky to implement, if those SPARQL queries are any indication), there are some good ideas in here that could likely be used alongside Haystack or else pulled into Haystack at some future point.

I'm one of the lead maintainers of Brick, and I can confirm that we're very much working on this problem of encoding the body of implicit human knowledge into a form which is machine-readable.

I would definitely agree that the SPARQL queries are a bit crufty, but they do provide a very flexible interface to the model. What this means is Brick can be used as a "low level" data model on top of which other data models (e.g. something like Haystack) could be realized. It is here that we could realize a simpler querying interface

Briefly, I think there's a few things Brick can bring to the table.

1) An example of how a class hierarchy of equipment, points, locations, zones, etc can be formulated. Class names are formulated from a set of tags, so you can use either the class name or the tags to find instances in the model (or explore the ontology itself). We can attach attributes to these classes to specify what kinds of equipment and points are commonly associated with a particular class (e.g. what can I expect from an absorption chiller vs a centrifugal chiller, or a VAV with reheat vs a VAV without reheat).

2) A set of relationships that can flexibly capture how everything is related. Relationships can express concepts like subclasses (so you can reference equipment by a superclass), composition (so you can identify which equipment/points are associated with a piece of equipment) and flows (capture the sequence of equipment/points in a building, such as in an HVAC system or electrical submetering infrastructure). Relationships are bidirectional, so you have both "up" and "down" pointers between instances; i.e. an AHU is aware of the downstream VAVs as well as the VAVs being aware of their upstream AHU. The relationships are also general enough to capture many-to-one and many-to-many associations.

3) A "day one" concern of Brick is how to do this modeling consistently across buildings so that its possible to have portable code that can adapt itself to the structure and equipment inside a particular deployment. The SPARQL queries, while a bit opaque, do make it possible to write "generic" queries that can work over many different buildings. There's details in the paper linked above.

Brian Frank has started a discussion on an implementation of some of these ideas in Haystack over at https://project-haystack.org/forum/topic/551

If you're interested in Brick, we have a mailing list, example building models and some basic documentation over at https://brickschema.org/ . Its not all very up-to-date, but we're actively working on it.