Introduction and Background

The physical properties of facades have a determining effect on the energy and comfort performance of buildings. This is particularly the case for windows, which need to perform multiple functions such as providing view, privacy, solar control, acoustic insulation, and thermal insulation. The desired balance between these functions usually varies, not only with time of day and time of year, but also with occupant preferences. For this reason, automated fenestration systems, in the form of automated shades or dynamic glazing, are considered a key technology for optimizing the energy and comfort performance of windows [1].

The impact of automated facades on building performance is mostly indirect, i.e., realized through the effect of the façade on other building systems, such as lighting and HVAC. As facades modulate the amount of visible light and solar heat gain that is admitted into the building other building systems react to the changing environmental conditions inside the space. Lighting systems detect changes in light levels in the space and can respond by changing the amount of artificial light provided to the space. HVAC systems detect changes in indoor air temperature and can respond by changing the amount of heat provided to or removed from the space. This indirect coupling between the operation of the façade and the rest of the building is what happens in standard building practice.

Previous research studies show significant energy benefits from going beyond this indirect coupling towards operating the façade and other building systems as a single system [2, 3]. These benefits include significant reductions in energy use as well as enhanced ability to temporally shift electricity use according to the needs of the electrical grid or in order to minimize electricity costs. Despite these potential benefits, in standard building design and construction practice, automated facades are overwhelmingly specified, installed, commissioned, and operated separately from other building systems. When integration between facades and other building systems takes place, it is often time-consuming and labor-intensive to implement, e.g., requiring custom wiring. Integration becomes even more challenging in existing buildings, where existing building systems may not be set up to easily communicate with a new automated façade system.

This status quo suggests a pressing need for tools that enable communication between automated facades and the rest of the building and ultimately allow their operation to be integrated with the operation of other building systems. This paper introduces such a tool, which is in its development stage, and describes initial tests performed in a full-scale building system experimentation testbed.

OpenFacadeControl Introduction

To resolve the challenges causing facade integration to be time-consuming and labor-intensive, Lawrence Berkeley National Laboratory (LBNL) developed OpenFacadeControl (OFC). OFC is a publicly available\*1, open source, Volttron-based communication and control platform designed to enable integration of facade, lighting, and other building systems. The two goals of OFC are to 1) enable communication with as many devices as possible, overcoming the challenges posed by a lack of interoperability, and 2) provide an easy deployment platform for advanced facade control algorithms.

To accomplish those objectives, OFC is based on the following governing design goals: 1) include communication capabilities matching as many communication protocols as possible, 2) be able to communicate with any/all communicating devices, 3) be able to operate multiple control algorithms, each controlling different devices, or groups of devices, as specified by the user, 4) provide easy access to needed inputs such as weather forecasts or electricity price schedules, 5) provide a simple, user-friendly pathway for transitioning controls from algorithm development to deployment in real buildings, and 6) leverage publicly available tools to facilitate ease of use.

OpenFacadeControl accomplishes these design goals by:

• Leveraging Volttron: Volttron is a publicly available, Python-based building control platform developed by Pacific Northwest National Laboratory (PNNL) [4]. This highly flexible platform enables users to both access PNNL’s control algorithms and develop/deploy their own scripts. Volttron also includes useful scripts, such as one that accesses weather forecasts from the National Oceanic and Atmospheric Administration (NOAA).
• Python-based: All OFC code is programmed in Python, one of the most popular computer programming languages, ensuring that the platform remains accessible to many users.
• Streamlined deployment: OFC is being designed to separate control scripts from communication scripts, enabling rapid switching from controlling simulation models to buildings. The goal is to enable, e.g., in cases with highly detailed simulation models, for deployment to be achieved by simply deactivating the simulation model and activating communication with the real building.
• Parallel control: Volttron, and by extension OFC, is capable of running many control algorithms simultaneously. This enables controlling different pieces of hardware, or groups of devices (e.g., lighting, shading, and sensors), with different control algorithms, enabling flexibility in algorithms deployed throughout a building.
• Pre-programmed communications: To streamline deployment in as many buildings as possible, OFC includes pre-programmed scripts that communicate via the BACnet standard for building communications [5], internet-protocol-based application programming interface (API) matching the specifications of several manufacturers, and 0-10 V signals.
• Open-source: OFC is intended to remain freely available to all users including access to the core code. Integration with manufacturer proprietary controls is intended to take the form of communicating directly with non-accessible code ensuring that OFC can remain open-source in the future.

OpenFacadeControl Architecture

