Outcome-driven system integration in smart buildings

Learning objectives 

• Develop an outcome-based methodology for designing smart buildings.  
• Identify key challenges in executing a smart building design. 
• Outline how to define systems integration requirements based on desired outcomes. 

---

The digitalization of the built environment is, if not already upon us, arriving in the next design and construction cycle. Looking at other industries for examples, in the last 50 years the music industry saw the generation, distribution and consumption of music evolve from magnetic tape recording and vinyl records to digital audio workstations and streaming platforms. 

Looking forward, it is easy to conceive that post-millennial consumers of music may never purchase a physical copy of the songs they love. While it may not be as evident on the surface, the technology that drives building systems today is going through a similar shift. Or perhaps it is evident — just ask any colleague who recently attended a conference on the built environment. It is a good bet buzzwords words like “internet of things,” big data, analytics, machine learning or cloud platform were sprinkled liberally across conference marketing materials. 

Smart buildings, intelligent places or connected venues are all terms the industry is using to describe this new way of thinking about how users consume the built environment. While a definition of what makes a facility a smart building is not yet agreed upon, a broad statement of goals and outcomes could be the following: 

• A smart building aspires to be agile, responsive and adaptive to its users. Data generated by the building should continuously inform system operation, enabling the building to take proactive steps, anticipating user needs and optimizing target outcomes. 
• A smart building leverages technology to improve the quality of experience, and provides users contextually relevant information to inform their actions in real time. 
• A smart building provides solutions that bring added business value through data analytics informing organizational decision making.  

We have had smart features in buildings for quite some time. Let’s take, for example, the user experience of a modern sensor-based lighting control system as would be found in an open or private office setting. When a user walks into the space, an occupancy sensor notices their movement and communicates this change to the controller, which in turn triggers the lighting to turn on automatically to some preset value. If the space is at the perimeter of the building, a photosensor is measuring ambient light level and communicating back to the controller, which automatically dims lights up and down to maintain a programmed light level. When the user leaves, the sensor notices the space is empty and communicates this to the controller, which shuts off the lights. Referencing the definition of a smart building above, one could argue this lighting control system ticks most of the boxes for a smart building. 

So why is there so much press about smart buildings these days? Is it just manufacturing hype trying to sell what is essentially the same legacy product with a flashy new front end? Or can we design smart buildings that meaningfully bring value to clients? Compared with legacy solutions, three key features differentiate the design and operation of smart building from a traditional one. 

• Data generation: Characterizing the operation of the building through data are the foundational building block of a smart building. These data are generated through sensors or through system operational reporting. 
• System integration: Connecting multiple building systems, enterprise applications and third-party platforms and enabling them to interact either automatically or manually creates the heart of a smart building. 
• Analysis and response: Creating successful outcomes from a smart building requires the ability to aggregate data from various systems and platforms, make sense of the story the data are telling and act based on that story. This is often referred to as “insights” or “business intelligence.” 

Why have a smart building?  

The features outlined above do not answer the question of why we should propose a smart building, how the architecture, engineering and construction community will design and implement smart buildings or what clients will do with them once completed. What are we as designers of the built environment trying to accomplish by going smart in this approach?  

To identify and communicate value, use cases have become an important component of a smart building design. A use case outlines the desired outcome and the systems and users that interact to generate the outcome. In the context of smart buildings, use cases are a compelling mechanism to connect the design and construction of traditional building systems (mechanical, lighting, security, etc.) to a business need (Do I need to rent more space for new hires, or do I have enough?) through the application of technology. They are critical for defining the “why statement” for a client and for creating a cost model justifying the implementation of systems to enable the use case outcomes.  

They also are instrumental in defining requirements for the features noted above — what data are required, how must systems interact, how will the data be analyzed and presented and who will do something with it. Potential smart building use cases could include: 

