Reduce building maintenance costs with AWS IoT TwinMaker Knowledge Graph

Introduction

The shift from in office work to hybrid and fully remote work is causing revenue and valuation pressure on commercial building owners. As a result, building managers are exploring ways to optimize their expenses by reducing maintenance costs while still providing a premier tenant experience.

Building managers are responsible for maintenance and providing a comfortable space for tenants while balancing the cost of both. They often maintain multiple properties. The maintenance crew may not be physically present in all buildings, or familiar with the building that needs servicing. Therefore, having the right tools to troubleshoot and find the root cause can improve maintenance efficiency.

Building maintenance is typically reactive and driven by tenant reported issues or alarms. The HVAC Maintenance and Energy Savings report states that non-reactive maintenance on HVAC systems can reduce the operational cost by 10% – 20%. Scheduling regular service is simple, but detecting issues with sensors, economizers, or long-forgotten override settings requires a data-driven solution. Proactive building managers will identify issues before they arise, which involves having an effective method to search the buildings and identify equipment under similar conditions or failure modes.

In this blog, we will expand on the use case from our prior post on Cognizant’s 1Facility solution and demonstrate how TwinMaker Knowledge Graph, a new feature in AWS IoT TwinMaker, makes it easier to find and troubleshoot issues. In the prior post, Cognizant describes how AWS IoT TwinMaker enables them to visualize the building for customers and adds value by fusing multiple data sources in one location. We assumed that the building manager knew the building, rooms, and the equipment as well as the location and available sensors in each room. In this blog, we will walk through the use case of troubleshooting HVAC issues in a building. We will describe how customers use TwinMaker Knowledge Graph to contextualize the alarms, and demonstrate how it empowers building managers to generate insights.

Use case walk through: troubleshooting uncomfortable tenant conditions

In this example, the building manager will focus on only one of the buildings they manage. A tenant reported an uncomfortable environment in room 1.1E, specifically noting that the room was hot and humid.

From the digital twin of this building, the building manager learns it is a multi-story building with 2 HVAC zones per floor, aligned to East and West. Then, the building manager examines a dashboard displaying all room temperatures in the building, and confirms the temperature in room 1.1E is higher than the setpoint. Analyzing this room’s humidity sensor data, the building manager corroborates the report that the room is also humid.

The building manager isn’t familiar with this building and is puzzled as to why only a single room has high temperature and humidity. To investigate further, the building manager uses the digital twin dashboard to look at the rooms in the East HVAC zone, where room 1.1E is located. By inspecting the sensor data in those rooms in the East HVAC zone, they discover that all the other rooms in the East HVAC zone are cooler than the temperature set point and drier than expected. By examining the 3D model of the building, the building manager discovers room 1.1E is different from the others because it doesn’t have a window. They visit the nearby rooms in the East HVAC zone and validate the hypothesis. They also discover occupants in other rooms opened their windows to make the rooms comfortable. The exterior air lowered the temperature and humidity level of the rooms below the set point, but not enough to trigger an alarm in the building monitoring system.

Now, it is clear there is an issue in the eastern HVAC zone with the abnormal conditions in room 1.1E. To find the root cause of the issue, he used the digital twin dashboard to inspect sensor values for the east HVAC zone. The building manager selects a view to display all the sensor data for the east HVAC zone. He inspects measurements from sensors (time-series data), such as the floor 1 return air temperature, floor 2 return air temperature, supply air temperature, outside air temperature and humidity, as well as other controlled values such as the desired fan speeds, economizer position, and the damper position on each floor. With access to all of these data points, the building manager can compare trends and identify abnormal behavior. Then he discovers that supply air temperature doesn’t change when the economizer command is changed. This indicates that the economizer is malfunctioning, and the outside air is not being mixed with the return air before being recycled into the building.

Next, the building manager scans through the historical data to identify when the economizer started to malfunction. Now the building manager will be familiar with the details of the economizer issue before submitting a repair order to the HVAC company maintaining the system. These insights reduce the time to diagnose the problem and accelerate time to resolution. As a follow-up, he proactively checks the status of the economizer for the other HVAC units in this building and other buildings he manages. These actions not only mitigate a potential tenant comfort issue, but also help to reduce the operational cost of the HVAC system if other economizer issues are identified and proactively repaired. This is the value of proactive maintenance.

