利用 AWS IoT TwinMaker 知识图谱降低建筑维护成本

关键要点

引言

随着工作模式从传统办公室转向混合和完全远程办公，商业建筑所有者面临收入和估值压力。因此，建筑管理者正在寻找优化开支的方法，以降低维护成本，同时为租户提供优质体验。

建筑管理者负责维护和为租户提供舒适的空间，同时需要平衡这两者的成本。往往情况下，他们需要管理多个物业，而维护人员可能不在所有建筑中工作，或对需要服务的建筑不熟悉。因此，拥有正确的工具进行故障排除和查找根本原因可以提高维护效率。

建筑维护通常是反应式的，主要由租户报告的问题或警报驱动。根据HVAC 维护与节能报告，非反应式的 HVAC 系统维护可以将运营成本降低10 20。虽然定期安排服务比较简单，但要检测传感器、经济调节器或长久遗忘的覆盖设置所需的数据驱动解决方案。主动的建筑管理者能够在问题发生之前识别出问题，这需要有效的方法来查找建筑并识别相似条件或故障模式下的设备。

在本篇博客中，我们将扩展关于我们先前帖子中提到的Cog知晓的 1Facility 解决方案，并演示知识图谱这一 AWS IoT TwinMaker 中的新功能如何使问题的查找和解决变得更加简单。在先前的文章中，Cognizant 描述了 AWS IoT TwinMaker 如何帮助他们为客户可视化建筑，并通过在一个位置融合多个数据源来增加价值。我们假设建筑管理者了解建筑、房间和设备，以及每个房间的位置和可用传感器。在本文中，我们将探讨在建筑中故障排除 HVAC 问题的使用案例，描述客户如何利用知识图谱来将警报进行情境化，并展示它如何帮助建筑管理者生成洞察。

使用案例分析：故障排除不适的租户环境

在这个例子中，建筑管理者将专注于管理的其中一栋建筑。一位租户报告称 11E 房间的环境不舒适，特别指出房间内潮湿闷热。

通过这个建筑的数字双胞胎，建筑管理者了解到这是一栋五层楼的建筑，每层有两个 HVAC 区域，分别朝东和朝西。接着，建筑管理者查看显示所有房间温度的仪表板，确认 11E 房间的温度高于设定值。分析该房间的湿度传感器数据后，建筑管理者证明了此房间也确实潮湿。

建筑管理者对这栋建筑不熟悉，困惑于为什么只有一个房间的温度和湿度偏高。为了进一步调查，建筑管理者使用数字双胞胎仪表板查看东 HVAC 区域的房间。通过检查这些房间的传感器数据，他们发现东 HVAC 区域中的其他房间温度均低于设定值，湿度也低于预期。通过检查建筑的 3D 模型，建筑管理者发现 11E 房间与其他房间的不同之处在于它没有窗户。他们随后访问了该 HVAC 区域附近的房间，验证了这个假设。同时还发现其他房间的住户打开了窗户以使房间保持舒适。外界空气将这些房间的温度和湿度降低到设定值如下，但并不足以触发建筑监控系统的警报。

上面这张 3D 可视化图展示了有窗房与无窗房，提供了建筑管理者形成假设的背景信息。

现在，可以清晰地看出东 HVAC 区域内存在不正常的情况。为了找到问题的根本原因，建筑管理者使用数字双胞胎仪表板检查东 HVAC 区域的传感器值。他选择了一种视图，显示东 HVAC 区域的所有传感器数据。他检查了来自传感器时序数据的测量值，比如一楼的回风温度、二楼的回风温度、供气温度、外界空气温度和湿度，以及其他控制值，如期望的风扇速度、经济调节器位置和每层楼的阻风门位置。通过访问所有这些数据点，建筑管理者可以比较趋势并识别异常行为。然后发现当经济调节器指令变化时供气温度并没有变化。这表明经济调节器出现故障，外界空气没有与回风空气混合后再被送入建筑。

接下来，建筑管理者查看历史数据，以确定经济调节器何时开始故障。这样，建筑管理者在提交供暖通风和空调公司维修服务单之前，能够熟悉经济调节器故障的详细信息。这些洞察减少了故障诊断所需的时间，加快了解决问题的速度。作为后续步骤，该管理者主动检查了这栋建筑及其他建筑中经济调节器的状态。这些行动不仅可以减轻潜在的租户舒适度问题，还可以帮助降低 HVAC 系统的运营成本，尤其是当其他经济调节器故障被识别并主动维修时。这就是主动维护的价值所在。

使用知识图谱的技术实现

知识图谱是 AWS IoT TwinMaker 的一项新功能。现有的 AWS IoT TwinMaker 客户可以通过在 AWS 控制台的设置页面选择标准定价计划来启用该功能。所有新客户默认启用知识图谱。通过该功能，用户可以使用开源的 PartiQL 查询语言执行查询，语法类似 SQL。客户使用关系属性来描述实体如何在物理上或逻辑上相互关联。然后可以查询他们的实体和这些实体之间的关系。例如，客户可以查询所有名称中含有“温度”的实体，或者找到与感兴趣的实体相连接的所有实体。这些功能使客户能够构建仪表板，以查看同一地点上相同类型设备的性能趋势，或通过遍历与问题相关的所有实体查找问题的根本原因。

在这一部分，我们将介绍如何使用知识图谱实现根本原因分析的使用案例。

