Improving building operational performance with Cognizant 1Facility and AWS IoT TwinMaker

Post also written by Shardul Pradhan and Ramesh Yechangunja from Cognizant

Introduction

Recent market conditions have stressed the commercial building management market due to the increased cost of construction, reduced occupancy, and increased cost of labor to monitor and maintain buildings. This is fueling the need for smarter and safer buildings. According to research from a Research And Markets article, the global smart spaces market is estimated to grow from $8.5 billion in 2019 to $19.9 billion by 2024. Building occupants expect issues to be resolved quickly and without impacting their environment. To accomplish this, building owners must be able to identify, predict, and respond to issues in a timely and cost effective manner as ongoing operating costs represent a significant portion of a buildings total cost of ownership over a buildings lifetime. Monitoring the performance of buildings is critical as it will help building owners understand the state of their building and improve decision making.

In this post we explore how Cognizant’s 1Facility solution can leverage the new AWS IoT TwinMaker service to help improve the building monitoring experience by reducing the time to troubleshoot a building issue via 3D visualization and aggregating data from multiple sources in a connected building.

Facilities operations and maintenance

Managing a commercial building requires multiple objectives, with competing priority, to be satisfied simultaneously including:

• Ensuring health, safety, and comfort of the occupants
• Reducing energy usage
• Meeting environmental and other government regulations
• Lowering cost of monitoring, maintaining, and operating the building

To satisfy these objectives the building data must be measured and reviewed. Building data is typically collected by disparate systems and sensors and even if the data is migrated to the cloud, it will be in different storage locations and formats. Individual applications monitor each of these areas, but these applications focus on its data, its objective, and alarms related to its function. The facility manager is responsible for manually associating disparate information to determine the full understanding of the state of their building.

A single visualization interface that federates data from multiple sources and organizes it in a meaningful way will allow building staff to effectively monitor the status of the building. Without this, staff will spend their time switching between systems without perspective on the entire building. The facility manager may miss transitory issues if they occur for a short period of time, such as when another system is being reviewed, and they are not logged to a central system. Alternatively, the underlying cause of an anomaly or alarm can be missed because relevant data is stored in multiple systems that are not linked. The context of a particular textual alarm may be lost on an inexperienced building operator. An early anomaly that is ignored may lead to a much more serious issue. The issue may be associated with the incorrect subsystem and lead to unnecessary work orders. By focusing on a single consolidated view that curates the data and uses 3D models of the building to highlight the issue will help a building operator to more quickly identify and take the appropriate mitigation steps while also monitoring key performance indicators(KPI) related to building performance and energy usage.

Cognizant’s 1Facility solution addresses these business needs and is used by building owners and facility managers to enhance their level of awareness, intelligence, and remote management of buildings by connecting disparate storage mechanisms, sensors, and building monitoring applications into a single system.  The 1Facility solution reduces installation and operating costs by having pre-built modules to meet common facilities management use cases. AWS IoT TwinMaker enhances the capabilities of 1Facility via 3D visualization of the building helping to quickly locate building issues, even for less experienced operators, while also reducing the level of effort to build and maintain connections to the facility’s data.

Use case walkthrough: Remote alarm triaging

In this example, the facility manager focusses on a single building as opposed to the multiple buildings they manage. The application displays a 3D view of the building that an operator can virtually navigate through. A list of alarms for the entire building is shown and can be filtered to only show active alarms. Key parameters including occupancy of the building, energy utilization, as well as the environmental conditions such as ambient temperature and air quality are presented on the building level view – the dashboard can be customized based on specific requirements. By default, the application will present the most current data and aggregate measurements.

When an alarm occurs in any floor or zone of the building the dashboard surfaces the issue via a new entry on the list of alarms and highlights the floor in the building 3D model. The entry in the alarm list provides tabulated information including the alarm name, time of the alarm, the rule that was breached, and information about the location including zone and floor. Highlighting the alarm on the 3D model provides the facility manager spatial and contextual awareness, especially if multiple alarms are triggered.

Consider the alarm in this case is a low temperature alarm in zone A on floor 6. This could be an occupant comfort issue, a failed HVAC system, or possibly an energy management issue if a window was left open, especially because this zone contains a room that is part of the building’s exterior. The facility manager will want to track down the root cause of this alarm so the issue can be corrected and future issues mitigated. To accomplish this they will navigate to the floor dashboard by selecting the floor name in the list of alarms or from the floor navigator drop down.

In this floor dashboard the particular zones or objects of interest causing the alarm will be highlighted to draw the attention of the facility manager. The alarm list shows current and historical alarm records for this floor. KPI indicators and line graphs present information about the floor in aggregate in the default view. The facility manager can explore the zone in question or other areas of interest by clicking on the anchor points in the 3D model. The data presented in the KPI indicators and line graphs will change based on the selected anchor point.

