Reduce building maintenance costs with AWS IoT TwinMaker Knowledge Graph

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 optimise their expenses by reducing maintenance costs while still providing a tenant experience, says Nick White, senior partner solutions architect, Jameson Bass, partner solutions architect, Julie Zhao, senior product manager at AWS and Stephen Plechy, chief architect of technology at Cognizant.

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, economisers, 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 visualise 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 contextualise 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. Analysing 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, economiser 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 economiser command is changed. This indicates that the economiser 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 economiser started to malfunction. Now the building manager will be familiar with the details of the economiser 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 economiser 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 economiser 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 visualise 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 realises 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 economiser position, the building manager was able to identify the failed economiser 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 economiser. 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 economiser 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 recognise that the economiser 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 visualisation.

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.

The authors are Nick White, senior partner solutions architect, Jameson Bass, partner solutions architect, Julie Zhao, senior product manager at AWS and Stephen Plechy, chief architect of technology at Cognizant.

Stephen Plechy
Nick White
Jameson Bass
Julie Zhao

Comment on this article below or via Twitter: @IoTNow_OR @jcIoTnow

RECENT ARTICLES

Ericsson, Thales launches IoT accelerator device connect with eSIMs for enterprises

Posted on: December 2, 2022

Ericsson’s Internet of Things (IoT) business, in partnership with Thales, launches IoT Accelerator Device Connect, a service offering generic eSIMs unbundled from pre-selected Service Providers. For the first time, enterprises have the flexibility to select one or more Service Providers easily and instantly at the time of device activation. This new business model dramatically accelerates

Read more

Airtel Business wins IoT solution mandate for Smart Meters from TPWODL

Posted on: December 2, 2022

Burla, Odisha, 29 November 2022 – Bharti Airtel (Airtel), India’s communications solutions provider has announced that it has won a cellular IoT solution mandate with TP Western Odisha Distribution Limited, (TPWODL), a Joint venture between Government of Odisha and Tata Power. The mandate will see Airtel power 200,000 Smart Meters with IoT solution, of which 70,000

Read more
FEATURED IoT STORIES

The IoT Adoption Boom – Everything You Need to Know

Posted on: September 28, 2022

In an age when we seem to go through technology boom after technology boom, it’s hard to imagine one sticking out. However, IoT adoption, or the Internet of Things adoption, is leading the charge to dominate the next decade’s discussion around business IT. Below, we’ll discuss the current boom, what’s driving it, where it’s going,

Read more

9 IoT applications that will change everything

Posted on: September 1, 2021

Whether you are a future-minded CEO, tech-driven CEO or IT leader, you’ve come across the term IoT before. It’s often used alongside superlatives regarding how it will revolutionize the way you work, play, and live. But is it just another buzzword, or is it the as-promised technological holy grail? The truth is that Internet of

Read more

Which IoT Platform 2021? IoT Now Enterprise Buyers’ Guide

Posted on: August 30, 2021

There are several different parts in a complete IoT solution, all of which must work together to get the result needed, write IoT Now Enterprise Buyers’ Guide – Which IoT Platform 2021? authors Robin Duke-Woolley, the CEO and Bill Ingle, a senior analyst, at Beecham Research. Figure 1 shows these parts and, although not all

Read more

CAT-M1 vs NB-IoT – examining the real differences

Posted on: June 21, 2021

As industry players look to provide the next generation of IoT connectivity, two different standards have emerged under release 13 of 3GPP – CAT-M1 and NB-IoT.

Read more

IoT and home automation: What does the future hold?

Posted on: June 10, 2020

Once a dream, home automation using iot is slowly but steadily becoming a part of daily lives around the world. In fact, it is believed that the global market for smart home automation will reach $40 billion by 2020.

Read more

5 challenges still facing the Internet of Things

Posted on: June 3, 2020

The Internet of Things (IoT) has quickly become a huge part of how people live, communicate and do business. All around the world, web-enabled devices are turning our world into a more switched-on place to live.

Read more

What is IoT?

Posted on: July 7, 2019

What is IoT Data as a new oil IoT connectivity What is IoT video So what’s IoT? The phrase ‘Internet of Things’ (IoT) is officially everywhere. It constantly shows up in my Google news feed, the weekend tech supplements are waxing lyrical about it and the volume of marketing emails I receive advertising ‘smart, connected

Read more