Logic Blocks in Brick

[schneider82]

As we go deeper into our building structure we are trying to add logic blocks to our brick model. Examples of this would be Schedule and Loop.

Although there are parameters for loop it makes logical sense for them to be grouped, and there are variations of loops that would be good to capture. There is also nothing for Schedules formally in the Brick model or am I missing something? Schedules are critical parts of a building automation system. but I think a way to extend logic blocks would be a great addition to the formalised standard.

[gtfierro]

Hi @schneider82 --- this is something that we've discussed on and off for some time now, but never settled on a design. @epaulson was working on some "schedule" modeling that was derived from some of the schema.org work, for example.

With the emergence of CDL/ASHRAE 231P, I think it may make sense to adopt some of the "function block" model that @JoelBender has been working on. My understanding is these can be black boxes that can represent arbitrary logic, but can codify the relationship of the input/output points to that function block. I don't think we want to be in the business of defining the logic itself --- this is better done as CDL descriptions, pointers to external code references, etc --- but we can at least model the existence of the logic and the relationship of Brick points/entities/etc to that logic. What do you think?

[gtfierro]

This would be an excellent candidate fora future ontology working group discussion as well!

[epaulson]

@schneider82 - could you be very specific on what you mean by 'loop'? It's an ambiguous term here, because we have things like 'chilled water loops', which I'm pretty sure is not what you're talking about. (I'm also pretty sure I know what you're talking about but even then there is some variation on what I think you could mean, so better to hear from you)

As for schedules, we're just dipping our toes into the water here and aren't going all-in just yet like you can with BACnet, where the schedule includes instructions on what values to change at the boundaries of the schedule. I was thinking a good place to start was just to be able to represent the 'opening hours' of a space, for which there are two good options from in schema.org's definitions - see #385 (unfortunately, there are 2 good definitions in schema.org - they've talked about unifying them but haven't done so yet).

The schema.org version is good enough to tell your analytics application if a space should be "open" or "closed", it's not good enough to fully describe the setback values for the space.

[schneider82]

function/logic blocks I think are key to representing the data in a way that allows better algorithms against Equipment. It would be interesting to have spaces with opening ad closing times and then be able to have equipment schedules to ensure an Optimum start-stop to allow the building to hold condition while tenants are occupying the space. The question though must start with is Logic/Function block a superclass or can it be argued as part of equipment or something else? Given it "regulates"/"is regulated by" one could argue it is a subclass of equipment. Another way to look at it would be the "old school" version of it would have been a device with input and pods thus it would be equipment. a schedule block represents a timeclock for instance.

I would love to be part of any discussion on this as it is a core part of the software we are developing. Our assumption will be for now that it is a sub class of equipment, which we will add via our own ttl for the moment.

[schneider82]

Had a few discussions over the weekend and today about logic. It is our belief logic should be a subclass of equipment. Then for schedules, we can use the well-defined events from RDF we can define all the days and their events. This is completely flexible and allows for massive event lists.

https://www.w3.org/TR/rdfcal/

So Under Equipment would be a subclass Logic under Logic would be Schedule and Loop and any other logic we start to need for an algorithm in a digital twin. I will have a chat with my guys and generate a TTL example of these so it can be discussed and hopefully added to the Brick Schema.

[JoelBender]

I attached a Turtle file for an RDF/SHACL version of CDL here and there is active work going on to translate CDL applications to CDX (essentially a JSON version of CDL) and then to RDF. So far it looks like a relatively simple process.

There are some missing pieces (like knowing which "metadata" parameters to associate with a Datatype, and the idea of a "proprietary block"), and there are still some things being actively discussed in the ASHRAE 231P committee like array inputs, outputs, and parameters.

[schneider82]

Joel, That seems to be a representation of the functions. IMHO I think that brick should focus solely on the representation of data. I don't think the interconnection of function blocks or the actual functionality of blocks is as important. I'm only new to this forum but I think it might be a bridge too far and many of the blocks required in a system would be irrelevant. IMH Brick should be focused on outcomes and the variables that give that result. I think representing a function block should be about it's variables not it's function.

[JoelBender]

Yes, there are lots of specific functions that are designed to be implemented in controllers, some of them are trivial and some not so much, but my focus is just the interface; inputs and outputs, datatypes for each one, etc. For example, in Guideline 36 the entire sequence of operations for a VAV box can be represented as a single function block, but there can just as easily be an FDD state machine or continuous machine learning application sitting behind the interface. That's outside the scope of CDL, but the essentials are identical.

[schneider82]

I understand that, but I think the scope of CDL surpasses anything something like brick needs to have, especially in the short term.

Representing the "objects/programming blocks" data shouldn't need anything special added to brick. Integers, Booleans, Floats and Arrays of vEvents are already an option in RDF, so I can't see a reason to add additional functionality. There might be edge cases that use some other data type, but this would be fine for 99.9% of all cases. Arrays are needed for Schedules, but vEvents easily represent that with an addition value field.