Figure 1 presents the architecture of OFC. All OFC code is contained in the green box in the center of the schematic, while other images and lines show the connections between OFC and the other hardware or data sources involved.

Figure 1: OpenFacadeControl Conceptual Diagram

OFC is split into communication and control agents. Communication agents gather data from or send data to hardware or servers outside of OFC itself, while control agents interpret the data and develop new control signals accordingly. This separation of communication and control supports flexibility; many different communication agents can communicate with hardware or servers from several different manufacturers and provide that information to the control algorithm(s). Meanwhile the control algorithm(s) can develop the optimal control signals without needing to understand the communication methods.

The communication scripts are designed to gather data from and send data to several different external devices. Some common examples include:

• Weather forecasts, such as those from NOAA or a different local weather forecast service
• Local electricity prices, such as those from the LBNL’s CalFlexHub price server [6] or the California Energy Commission’s Market Informed Demand Automation Server (MIDAS) [7]
• Measurements from on-site sensors, either associated with a particular building system (e.g., exterior irradiance sensors from an automated shading system), or standalone sensors (e.g., an interior CO2 sensor)
• Status indicators from software, e.g., indicating a particular action (lowering or raising shades, or reporting that some hardware has gone offline

OFC is designed to enable easy deployment of advanced control solutions. This includes two key features:

• Hosted on OFC: Advanced control solutions can be included directly in the OFC repository, and can thus be distributed as part of the OFC package. This enables easy access for those interested in using them. Further, it enables programming the control and communication agents to facilitate easy connection, supporting deployment in the field.
• OFC is being developed to enable connection to simulation models and to include a preliminary simulation-based toolchain for evaluation of control algorithms. Including the simulation testbed directly in the deployment pathway will facilitate deployment of advanced control solutions. If the simulation model developed for developing and testing controls uses the same point names as the real building, then transferring the controls from simulation to the field can be as easy as deactivating the simulation environment and activating the building communication scripts.

Case Study: Description

To demonstrate the benefits of integrating control of lighting, facades, and HVAC systems, ITRI performed laboratory testing of their advanced control algorithms at LBNL’s FLEXLAB facility. The project leveraged OFC to establish communication between CREE lights that communicate via web API, Mechoshade roller shades that communicate via BACnet, and photosensors connected to FLEXLAB’s data acquisition system. FLEXLAB has four test beds, as shown in Figure 2, and each test bed consists of two side-by-side cells with the same dimensions and construction. The rotating test bed used in this study consists of a pair of matched cells,with dimensions D:9.6 m × W:6.3 m × H:2.7 m. The pair of matched cells allows conducting side-by-side comparable tests, and the rotating facility allows conducting tests with the different façade orientations. Tests evaluated the performance differences between two shade control scenarios and a baseline scenario without shade.

Figure 2: Exterior view of FLEXLAB at LBNL

Case Study: Method and Test Plan

In their original state, the two adjacent cells in FLEXLAB's rotating testbed are practically identical in size, energy consumption, indoor environmental conditions, and daylight availability. This study implemented automated roller shades with shading control in one cell while keeping the other in an unshaded state, as a baseline. This allowed understanding the differences in indoor energy consumption and visual comfort performance resulting from shading or different shading control methods through the tests.

Two shade control strategies are implemented in this series of tests: Solar Penetration Control and Desktop Illuminance Control. Both shade controls were programmed and coordinated using OFC. The shade fabric is black in color and has a 3% openness, allowing limited light to transmit indoors. Table 1 provides details on the utilized control strategies.

Table 1: Details of the Baseline, Solar Penetration, and Desktop Illuminance Control Strategies

Table 2 presents details on the lighting, HVAC, and internal gains setup for the experiment, including hardware, setpoints, and control strategy. Identical HVAC, lighting, and internal load settings were implemented in both cells, simulating typical office scenarios. Specifically, LED lighting was equipped with dimming controls set at a threshold of 500 lux for desktop illuminance.

Table 2: Details for the lighting, HVAC, and internal gains

Tests were conducted in May 2023, with the equipment and sensor configurations of the test cells depicted in Figure 3. Both cells were equipped with four workstations, corresponding mannequins, and plug load emulators. Illuminance sensors were placed on each office desk for lighting dimming and shading control. The HVAC load, lighting energy use, plug load energy use, real-time horizontal illuminance, indoor temperature were monitored and recorded in both cells. Additionally, glare levels were detected and recorded using HDR cameras.

The overall plan included two sets of tests: one with the facade facing west and the other with the facade facing south. For the sake of brevity, this paper focuses solely on the results of the tests with the facade facing south. The test configurations are outlined in Table. 3.

Figure 3: The test layout of the test cell

Table 3: Test plan

The hardware communicated using the architecture highlighted in Figure 4. Interior light levels were measured using a LI-COR LI-210R photosensor, which provided illuminance measurements to the FLEXLAB data acquisition system using a standard BNC cable. An API communicating over SSH read the current brightness in the space from the FLEXLAB server and made it available to the OFC control scripts. OFC then implemented the control logic and sent shade position commands to the shade via BACnet, and to the lighting system using CREE’s API over HTTP.

Figure 4: Utilized communication architecture in the laboratory testing

Case Study: Results

Based on the aforementioned test plan, we collated the test results under clear weather conditions with similar outdoor temperatures, and analyzed cooling load, lighting energy, and Daylight Glare Probability (DGP) to compare the performance of each test cell in different control scenarios.

1. Cooling Load

Under clear skies and with the facade facing south, in the scenario without roller shades (Baseline) the daily cumulative cooling load ranged between 7 to 12 kWh. Implementing roller shades with Desktop Illuminance Control resulted in a reduction of 15.1 to 25.1% in cooling load compared to Baseline. Similarly, implementing roller shades with Solar Penetration Control led to a decrease in cooling load by 11.5 to 17.5% compared to Baseline, as illustrated in Figure 5. The results indicate that both roller shade control strategies significantly reduce cooling loads. It appears that the Desktop Illuminance Control has a stronger effect in reducing cooling loads. This is likely due to the fact that the Desktop Illuminance Control consistently recommends a lower shading position compared to the Solar Penetration Control, which is shown in Figure 6.

Figure 5: Cooling load and cooling load reduction results of each test day

2. Lighting Energy Use

The lighting electricity results indicate that, under clear skies and south-facing facades, in the scenario without roller shades (Baseline), the daily lighting energy consumption ranges from approximately 0.1 to 0.12 kWh. Implementing roller shades with Solar Penetration Control resulted in a similar daily lighting energy consumption of 0.1 to 0.12 kWh. However, implementing roller shades with Desktop Illuminance Control led to a notably higher daily lighting energy consumption of 0.53 to 0.54 kWh, as illustrated in Figure 5. The disparity in lighting energy consumption between the two roller shade control strategies primarily arises from the fact that Desktop Illuminance Control sets a threshold of 1,000±30% Lux for window-side desktop daylight illuminance to regulate roller shade position. This results in shading deployment for longer periods and lower shade positions throughout the day, leading to reduced inner-side desktop illuminance and necessitating supplemental electric lighting for longer periods.

Figure 6: Lighting output power and shading position results for each scenario

Figure 7: Desktop illuminance and shading position results for each scenario

Contrasting the data depicted in Figures 6-7, it is evident that when artificial lighting control is set with a desktop illuminance threshold of 500 lux, in Baseline scenario, only a minor supplement of electric lighting is required for the inner-side desk area during the evening hours (17:00 to 18:00), with no electric lighting needed for most of the day. With roller shades and Solar Penetration Control, the roller shades are only lowered to position 1 during 11:00 to 13:00, resulting in minimal deviation in daylight admitted into the space when compared to Baseline; the lighting demand is therefore similar to Baseline. Conversely, roller shades with Desktop Illuminance Control lower the roller shades throughout the day to regulate the window-side desktop daylight illuminance at 1,000 lux±30%, resulting in insufficient illuminance levels at the inner-side desks, necessitating supplemental electric lighting to meet the 500-lux requirement. Consequently, the lighting output power for the inner-side desk area is relatively higher.

3. Visual Comfort (Glare)

Visual comfort was assessed using the Daylight Glare Probability (DGP) index. Jae Yong Suk et al. [8] compared various metrics and determined that DGP is the most effective in assessing imperceptible and intolerable glare situations. The DGP thresholds for different levels of glare are suggested by J. Wienold et al. [9] and are listed in Table 4. This study primarily focused on glare events in areas facing windows. HDR cameras were installed at eye level (1.1m) to detect glare events, and the performance of DGP was analyzed under different scenarios of roller shade and lighting controls.

Table 4: DGP thresholds and descriptions for different glare levels

Figure 8: DGP results (facing windows) of each scenario

We selected two sunny testing days, May 17th and May 22nd, with identical baseline daylight conditions, to compare the visual comfort performance among the Baseline, Solar Penetration Control, and Desktop Illuminance Control scenarios, as depicted in Figure 8. Due to the clear weather and bright sky, along with direct sunlight entering the test cells between 09:00 and 17:00, glare is intolerable when facing the windows in both Baseline and Solar Penetration Control scenarios, resulting in DGP>0.45 for an extended duration. During the same period, while implementing roller shades and Desktop Illuminance Control could not maintain DGP below 0.35, it significantly reduced DGP to a range between 0.35 and 0.45, demonstrating an effective mitigation of glare interference compared to both Baseline and Solar Penetration Control scenarios.

Overall, the OFC framework facilitated the integration of various shading and lighting control scenarios, enabling effective testing and comparison of different control settings, and helping the research team optimize the integrated control strategies.

Conclusions

Despite research showing significant energy and comfort benefits, integrating the control of lighting, facade, and HVAC systems has remained challenging. Current standard practice is to not integrate between systems, and the projects that do include integration require additional hardware and costly labor-intensive installations. These limitations in the status quo make it difficult to capture the demonstrated benefits of integration.

To resolve that issue LBNL has developed OpenFacadeControl, an open-source, Python-based platform designed to streamline integration of facade systems with the rest of the building. OpenFacadeControl includes pre-made scripts to communicate with equipment from various vendors using methods, such as webAPI or BACnet, and the ability to operate numerous different communication scripts simultaneously. These capabilities enable rapid connection to products from multiple vendors using different protocols. Furthermore, OpenFacadeControl can host and operate several control algorithms, enabling deployment of different control algorithms to different devices or areas of the building.

ITRI recently tested their advanced controls for lighting and facade systems at LBNL’s FLEXLAB facility. Leveraging OFC enabled them to quickly establish communication between and control of CREE lights that communicated via web API, Mechoshade automated shades that communicate via BACnet, and a photosensor connected through FLEXLAB’s data acquisition system. The tests compared the following two control algorithms: 1) Solar penetration control, which adjusted the shade position to limit the penetration of sunlight into the space, and 2) Desktop illuminance control, which adjusted the shade position to optimally provide appropriate desktop illuminance on a window-side desk. The desktop illuminance control showed the best performance on glare control, reducing the average DGP in the space substantially across the workday. Both the solar penetration control and the desktop illuminance control reduced lighting + HVAC loads compared to baseline, by 14% and 17% respectively.