Technical implementation using TwinMaker Knowledge Graph

TwinMaker Knowledge Graph is a new feature for AWS IoT TwinMaker. Existing AWS IoT TwinMaker customers enable this feature by selecting the standard pricing plan on the settings page in the AWS console. All new customers will be on standard pricing plan by default and have TwinMaker Knowledge Graph enabled. With the feature, users execute queries using the open source PartiQL query language with SQL like syntax. Customers use the relationship property to describe how the entities are related to each other physically or logically. They can then query the entities in their workspace and the relationship between these entities. For example, customers can query all entities with a name containing “temperature,” or find all entities connected to an entity of interest. These capabilities enable customers to build dashboards to view performance trends for the same type of equipment in one site, or find the root cause of an issue by traversing through all entities related to the issue.

In this section, we will walk through the steps of how the root cause analysis use case is implemented using TwinMaker Knowledge Graph.

The application developer creates entities to represent physical things, such as a room or an air handling unit, and then adds a component that is instantiated from a component type. A component includes the attributes or properties that describe the physical thing. For example, a property can be a descriptor such as the floor number, or a time-series data stream like temperature measurement stored in an external data store. A relationship property captures how this entity is related to another entity in the context of the component. A component may contain multiple relationships or none, and each relationship can connect to one or multiple entities. To define a relationship property, a relationship type must be specified along with entity IDs that are referenced by that relationship.

To create entities, components, and properties, you can use the AWS IoT TwinMaker console or call the CreateEntity API. You can also use an onboarding script or cloud formation template that describes the layout of the building and the relationships between the physical objects. The figure below illustrates an entity representing a room with a user-defined component assigned to it; the JSON object describing the attributes’ relationships is overlaid onto the figure. In this user defined component, three properties define relationships, “feed,” “isLocationOf,” and “isMonitoredBy,” and two other properties, “roomNumber” and “roomFunction,” define the attributes.

We will assume that the application developer has created the components, entities, and relationships that represent the building. The figure below illustrates the TwinMaker Knowledge Graph query editor representation of the building and how the HVAC zones serve the building.

The image below shows a more detailed view of the TwinMaker Knowledge Graph for the East HVAC zone.

We will also assume the application developer has uploaded and configured a relevant 3D model of the building via scene composer, and that the dashboard is available to the end user using Amazon Managed Grafana. For step-by-step instructions on how to import a 3D model and visualize it in Amazon Managed Grafana, please see this hyperlinked blog.

With the digital twin of the building created in AWS IoT TwinMaker, let’s dive into how the TwinMaker Knowledge Graph helps the building manager to troubleshoot the environmental condition issue. For the first part of the use case, the building manager wants to view all relevant sensor data for rooms in the East HVAC zone. The user calls the GetPropertHistory API to get sensor data with entity IDs and component name as inputs. The first step is to identify all relevant entities that the building manager is interested in.

Prior to TwinMaker Knowledge Graph, the user had to apply business logic to each entity from the ListEntities API and determine whether the entity is a sensor in a room in the East HVAC zone. The user had to process multiple pages of results, parse the relationship data, and traverse the relationship with a number of recursive API calls. With TwinMaker Knowledge Graph, the user can construct a query as shown below. The query returns the entity IDs of all sensors related to rooms of the East HVAC loop. The query below can be executed via ExecuteQuery API or the query editor in AWS console.

SELECT e3.entityId
FROM EntityGraph
MATCH (e1)-[]->{1,5}(e2)-[:isMonitoredBy]->(e3)
WHERE e1.entityName = 'AHU_East' AND e2.entityName LIKE 'Room%'
AND e3.entityName LIKE '%_Sensor'

In the query above, the PartiQL language allows the user to specify a variable hop query and a multi-hop query. Specifically, MATCH (e1)-[]->{1,5}(e2) is a variable hop query which will identify all entities between 1 and 5 hops away from the East Air Handling Unit which start with the string “Room”. The multi-hop query, (e2)-[:isMonitoredBy]->(e3) enables us to specify that we are specifically interested in entities that end with the string sensor and have a direct (single hop) relationship with the rooms. Note that :isMonitoredBy further constrains the results by only allowing entities with that specific relationship to be returned. This use case is returning all sensors attached to a room in the East HVAC loop instead of all sensors on the East HVAC loop.