In our example, the facility manager explores the temperatures and other measurements in adjacent zones and observes that the temperature of all adjacent zones is normal. As the dashboard displays all the relevant data for this floor the facility manager identifies that the HVAC system is working as expected. Consider that while the facility manager is exploring the data that the alarm resolves itself, and is indicated as such in the alarm table. The temperature in zone A was only slightly low and did not show any discontinuities, so the temperature sensor is likely operating as expected. The facility manager forms a hypothesis that there is either a window open letting in cold air or possibly the air delivery system circulating hot air in zone A is malfunctioning.

To explore historical data the facility manager adjusts the time window using the time/date control in the top right corner. All graphs and KPI indicators will show data for the selected time period. As the facility manager plots data over the past week, they notice that the temperature in zone A has been lower than intended, but had not been low enough to trigger an alarm. The facility manager also notices that the temperature rise profile after the HVAC air delivery system is enabled is showing a delay in temperature rise the past couple days which is not reflected in the other zones, and is continuing to worsen.

The facility manager determines the HVAC air delivery system is malfunctioning in zone A. According to the time series data and a visual comparison against the temperature rise in other zones the HVAC air delivery system is continuing to degrade, but now reached a point where the zone temperature drops low enough to trigger an alarm. The facility manager submits a work order with a high priority to get the HVAC air delivery system inspected and serviced by the maintenance staff before the occupants’ comfort is affected.

The facility manager was able to identify and triage the issue remotely before a failure or occupant complaint. Further, the maintenance staff will be prepared to inspect and service the HVAC air delivery system based on the information from the facility manager. The 3D visualization enabled the facility manager to recognize adjacent zones and examine those temperature measurements. Combining this with historical data of multiple systems and observing the trend change the facility manager accurately concluded that an HVAC air delivery system is faulty. This solution enabled the facility manager to triage the issue quickly, assign the appropriate severity maintenance ticket, and provide insight to the maintenance staff on the issue.

Technical implementation of 1Facility with AWS IoT TwinMaker

1Facility is a set of connectors, tools, and processes to extract data from building systems and sensors in an effort to improve building operations, energy efficiency, and occupant safety and comfort. The solution includes design patterns to connect to in-building data sources, transmit data to the cloud, calculate KPI’s, and identify issues in the building. A dashboard layer provides an interface to display and explore this data at the building, floor, zone, and equipment level.

1Facility is built using a number of storage mechanisms based on the type and application or system that generated the data. Data representing a single physical object is often stored across multiple storage mediums. Therefore, the user interface or application layer must make calls to multiple data sources to pull all history for a particular physical object.

AWS IoT TwinMaker extends the capabilities of 1Facility by providing new functionality and data access improvements. Specifically, the scene composer in AWS IoT TwinMaker is used to add 3D visualization to 1Facility. This allows the facility manager to visualize the alarm information on a 3D model of the building and more quickly recognize and resolve issues. The concept of entities and components provides a framework to link the physical building to an information model enabling unified access to data across multiple sources without the need to replicate it to a central source. In the following discussion we will walk you through how a version of 1Facility leverages AWS IoT TwinMaker to provide these enhanced capabilities.

In this solution example, sensor data and building systems are simulated in an AWS Lambda function. The simulated data is collected using AWS IoT SiteWise. Measurements including air quality, temperature, occupancy, and energy usage are simulated. This time series data is stored in AWS IoT SiteWise along with the building hierarchy and asset models. Threshold based alarms are configured on the asset models to detect when a measurement exceeds the specified value. AWS IoT SiteWise generates the alarm records and publishes them to AWS IoT Core via a property change notification. The alarm records ultimately reside in Amazon Timestream along with external alarm data.

1Facility uses AWS IoT TwinMaker to access data from multiple data sources that contain the state of a physical object. Physical objects in this case include buildings, floors, zones, or equipment such as vending machines or coffee makers. In AWS IoT TwinMaker real world systems such as buildings, floors, and sensors are represented as entities. Hierarchies comprised of entities are established which correspond to the physical relationship. Components are attached to the entity to define the data that is associated with the object including measurements, alarms, and the details describing the alarm. All stored data for a physical object is made available via the entity, but remains in the original storage location.

The time series data stored in AWS IoT SiteWise is accessed through the built-in AWS IoT SiteWise connector which is used by default with the AWS IoT SiteWise component type. The AWS IoT SiteWise connector extracts data from AWS IoT SiteWise and exposes it via AWS IoT TwinMaker APIs such as get-property-value. This means that for AWS IoT SiteWise time series data a custom connector is not required. To reduce the configuration effort the AWS IoT SiteWise component type automatically configures the available properties by pulling in all the attributes, measurements, transforms, and metrics for the specified AWS IoT SiteWise asset.