This work was supported by the Assistant Secretary for Energy Efficiency and Renewable Energy, Building Technologies Office, of the U.S. Department of Energy under Contract No. DE-AC02-05CH11231.

[1] Harris, C., 2022. Pathway to Zero Energy Windows: Advancing Technologies and Market Adoption (No. NREL/TP-5500-80171). National Renewable Energy Laboratory (NREL), Golden, CO (United States).

[2] Lee, E.S., Gehbauer, C., Coffey, B.E., McNeil, A., Stadler, M. and Marnay, C., 2015. Integrated control of dynamic facades and distributed energy resources for energy cost minimization in commercial buildings. Solar Energy, 122, pp.1384-1397.

[3] Gehbauer, C., Blum, D.H., Wang, T. and Lee, E.S., 2020. An assessment of the load modifying potential of model predictive controlled dynamic facades within the California context. Energy and Buildings, 210, p.109762.

[4] Pacific Northwest National Laboratory. (2023). Volttron | Devices | Data | Decisions. Volttron.org. Accessed on June 13, 2023.

[5] American Society of Heating, Refrigerating and Air-Conditioning Engineers, 2020, BACnet: A Data Communication Protocol for Building Automation and Control Networks, ANSI/ASHRAE Standard 135-2020.

[6] B. Nordman, M. Pritoni, M. A. Piette, A. K. Prakash. (2022). Communication Requirements for Price-Based Grid Coordination. https://calflexhub.lbl.gov/wp-content/uploads/sites/41/2023/01/BerkeleyLabCommunication-Requirements-for-Price-Based-Grid-Coordination.pdf. doi: https://doi.org/10.20357/B7701H

[7] California Energy Commission. (2024) Market Informed Demand Automation Server (MIDAS). Accessed on February 20, 2024. https://www.energy.ca.gov/proceedings/energy-commission-proceedings/inactive-proceedings/market-informed-demand-automation

[8] J.Y. Suk , M. Schiler , K. Kensek , Investigation of existing discomfort glare indices using human subject study data, Build. Environ. 113 (2017) 121–130 .

[9] J. Wienold , Dynamic daylight glare evaluation, in: Proceedings of IBPSA 2009 conference Glasgow, Scotland, 2009, pp. 944–951.