We have upgraded the project-haystack.dev with a new version.

See previous version notes:

• 3.9.5 topic 714
• 3.9.4 topic 699
• 3.9.3 topic 694
• 3.9.2 topic 687

There is a lot of new content in this version to review.

New Chapters

There are several new chapters

• Normalization
• Associations
• Choices
• Protos

Associations and Choices

There is a spectrum of ontological relationships that didn't have very precise terminology.  While writing up the documents, I tried to tighten up the terms and concepts.

I was previously using the term aspect for def-to-def relationships to distinguish them from instance data relationships.  I renamed this concept associations.  These are strictly relationships between defs such as "is", "tagOn", or "quantityOf".  See new chapter.

Choices are a mechanism of enumerations leveraging subtyping for late binding (you can add new choices by creating new subtypes).  More importantly they have the concept of narrowing in the taxonomy and into actual instance data. See new chapter

Instance relationships and associated filter enhancements hasn't had any new work.  I would consider those docs still just a straw-man proposal.

Protos

A long standing and thorny problem during Haystack 4's design has been how to model the typical children points of a given equip.  In the last version, we tried out a new concept called "protos" or "prototypes".  After several months of working with this concept, it seems to be an ideal solution.  I've written up a new chapter on the design.

Plus I've added a new point protos index.  These point protos are often what people want when they are looking for an exhaustive "point type list".  But unlike first class defs, these prototypes are auto-generated from the ontology based on combinations of tags.

Zone Points

We've ported over all the various zone setpoints as children of thermostat and hvac-zone-space.  These points are often bound as children directly under VAV, AHUs, FCUs, etc.  This works out by having thermostat as potential child of airHandlingEquip and airTerminalUnit with point flattening (covered in new Protos chapter).

Panels

I ported over elecPanel tag via a new panel taxonomy which includes elec-panel and controls-panel.  We probably need a more thorough review of electric panels and circuits from 3.0 ontology, so I'm going to leave that as is for now.

Data Centers

There is a stubbed out a basic ontology of dataCenter which is a subtype of space.  

It contains CRAC units and also racks which subtypes equip.

Getting into data center modeling and device networking, requires dipping our toes into a device modeling.  I have stubbed out a very simple device taxonomy which needs some review and discussion.  The basic idea is that phIoT::equip is for physical assets, sensors, etc and phIct::device is for microprocessor based devices (servers, routers, controllers, etc).

ChangeLog

Version 3.9.6 (25 Sep 2019)

• Remove pointKind and use kind to keep it back compatible
• Replace mixinOn concept with tagOn
• Refactor choice to subtype directly from symbol
• Rename aspects to associations
• New Normalization chapter
• New Protos chapter
• New Associations chapter
• Zone setpoint ontology
• Space subtypes appendix
• Point protos appendix
• Add panel, elec-panel, controls-panel
• Stub simple device taxonomy
• Stub simple dataCenter, rack tags
• Apply tagOn to ref tags

This looks awesome, Brian! Cool stuff. I really like the Protos structure, and how thermostat fits into the standard.

Hey Brian,

I was looking at the new protos section, and looking at the pipe example. The children listed under it are:

1. pump motor equip
2. valve actuator equip
3. flow point
4. pressure point
5. temp point

I don't fully understand why the first two are children of pipe...can you elaborate?

I don't fully understand why the first two are children of pipe...can you elaborate?

From just a simple perspective its because pumps and valves are placed in piping. Likewise fans and dampers are placed in ducts. Both equipment are used to move and regulate fluid/air of their parent conduit respectively.

There was very long discussion about fans and pumps in Haystack 3 that led to the discussion they can be either sub-equip or a point.

In Haystack 4 we formally capture these rules using a couple of techniques:

1. We list pumps, valves, fans, dampers as sub-equipment of their respective conduits (for example any pipe can contain a valve)
2. We specify a child flattening mechanism to model when you can omit a level of the ontology in your instance models

You can see how this works in the prototypes as a series of nested equip:

chiller equip
  chilled water leaving pipe equip
     chilled water leaving pump motor equip
       chilled water leaving pump equip
         chilled water leaving pump run state point

Protos take a bit to grok, but they have turned out to be a super powerful tool. They let us formally model what people do today in their models. But they also provide formal definition for modeling individual ducts and pipes if/when people want to model that level of detail.

I see - ok, thank you Brian! I think I need to spend some time doing deep dive on protos. Also, do you know of any recorded talk from Haystack connect introducing 4.0? Sometimes video explanations can be very helpful - thanks.