A custom component is defined to represent the alarm data that is stored in Amazon Timestream. The custom alarm component extends the built-in basic alarm component. Additional data fields such as alarm type, time, status, condition causing rule violation, and additional metadata are defined. A Lambda function accesses records from Amazon Timestream and returns these to AWS IoT TwinMaker in the required Unified Data Query format. The component definition specifies a particular Lambda function. This Lambda function executes when a query requests data for a property defined on the component.

For this solution example the visualization layer is built using Grafana hosted in an Amazon Elastic Compute Cloud (Amazon EC2) instance. Amazon Simple Storage Service (Amazon S3) stores the 3D models of the floors, zones, and assets used to build the scene. Grafana interfaces with AWS IoT TwinMaker via a plugin to access the data as opposed to interfacing with the individual data sources. This enables the application developer to focus on creating meaningful visualizations rather than determining where and how to access data.

A differentiating feature for 1Facility enabled by AWS IoT TwinMaker is the 3D display of the building and floors to help the facility manager identify, locate, and triage issues. Using the Scene Composer feature in AWS IoT TwinMaker a scene is created for each floor and also for the overall building. As a first step, you upload the 3D models that represent the zones and other equipment. To create a scene for the floor you add one or more 3D models from the Resource library and then assemble the models to represent the floor by specifying the coordinates and rotation of each model. This is repeated for each floor as well as the building scene.

The facility manager uses visual indicators on the 3D model to quickly identify and gain context about issues. The icon used to represent an anchor point or color of a 3D model can be adjusted via rules and rule maps configured in the scene composer. The component property tied to the anchor point or 3D model can control the appearance of the object.

Each dashboard representing a particular building or floor will present a 3D model and data relevant to that floor or building, and the corresponding list of alarm history. The widgets on the dashboard will pull in properties such as air quality parameters, energy utilization, and aggregated occupancy by using the Get Property Value History by Entity API in Grafana. This API will retrieve the data from where it resides whether it be AWS IoT SiteWise, Amazon S3, Timestream, or other services based on the configuration of the component and Lambda function specified to retrieve the data. In this case, selecting the entity, component, and desired properties causes the Lambda function to retrieve particular time-series properties from AWS IoT SiteWise based on the specified assetID and modelID. This enables the KPI widgets and line chart widgets to be populated when a particular anchor point is selected.

Displaying the list of alarms by floor or by building requires a separate component type to be created for each physical object. The AWS IoT SiteWise assetID represents the physical object that generated the data. The specific AWS IoT SiteWise assetID is defined in each component type and is the filter key in the Amazon Timestream table. The component type, representing the building or a specific floor, is included when calling the Get Property History by Component Type API to return data for a specific floor or building. To return this data, AWS IoT TwinMaker executes the same custom Lambda function, but the internal logic will only return data from Amazon Timestream to AWS IoT TwinMaker where the particular assetID is present. This data is then displayed on the list of alarms in the context of the dashboard which is being observed.

Conclusion

In this blog post we outlined a solution using the new AWS IoT TwinMaker service to connect data from disparate sources and create a single view of all aspects of the facility with a 3D representation of a building. A facility manager utilizing this solution will understand the data in a more meaningful and accessible manner because the building 3D model visualizes the areas of interest. The root cause and mitigation steps of an alarm can be identified by examining all pertinent data for the entire facility. Providing a service to simplify and streamline data integration from disparate sources and visualizing the physical world in 3D enables solution providers like Cognizant to focus on how the data is used and implement meaningful analytics.

For more information on the Cognizant 1Facility solution, check out the solution in the AWS solution portal. To get started using AWS IoT TwinMaker, log into the AWS IoT TwinMaker console where you can create a digital twin of your own space.

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.
	Raj Devnath is a Senior Product Manager at AWS working on AWS IoT TwinMaker. He is passionate about IoT and AI and helping customers extract value from their IoT data. His background is in delivering solutions for industrial and consumer end markets such as Smart buildings, home automation, data communication systems, etc.
	Shardul Pradhan is an IoT Solution Architect at Cognizant Technology Solutions. He has over 15 years of experience and worked extensively in designing and building highly scalable IoT solutions for the manufacturing and commercial domain using cloud services. He has also designed and deployed a post Covid-19 return to office solution recently and is currently working on Smart Facility solution accelerators.
	Ramesh Yechangunja is an Innovation leader at Cognizant Technology Solutions, driving business outcomes through technology with over 19 years of experience in niche startups and global technology organizations. He is currently working as a Director of the IoT Centre of Excellence at Cognizant Technology Solutions leading the strategy and development of a robust and innovative Internet of Things ecosystem. This includes defining platform requirements, customer experience, and market strategies. He is spearheading IoT solutions spanning Smart Buildings, Industrial IoT, and the Internet of Medical Things.