Data has the power to shape the future of building design and operationBy Jessica Collier and Michael Poplawski
Given the variety and breadth of data generated during building system design, considerable opportunity exists to use data to support and improve system configuration as well as operation. Once a building reaches operational status, large amounts of data can be collected by today’s building systems and studied to improve future building design. However, in everyday practice this loop simply does not exist.
The roles that data might play in building design and operation go far beyond traditional post-occupancy evaluations. However, in current practice significant barriers exist to harnessing the potential of data for these purposes. Such barriers are less about the creation, digitization, transport or storage of data, or the software needed to analyze it, and more about data access and usability.
Access to data may be limited by standard practices such as legal or contractual considerations during building system design, construction and configuration. Once the building is operational, access to data may be limited by privacy issues. Any inability to understand data also serves as a significant barrier, whether it’s the meaning of the data, the need for or value of it, or the skill to pinpoint which data to employ and which to discard.
Today’s design process does not facilitate efficient information exchange, and as a result, design and construction teams often make uninformed decisions and assumptions based on inaccurate information. These inefficiencies complicate, delay and often compromise decisions regarding system integration and cybersecurity. Too often do issues become apparent after products are on-site and not functioning as expected.
Typically design professionals are only contractually obligated to provide design intent and knowledgeable technical specifications to meet that intent. Their only obligation long-term is to provide a safe building; they are not legally bound to the longterm performance of the building in any way. As a result, large portions of the “intent” behind the design are communicated during the design and construction phases, but may not be captured or expressed outside of project meetings and site visits. For lighting professionals in particular, considerable time can be spent searching for fixtures that meet specification criteria, broader project goals, energy code and control requirements, only to have the products respecified later in the process.
Once the building becomes operational the design team drifts out of any feedback loops, and their expertise does not factor into efforts to identify and close gaps between expected and actual performance. Energy code verification ranges from limited to non-existent, and clients and building operators typically struggle to evaluate performance in other ways. Few performance indicators that use measurable parameters are available to quantify project goals like “productivity” and “satisfaction.”
How can we improve communication and create feedback loops throughout the design, construction and operation phases? Design simulations stipulate assumptions that are linked to the results which inform the specification process. These assumptions and results are typically not shared, or in some cases even documented—but they could be. A common data repository that collected this information throughout the process could inform configuration and define how operational data should be collected and analyzed.
Designers spend significant time developing and documenting lighting control narratives that strive to meet code requirements and user expectations. Much less time is spent onsite to determine if the system was implemented correctly or functioning as expected. How can these control narratives be digitized in a common format for use by system integrators and configuration software?
What about maintenance? Most connected lighting systems can monitor a variety of environmental conditions, but to make this monitoring data useful, fault thresholds must be defined. How can these thresholds be derived from design assumptions, and either modified or further specified, when products are selected?
What about occupants? Do occupants understand how to use the lighting control system? Are they using scene presets as intended, or altering them? Can occupants’ interaction with user interfaces be digitized? Can design expectations be used to define fault conditions that would flag alternative use?
To explore these questions (and more), Pacific Northwest National Laboratory (PNNL) is investigating how prototype building models can be used to evaluate and characterize software tools and workflows that facilitate more data sharing and enable feedback loops. Prototype building models have been used by the Department of Energy Lighting since 2011. They serve as a common baseline to measure the progress of energy-efficiency goals and provide consistency in modeling approaches and analysis across commercial building types. However, lighting is typically modeled in a simplified manner that does not consider how decisions are made during the design and specification process. Paradoxically, research results from these simplified models.
While prototype building-based models typically represent the lighting system as the maximum lighting power allowance defined by code, PNNL’s new, higher-fidelity models define a space-specific lighting layout with realistic luminaire specifications that represent current offerings and performance, as well as clearly defined control strategy, sequence of operations and occupant model (Figure 1).
This model was developed in Autodesk Revit, a leading architectural design software that is capable of both building information modeling (BIM) and creating 2D and 3D visual models. Although Revit is primarily used to coordinate drawing sets in practice, PNNL is exploring how its BIM capabilities might be used to facilitate more design data sharing. In addition, these models will be used to facilitate research surrounding the energy implications of control zone sizing, level of building occupancy or level of code compliance to focus on design decisions that are made with building operation in mind, but rarely evaluated or changed post-occupancy.
Making use of every data input can be a real challenge. It is, however, important to focus any plan for change on use-cases that add value, whether from a workflow or design/operational challenge perspective. These use-cases can then drive the definition of changes—perhaps in personnel, software tools, time or budget—that will facilitate the creation and use of the data for meeting defined use-case goals.
Data can quickly become overwhelming; it can be highly advantageous to start small, perhaps with a focus on just one or two space types. Defining key performance indicators (KPIs) that can be simulated during design and evaluated during operation are essential to forming feedback loops that inform future simulation assumptions, while also identifying gaps between expected and actual performance. Armed with the right KPIs, building owners and designers alike can evaluate design decisions in new ways. Things like capital cost, operating and maintenance cost, interoperability maturity, occupant productivity and tenant experience can be considered.
Data has the power to shape the future of building design and operation. Turning this potential into reality requires specifying and successfully configuring and integrating lighting systems that capture and/or produce the data required to draw conclusions and influence future work. It requires overcoming concerns that data and feedback loops translate to willingly highlighting the mistakes and failures of a project. While these concerns are real, and appropriate, one cannot seek improvements while looking the other way; data can be used to identify both, failures and successes, and manage the sharing of both, risks and rewards.
If you are interested in collaborating with PNNL to develop data sharing strategies and feedback loops in a real-world lighting project, send an email to doe.ssl.updates@ee.doe.gov.