应用程序开发人员创建实体以表示物理对象，例如房间或空气处理单元，然后添加从 组件类型 实例化的组件。组件包含描述物理对象的属性。比如某个属性可以是楼层号，或以时序数据流形式存储在外部数据存储中的温度测量值。关系属性捕捉该实体与另一个实体在组件上下文中的关系。一个组件可以包含多个关系，或者没有关系，而每个关系可以连接到一个或多个实体。要定义关系属性，必须指定关系类型及与该关系相关的实体 ID。

要创建实体、组件和属性，您可以使用AWS IoT TwinMaker 控制台或调用CreateEntity API。您还能使用描述建筑布局及其物理对象之间关系的入驻脚本或云形成模板。下图演示了一个表示房间的实体，以及与其关联的用户定义组件；描述属性关系的 JSON 对象也叠加在该图上。在这个用户定义的组件中，三个属性定义了关系：“feed”、“isLocationOf”和“isMonitoredBy”，另外两个属性“roomNumber”和“roomFunction”则定义了属性。

我们假设应用开发者已经创建代表建筑的组件、实体和关系。下图显示了知识图谱查询编辑器表示的建筑，及 HVAC 区域如何服务于建筑。

下方的图片展示了东侧 HVAC 区域的知识图谱更详细的视图。

此外，应用开发者已经通过场景作曲器上传和配置相关的建筑 3D 模型，并且最终用户可以通过Amazon Managed Grafana访问仪表板。有关如何导入 3D 模型并在 Amazon Managed Grafana 中进行可视化的分步说明，请参见此超链接博客。

有了在 AWS IoT TwinMaker 创建的建筑数字双胞胎后，让我们深入了解知识图谱如何帮助建筑管理者解决环境条件问题。在用例的第一部分，建筑管理者希望查看东 HVAC 区域房间的所有相关传感器数据。用户调用GetPropertyHistory API 以获取传感器数据，输入参数为实体 ID 及组件名称。第一步是识别建筑管理者感兴趣的所有相关实体。

在知识图谱推出之前，用户必须对来自ListEntities API 的各实体应用商业逻辑，以确定实体是否为东 HVAC 区域房间的传感器。用户需要处理多页结果，解析关系数据，并通过许多递归 API 调用遍历关系。借助知识图谱，用户可以构建如下查询。该查询返回与东 HVAC 回路房间相关的所有传感器的实体 ID。下面的查询可以通过ExecuteQuery API或在 AWS 控制台中的查询编辑器执行。

sqlSELECT e3entityId FROM EntityGraph MATCH (e1)[]gt{15}(e2)[isMonitoredBy]gt(e3) WHERE e1entityName = AHUEast AND e2entityName LIKE Room AND e3entityName LIKE Sensor

在上述查询中，PartiQL 语言允许用户指定变量跳跃查询和多跳查询。具体地，MATCH (e1)[]gt{15}(e2)是一个变量跳跃查询，能够识别与东侧空气处理单元之间 1 至 5 的所有实体。多跳查询(e2)[isMonitoredBy]gt(e3)使我们能够明确指定与房间直接单跳相关的以“sensor”结尾的实体。注意，isMonitoredBy进一步限制了结果，只允许具有该特定关系的实体返回。这个用例返回的是与东 HVAC 回路的房间相连的所有传感器，而不是东 HVAC 回路上的所有传感器。

然后，应用逻辑迭代传感器 ID 列表，并调用 GetPropertyValue API 以检索最新的传感器值。这些结果以单点时间数据的形式呈现给用户，如上图所示。现在，建筑管理者意识到所有房间的湿度和温度略微偏离设定值。

这种识别东 HVAC 区域房间传感器的繁重任务由知识图谱处理，而不是复杂的商业逻辑。这降低了应用程序开发的复杂性，使应用程序开发者能够专注于改善功能。例如，通过比较供气温度与经济调节器位置的时序数据，建筑管理者能够识别导致故障的经济调节器作为根本原因。

在这个用例中，建筑管理者决定主动检查其管理的其他建筑，看看是否有更多 HVAC 空气处理单元出现经济调节器故障。他将使用其他建筑的数字双胞胎进行相同的步骤。使用类似的查询检索实体 ID，然后使用GetPropertyValueHistory API 检索一段时间内的数据。接着，他创建并检查供气和经济调节器位置的图表。

结论

在本博客中，我们概述了利用知识图谱帮助建筑管理者故障排除租户舒适度问题的用例。建筑管理者能够查看建筑中存在的不同数据源，并根据知识图谱捕捉的物理关系深入到相关的房间和传感器。这使得建筑管理者能够准确地定位 HVAC 系统区域内的问题。接着，他们利用建筑数字双胎仪表板的 3D 场景形成有关根本原因的假设。通过深入研究在 AWS IoT TwinMaker 中建模的物理关系，建筑管理者确定了特定 HVAC 区域内的所有传感器。通过比较这些传感器的时序数据，他们能够认出屋顶空气处理单元上的经济调节器出现故障。结果，建筑管理者节省了时间，并能够为客户提供更好的问题解决体验。借助知识图谱，建筑管理者能够快速找出问题的根本原因，同时也可以主动查找其他建筑中类似的问题。这一故障排除体验得益于 AWS IoT TwinMaker 中的各项功能，包括知识图谱、统一数据查询和 3D 可视化。

欲了解有关 Cognizant 1Facility 解决方案及知识图谱如何帮助解决客户问题的更多信息，请访问其解决方案于 AWS 解决方案门户中。要了解有关知识图谱的更多信息，请查看这篇使用 PartiQL 和 AWS IoT TwinMaker 的文档，并开始使用AWS IoT TwinMaker 控制台创建自己的工作区。

关于作者

Nick White 是 AWS 的高级合作伙伴解决方案架