Demand Response vocabulary extension: Constraints

[Oisín Grehan]

Hello -- I'm currently working on a vocabulary that will describe a Demand Response (peak shaving) event that will be sent to aggregators to execute, and the idea is to declare a schedule that will put _constraints_ on DERs in the form of a brick:Limit (for power, i.e. don't go over 80% for an EV charger, or don't exceed 1kW load), but there doesn't seem to be any generalized "constraint" vocab in Brick that would be more semantically acceptable to associate with a Setpoint, like 8.3.3.3 IfcObjective - IFC4.3.0.0 Documentation (buildingsmart.org)   (which replaced 2.x IfcConstraint)  -- is there anything in Brick you could suggest, or do you have another vocab recommendation that I could use to augment Brick here?

-Oisin

[Ben Bartling]

Hi,

I am familiar with open ADR and work with it in research a bit. We use open Leadr, could Brick ever be tailored to be similar to open ADR representation? 

Thanks,

Ben

On Tue, Jun 6, 2023 at 2:32 PM Oisín Grehan <ois...@gmail.com> wrote:

Hello -- I'm currently working on a vocabulary that will describe a Demand Response (peak shaving) event that will be sent to aggregators to execute, and the idea is to declare a schedule that will put _constraints_ on DERs in the form of a brick:Limit (for power, i.e. don't go over 80% for an EV charger, or don't exceed 1kW load), but there doesn't seem to be any generalized "constraint" vocab in Brick that would be more semantically acceptable to associate with a Setpoint, like 8.3.3.3 IfcObjective - IFC4.3.0.0 Documentation (buildingsmart.org)   (which replaced 2.x IfcConstraint)  -- is there anything in Brick you could suggest, or do you have another vocab recommendation that I could use to augment Brick here?

-Oisin

--
You received this message because you are subscribed to the Google Groups "Brick User Forum (Unified Building Metadata Schema)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brickschema...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/41485f33-aa71-42c4-a4ce-af3c674126dan%40googlegroups.com.

[Oisín Grehan]

After sleeping on it (man, the life of an amateur ontologies is tiring!) I realize that for any given Demand Response program, the practical effect of a setpoint constraint is to lock it at a certain value. That said, the _desired_ plan could be defined as a Limit with a Max value for the setpoint because during peak shaving a value less than this would be beneficial for the program's goals, so there is effectively no minimum. Some aggregators might do a forced opt-out for any manual change of the setpoint during a peak shaving event, but the cleverer ones might ignore changes to a lower temperature (in the context of a heat demand, as a cooling demand would be the reverse.)

Anyway, just sharing my thoughts.

[Matt Steen]

There's also https://github.com/LBNL-ETA/EnergyFlexibilityOntology, in case you haven't seen it.

[Gabe Fierro]

This is an interesting problem!

I'm aware of this paper which dug into a few of these issues, including working with DR events but I don't think the constraints on responses to DR events were ever expressed in the RDF graph. For basic plans that just stick with hard limits on setpoints I think the proposal you suggested works great. The challenge comes if we ever want to be able to express something more complex than that -- it quickly devolves into trying to express some sort of imperative logic in RDF. In this case, we could probably use an RDF version of Control Description Language (one is already in progress) to express the constraint logic.

I'm starting to chat with the Energy Flexibility Ontology folks so I can learn more about their approach. I don't think they are expressing the logic in RDF either -- instead they standardize describing the data needed for different energy flexibility strategies.

Oisin --  how do you want to use the information with a Brick model? I think understanding your use cases will help me figure out a good direction.

Best,

Gabe

--

You received this message because you are subscribed to the Google Groups "Brick User Forum (Unified Building Metadata Schema)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brickschema...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/d657eae6-699c-4b60-b91e-099243c98b79n%40googlegroups.com.

[Gabe Fierro]

I think so! I can see that being a helpful integration. Do you have any particular modes of interaction in mind?  One thing Brick can do is point to external digital resources like BACnet objects, IFC objects, Modbus devices, etc. Maybe Brick could also represent VEN/VTN info (address, etc) as well as a DR response ‘stream’ as a kind of Point?

To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/CADJmWLK%2B%2BvQKKD72-kLyG7w5pMVOou5ObF1wpA3ej6sg-a_Mwg%40mail.gmail.com.