• Using weather predictions to sub-cool a building ahead of a heat wave. 
• Advising employees if and when to travel to the office based on current traffic, air quality or colleague availability. 
• Adjusting temperature zone setpoints based on profile preferences of users currently in the space. 
• Dynamically adjusting white noise based on ambient sound levels or signaling users when ambient level exceeds threshold by flashing the lights. 

A common example of a smart building use case is space use. Within the corporate real estate realm, a way to state the use case value proposition might be to “improve workplace efficiency by maximizing the use of office assets (rooms and desks).” Designing an appropriate implementation of this use case requires a thoughtful approach, considering both the implementation and operational aspects of this solution.  

A smart office building 

We will use this example as a case study through the remainder of this article based on the application of a smart building platform at WSP’s Boulder, Colorado, office location. For context, the office is approximately 6,000 square feet and includes a mix of open and private offices, focus and meeting rooms, a café and supporting spaces for 33 full–time employees (see Figure 1).  

Several smart building systems have been installed in the office as part of WSP’s ThinkBOLDR Innovation lab, including a variety of occupancy detection solutions, utility metering, indoor environmental quality sensing, meeting and desk management systems and platforms to ingest, aggregate, analyze and present data to stakeholders.  

The first step is to define its value and agree on the methods by which we will measure its success (often referred to key performance indicators). Why is this step critical? Because we are not just implementing smart building solutions because we can, we are delivering value to stakeholders. Whatever the desired outcomes are, the use case will almost certainly cost more to implement and run than if we maintained business as usual. Just like with any engineering solution where there are options, we designers need to show that the value justifies the implementation costs. Otherwise we are likely to face an uphill battle through value engineering, alternate system evaluations, integration and implementation challenges and operational change management.  

Technology continues to generally improve features in building systems and while there may be little to no capital expenditure impacts for a specific technology, there frequently are integration and commissioning costs that increase the installed cost, as well as operational expenditures to maintain platforms or for continued access to analytics, often referred to a software as a service model. These ongoing costs must also be considered in evaluating the value of any smart building design.  

Finally, the use case must also establish a baseline to identify opportunity for improvement. Using the case study, WSP had a stated goal to improving workplace efficiency. But what is the current space use for various types of program (open/private office, conference, etc.)? Accurately determining the potential improvement is certainly a challenge, as there are various ways to calculate a baseline.  

To assess this, we considered usage data from several sources using similar offices or the previous location of the existing office to establish a baseline workplace efficiency. Relevant data for workplace efficiency might include: 

• The number of full–time employees assigned to the offices (discounted to account for travel and time off). 
• Data from access control badge swipes. 
• Login information for employee’s workstations. 
• Booked meetings in conference spaces. 
• Site surveys manually counting employees. 

These are all data sources that a real estate group might already use to assess real estate portfolio needs and can be used to establish a baseline. There are opportunities for improved survey methods using occupancy sensors that can be temporarily installed to gather a richer dataset around use over a given time period. For the purposes of the case study, WSP established that the baseline workplace efficiency KPI is 50% during working hours.  

Using the baseline, we can then estimate the potential improvement in space use we believe we can achieve through the implementation of a workplace efficiency use case and thus the potential value it might bring. For the case study, it is worth noting that the ability to improve space use may be limited in the short term, as reducing leased space or hiring more employees is not always an option.  

This is something that WSP has explored in assessing the implementation of the ThinkBOLDR Lab. The primary mechanism we have identified for space use value is through identifying ways to add more employees into the same office without impacting experience or through reducing program space that is poorly used for its intended purpose, such as large conference rooms.  

How are data generated?   

Following the definitions of the use cases, desired outcomes and value proposition, it is time to transition to design of the smart building infrastructure. Data generation, system integration and analysis and response form the three pillars of how to approach this design. The use case definitions are key drivers to identify what data are required to be generated to support the desired outcome. There are several types of data a smart building could use. 

Traditional building systems: 

