dhblum
commented
1 year ago Thanks @epaulson for reporting. I understand what you are requesting and the reasoning behind it regarding bacnet priorities, and being able to mimic such behavior in BOPTEST.
Regarding implementation, it will take some effort, though not totally unreasonable. My suggested solution at the moment is based on the description of the signal exchange block usage in the design documentation under Section Control and Sensor Signal Exchange in Modelica Subsection Parsing and FMU Export. There, I would suggest adding an additional output for every overwrite block that connects to the overwrite block's connected input in the Modelica model. A key question would be what to name the point, how to describe it, and how to manage exposing it to a user so as not to cause too much confusion. Maybe something simply like <block_instance_path>_default is sufficient, and describe the point as the control signal always representing that which is generated in the embedded control, regardless of whether being overwritten or not. Open to suggestions though.
Some of the test cases have an internal control schedule - for example, the multizone office simple air testcase has an internal occupied/unoccupied schedule that goes through a couple of different states and a number of setpoints that it adjusts depending on the time of day - see table 2 here: https://ibpsa.github.io/project1-boptest/docs-testcases/multizone_office_simple_air/index.html - for example, at 5:30am, the building goes into 'unoccupied warmup' and changes TZonHeaSet from 12C to 20C.
In the BACnet proxy, I've been creating BACnet 'Analog Value' (AV) objects for these different settings, and I update the 'presentValue' of the analog object based on what comes back from calls to /advance endpoint, so if something is watching via bacnet they'll see that change in the setpoint go from 12C to 20C
To change a value, one would use a BACnet client to write into the 'priority array' for the AV object. The proxy takes the highest priority value from the AV object and passes it in as a parameter to the /advance endpoint to change the boptest version, along with flipping the corresponding _activate parameter to be TRUE so boptest uses the new value.
To stop overriding a value, you use a BACnet client to write a NULL into the priority array at the slot you previously wrote to. If someone else was overriding the value at a higher priority level, that means they're still in charge, if someone has written to a lower priority level, now their change becomes active. You can see more about how that works here: https://store.chipkin.com/articles/bacnet-#:~:text=The%20Relinquish%20Default%20Value%20is,to%20set%20the%20Present%20Value.
So what happens when the last client deletes themselves from the priority array? Well, in BACnet, the controller usually updates the presentValue back to the 'relinquish default' parameter for the object, which you could think of as the slot in the priority array with the lowest possible priority.
In the BACnet proxy, I don't know what the relinquish-default value should be because it might be changing depending on what the built-in schedules are set to do.
This is a low-priority feature request because what I do today is just don't set anything and unset the _activate parameter, which means the default program comes back into play, but it'd be great to get as part of the response to /advance what the values of any of the inputs would be if they weren't being overridden so I could keep the relinquish-default values correct and available.