Then, the application logic iterates through the entity list (i.e. room sensors) IDs and calls the GetPropertyValue API to retrieve the latest sensor value. These results are presented back to the user as the single-point-in-time data on the dashboard, as shown in the image above. Now, the building manager realizes that the humidity and temperature in all rooms were deviating slightly from the setpoint.

This undifferentiated heavy lifting of identifying room sensors of the east HVAC zone is handled by TwinMaker Knowledge Graph rather than complex business logic. It reduces application development complexity and enables the application developer to focus on improving features. For example, by comparing the time-series data for supply air temperature and the economizer position, the building manager was able to identify the failed economizer as the root cause.

In this use case, the building manager decides to proactively explore other buildings they manage to determine if more HVAC Air Handling Units have a failing economizer. He will follow the same steps using the digital twin for other buildings. A similar query is used to retrieve the entity IDs, and then the GetPropertyValueHistory API is used to retrieve a range of data. Then, he creates and reviews the graphs of the supply air and economizer position.

Conclusion

In this blog, we outlined an TwinMaker Knowledge Graph use case for helping a building manager troubleshoot a tenant comfort problem. The building manager was able to view the disparate data sources present in the building, and drill down to the relevant rooms and sensors based on the physical relationships captured in the TwinMaker Knowledge Graph. This enables the building manager to pinpoint an issue within a zone of the HVAC system. Then, they use the 3D scene of the building digital twin dashboard to form a hypothesis on the root cause. By diving deep into the physical relationships modeled in AWS IoT TwinMaker, the building manager identifies all sensors in the specific HVAC zone. By comparing the time series data from these sensors, they are able to recognize that the economizer on the roof top air handling unit is malfunctioning. As a result, this saves the building manager time and enables them to provide a better customer experience of issue resolution. With TwinMaker Knowledge Graph, the building manager can root cause the issue quickly and also proactively look for similar issues in other buildings. This trouble shooting experience for the building manager was enabled through the various features in AWS IoT TwinMaker including TwinMaker Knowledge Graph, unified data query, and the 3D visualization.

For more information on the Cognizant 1Facility solution and how TwinMaker Knowledge Graph helps to solve customer problems, visit their solution in the AWS solution portal. To learn more about TwinMaker Knowledge Graph, check out this documentation on using PartiQL in AWS IoT TwinMaker and start building your own workspace using the AWS IoT TwinMaker console.

About the authors

	Nick White is a Senior Partner Solutions Architect at AWS focusing on IoT applications. He joined AWS from a globally diversified manufacturer where he led the IoT program for connected mobile equipment and industrial equipment. Nick has also developed systems and advanced controls for industrial machinery where he recognized the value of connected devices throughout the product lifecycle. Nick is passionate about IoT because of the efficiencies and insights that can be unlocked by bringing visibility of the physical world into the business decision making process.
	Jameson Bass is a Partner Solutions Architect at AWS supporting the RCGTH & MLEU (collectively ‘P&R’) industry verticals for Cognizant in North America. He came to AWS after working as an IT Consultant at multiple firms where he would work alongside clients performing cloud migrations and/or building custom data and analytics solutions.
	Julie Zhao is a Senior Product Manager on AWS Industrial IoT team working on AWS IoT TwinMaker. She joined AWS in 2021 and brings three years of startup experience leading products in Industrial IoT. Prior to startups, she spent over 10 years in networking with Cisco and Juniper across engineering and product. She is passionate about building products in Industrial IoT domain.
	Stephen Plechy is Chief Architect of Technology at Cognizant focusing on deploying Cognizant’s smart building initiative, creating scalable cloud-enabled architecture to measure and control clients’ energy usage. He is an expert in building automation systems and IoT programs for connected buildings. Stephen’s strengths include deploying smart building technologies for large, commercial buildings and dispersed retail locations. Stephen has almost two decades of experience in building automation and has been with Cognizant for three years.