• Presence detection (room or desk presence sensing, people counters). 
• System operation and status reporting (building management system equipment, elevators, audiovisual equipment, motorized shades). 
• Utility consumption metering (energy, water, gas). 
• Location services (asset or user device mobile device location). 
• Indoor environmental quality sensing (carbon dioxide, total volatile organic compounds, particulate parts per million, ambient sound pressure level, light level). 
• Access control (badge swipes). 

Additional data sets: 

• User or device detection (video analytics, Wi-Fi access points, Bluetooth beacons). 
• Enterprise systems or platforms (meeting room availability, user profiles, visitor management). 
• Building-generated data (parking spot availability, amenities).
• Static data (square footage of building spaces, floorplans, locations of desks). 
• Utility rate schedules 
• Weather, traffic, public transportation, transportation network companies.  

Desired use case outcomes often require additional datasets beyond what can be generated by building systems alone to bring maximum value. Generating or accessing this data needs to be considered as part of the smart building design.  

When defining data, it also is critical to consider the accuracy and resolution necessary to support the use case. This resolution needs to be defined both spatially (desk, room, floor, building) and temporally (polled every second, minute, hour, day, etc.). Finally, for some use cases it is important to determine the system resolution (meters on every electrical circuit or just the panel). 

After careful consideration, WSP determined that the use case required an occupancy dataset representing a binary value of each area’s occupancy in 15-minute intervals to achieve the desired outcome. The binary value was “occupied” or “not occupied” and granularity of the data was limited to enclosed small rooms no greater than 150 square feet or approximately 100–square–foot areas within open offices.  

Open office occupancy resolution was used to generate a more representative value of how open offices are used for agile working areas (approximating how many desks are available). Referencing the earlier example of the lighting control system, we determined that the most effective method to generate occupancy data was to leverage code required occupancy sensors in the lighting control system (in many cities and states, this would need to be verified on a case by case basis), augmenting that base system with a higher density of sensors in open office areas than traditionally deployed. Occupancy sensors are, as noted above, one method to assess space use.  

For this installation, occupancy sensors were selected based on the resolution needs of the use case, business systems already in place, product capabilities and cost. However, the choice to use occupancy sensors meant that the data generated would not distinguish between one user in a space or multiple users in the space. Sensors also cannot identify specific users, meaning a moving employee might trigger multiple spaces as occupied. However, occupancy sensor data are broadly anonymous, meaning there is limited exposure to personally identifiable information concerns.  

In an assessment of space use characterization, the largest drawback to using the lighting control occupancy sensors was the inability to distinguish between single and multiple users in the same space. This meant that the dataset could not be used to assess, for example, whether large conference rooms were typically being used by two people or if the restrooms had many users in a single interval. As with any design decision, we needed to evaluate these limitations against the intended use case. 

System integration  

Once the smart building design has identified the data that needs to be generated for all use cases and defined the governing values for resolution of data, system integration becomes the next task. While the aspiration of smart building advocates is that the industry will soon transition to a native internet of things environment where sensors, devices and actuators are connected and communicate with each other at what is referred to as “the edge” (see Figure 3), today’s reality is that most systems are siloed in their traditional design and installation, with a focus on individual system functionality.  

These individual systems provide a dedicated interface or server that can support integration with other systems (see Figure 4). The result is that well-defined system integrations become critical to the success of smart buildings. System integration should include the following aspects within a smart building design: 

• Functional diagram: The design must chart a path for the data, from where it is generated to its destination. This should include all systems through which data must pass, directions of data flow, hosted location of systems (on premises or cloud), storage, analytics platforms and user interfaces (see Figure 5). 
• Communication network: What is the physical networks over which data will be communicated, quality of service, resiliency and redundancy, performance and security? 
• System integrations: This is the connection points between systems, as identified in the functional diagram. Systems integration must define interoperability between systems. 

The systems integration requirements must be defined for each point of connection between two systems on the functional diagram. At each of these points, the integration and interoperability between each system must be defined very specifically. The following items are usually required for system integration: 

