2018 04 11 WP1.2 BOPTEST Toolchain Working Group

WP1.2 BOPTEST Toolchain Working Group Meeting

Agenda

1. Handling local loop and supervisory control
2. Software stack and architecture
3. Documentation and hosting
4. Other topics
5. Next steps

Meeting Information

Topic: BOPTEST Toolchain

Time: Apr 11, 2018 8:00 AM Pacific Time (US and Canada)

Join from PC, Mac, Linux, iOS or Android: https://lbnl.zoom.us/j/653784360

Or iPhone one-tap : US: +16465588656,,653784360# or +16699006833,,653784360#

Or Telephone: Dial(for higher quality, dial a number based on your current location): US: +1 646 558 8656 or +1 669 900 6833 Meeting ID: 653 784 360 International numbers available: https://zoom.us/u/dH9wDTTDj

Minutes

Participants

1. Roel DeConinck
2. Filip Jorissen
3. Krzysztof Arendt
4. Javier Arroyo
5. Sen Huan
6. Kaustubh Phalak
7. David Blum
8. Lisa Rivalin

Handling Local Loop and Supervisory Control

Questions:

1. Can we theoretically split?
2. What is architecture of splitting? (e.g. separate models or fmus, or outside of emulator)

Issues:

1. Many MPC solutions rely on local loop control and only implement "setpoints" as supervisory control. Requiring development of local-loop controllers could burden these developers.
2. However, some MPC and other advanced control solutions may wish to control actuators directly, and so this capability is warranted. In addition, it is not always clear for a building what is "local-loop" and what is "supervisory" control. For instance, in a known case of concrete core activation, the BMS supplies valve positions and not setpoints for temperature. In the case of Single Zone VAV control, the BMS supplies fan speed directly, instead of static pressure setpoint.

Consensus:

1. It is hard to formalize the split between local-level and supervisory controller for every case.
2. Therefore, it is up to the emulator developer to decide for specific emulator case, which points are exposed for control. All actuator signals should be exposed for override, with default low-level control signals being provided by the emulator developer to the extent possible. A peer review process will be used for emulator models, during which it will be determined if what is exposed is appropriate for control.
3. There also needs to be development of "overriding/prioritization block" for control signals that are exposed.

Meeting adjourned short of addressing other topics in the agenda. These will be addressed in future working group meetings.