New version has been posted. See previous version notes:

• 3.9.3 topic 694
• 3.9.2 topic 687

Synthesized Children

This build prototypes a new mechanism to synthesize all the different combinations of equip and point tags. There are different ways to go about it, but this design starts from hand curated equip sub-parts and then recursively iterates. For example:

1. Chiller says its has a chilled-water-leaving-pipe
2. Pipe says it has a {conveys}-{section}-temp-sensor
3. That generates chilled-water-leaving-temp-sensor

Currently this generates defs with the "synthetic" marker. These synthesized defs show up in the docs, but are not first class defs that are considered part of the ontology.

What we have generates fairly complete docs for the points and containment. However there are two looming questions:

1. how aggressive or hand curated should "expansion" of combinations be?
2. should these be first class defs or something "else"?

Pages to see this in action (NOTE things have changed since this post):

• equip listing
• point listing
• ahu children

Ontology Changes

There are significant enhancements the ontology itself:

• flushed out a taxonomy for coils under heatExchanger
• flushed out a taxonomy for motor/vfd/fan/pump
• flushed out a taxonomy for actuator/valve/damper

ChangeLog

Version 3.9.4 (3 May 2019)

• New synthesizer design
• Rework mixins to use mixinOn/mixins tags
• Rework fan, damper, pump, valve to be both point and equip
• Add motor/vfd as supertype/mixin for fan/pump
• Add actuator as supertyper of damper/valve
• Rename uv to unitVent and subtype from fcu
• Add movingWalkway
• Add coils and associated subtypes as a type of heatExchanger
• Flush out pointFunction, pointSubject, and pointQuantity

I'm trying to wrap my head around the Ontology definitions and how we create the instance data.

If I use an ontology definition example from previous presentations:

ahu contains discharge-duct

Looking at ahu in the v4 docs , discharge-duct is listed as a child but no specific relationship type is specified.

2 Questions:

• 1: How do we instantiate both the ahu and child discharge-duct?
  • Create 2 entities and link via eqiupRef? (how did we know we needed equipRef?), or
  • Nest the discharge-duct entity as a dict within the ahu entity?
• 2: Does the contains definition apply somehow?

Cheers,

Patrick

Patrick,

I would not spend much time with the children or synthetic defs in 3.9.4 - it was just a prototype to see how that design direction would work. And it hasn't worked out all that well. I'm working on a new direction which we've prototyped and will post shortly. But there isn't much written up about it (I don't want to spend time writing up a design until it looks like we have something that seems to be elegant).

The fundamental issue is how to treat "children" of equip such sub-equip and points. This drives both documentation and tooling. The primary design options are:

1. Make them first class defs - not good because they are 1000s or 10,000s of them. This has never felt right
2. Make them kind of like defs - this is what is posted currently in 3.9.4 as "synthetic defs" which looks like defs but they are generated on the fly to model things like discharge duct, then discharge duct points, ...
3. Make them something completely different - this is the design I'm prototyping now where they are just Dict instances I'm calling "protos/protoypes"

Making them instance dict "templates" as protos instead of first class defs seems to be the right set of trade-offs.

Hi Brian,

Thanks for the quick response. It's great to hear you working on it as I see some clear use cases for smart tools.

I've since discovered some recent commits on the haystack-defs repo. I think I see where you're going, but I'll wait until you have something more concrete.

Let me know if you need any help.

Patrick