• Data shared by the system (occupancy data per space or individual occupancy sensor in open offices). 
• Control capability being given to other systems (i.e., can the building management system temperature setpoints be adjusted by other systems). 
• Communication protocols being used for integration. These would include open standard protocols, with common implementations including BACnet/IP (BACnet using transmission control protocol/internet protocol), representational state transfer application program interface (known as a RESTful API), message queueing telemetry transport, LonWorks and Modbus TCP/IP. 
• Semantic data model and data tagging. Both Brick and Project Haystack are commonly used here as metamodels. Use of semantic data models is important to provide context for the data being shared and should include naming conventions, tags, hierarchy and relationship. 

It is important to note that a system may require multiple integrations to the various systems with which it integrates.  

Taking the case study of space use, WSP implemented an approach for the office to generate data from the lighting control system. Referring to the functional diagram in Figure 5, the lighting control system needed to integrate with two systems — the analytics platform and the room booking system. The WSP team determined that different integrations would be required for these two systems, as the analytics platform would be located on premises and the room management system platform would be in the cloud. As a result, a BACnet/IP protocol was integrated with the analytics platform. The room management system, however, uses the lighting control system manufacturer’s cloud platform to connect via RESTful API to the room management system. 

How to work with the data  

A smart building has the potential to collect a much richer dataset about building operations than traditionally available. Additionally, combining data from multiple systems that have historically existed in silos brings opportunities to smart buildings that did not previously exist both in the types of analytics that can be implemented and in improving the confidence of decisions made from analytics. Finally, smart buildings enable real–time analytics that bring actionable information to users (such as quickly finding a focus room with nobody in it).  

As a result, the system integrations that smart buildings require to support desired use case outcomes can be both broader and deeper than contractors and building operators are familiar with deploying. To ensure smart buildings are prepared to deliver on their intended outcomes, careful consideration of the procurement of systems, installation and commissioning sequences and clearly defined scope of work for vendors, integrators and operators to eliminate scope gaps is required. 

Ultimately, the success of smart buildings depends on enabling decisions to be made based on the analysis of the data. It is critical that any smart building design includes a plan for how action will be taken based on the data and whether the actions need to be reactive, near real-time or predictive. This action is what will deliver the outcome.  

These decisions could be automated by enabling machine to machine interactions, such as precooling a conference room before a meeting. Alternately, they may require human review and action, such as deciding to hire another employee without leasing additional office space. Smart buildings likely will require change management for owners, and design teams should consider ways to provide a soft landing for stakeholders as they become familiar with operating systems, managing platforms and interpreting dashboards.  

As a workplace efficiency example, two solutions were deployed to measure and enact efficiency improvements in WSP’s Boulder office. First, a number of dashboards were created to interpret office use. Floorplan visualizations graphically indicating which spaces are used more frequently are helpful for management of business units where employees may be co-located at client facilities, frequently traveling or working from home. Also developed: A dashboard graph identifying space type use over the course of a typical workday. One of the takeaways from this dashboard is that while overall area weighted office use is 50% to 60% from 9 a.m. to 5 p.m., open offices are the most highly used space type at 70% to 80% during peak hours.  

There is some room for improvement, but we need to be careful about impacting experience if no desks are available for employees arriving later in the morning. Private offices are poorly used, at only 30% to 40%. This is an opportunity for improvement and we are exploring programs to turn private offices into focus areas or to share assignment of private offices for employees frequently out of the office. An additional dashboard was created to identify coincident use of private offices, providing an insight into when private office scarcity may become an operational issue. 

The most interesting result was conference space, which lags significantly in use at 30% to 40%. This was a surprising result, as the perception among staff is that meeting space is always full. A second solution was integrated to better manage conference space, by integrating occupancy data with the room management system. This integration provided the ability to automatically delete meeting reservations if attendees were a no-show and to automatically block out the calendar for rooms during impromptu meetings. Additionally, the large conference room was the worst performer and is now acting as a quiet room for staff that need to concentrate during periods when meetings are not required.

Copyright 2019 CFE Media LLC