一、研究背景与问题定义1.1 背景数据驱动的建筑分析如负荷预测、故障检测、系统控制在建筑能源管理中日益重要。为了提高建筑分析应用在不同建筑间的可移植性业界已开发统一的数据模型如Brick通过本体Ontology的方式标准化建筑实体及其关系使数据访问方式统一化。1.2 核心问题现有数据模型Brick、BuildingSync、Project Haystack 等仅覆盖建筑内部系统数据如 HVAC。许多建筑分析应用还需要外部数据如气象、光照、太阳辐射等这些数据来自外部数据源如气象台、传感器网络并采用不同的数据模型和存储方式如关系数据库。缺少一种统一的机制使得建筑分析应用能够同时、便捷地访问建筑内部数据和这些“外围数据”导致开发工作重复、可移植性差。二、核心概念与术语建筑外围数据Building Periphery Data指不直接来自建筑内部系统如 BAS但对建筑分析模型训练或推理有贡献的外部数据。示例室外温湿度、太阳辐射、降雨量、紫外线强度等。这些数据通常来自外部数据平台采用关系型或其他非 RDF 数据模型。Brick 扩展本体Brick-extended Ontology在原有 Brick 本体的基础上融入建筑外围数据的语义描述形成一个统一的本体。本质仍是 Brick 本体但扩展了对外部数据的表达能力。三、主要贡献3.1 提出了建筑外围数据的建模方法定义了建筑外围数据的概念及其在本体中的表示方式。给出了如何将外围数据源如 RDB 模式转换为 RDF 本体并与 Brick 本体集成的方法。3.2 开发了 Cement-α 系统一个基于本体的多数据源数据访问系统结构如下1建筑外围数据辅助的本体生成模块BPOG输入Brick 本体 外部数据源模式如关系数据库模式处理将外部数据模式转换为本体表示Building Periphery Ontology Generation与 Brick 本体集成Building Ontology Integration输出Brick 扩展本体2本体辅助的数据提取模块ODE输入用户使用EnergonQL查询语言表达的数据需求处理基于 Brick 扩展本体进行本体遍历跨数据源时序数据库、关系数据库等提取所需数据输出统一格式的、满足分析需求的时序数据3.3 实验验证通过4 个真实的建筑分析应用进行定性和定量评估冷负荷预测CLF冷水机组性能分析CP建筑集成控制BIC能耗预测ECP四、评估结果指标结果代码行数减少相比传统“Brick RDB 分别提取”方式减少68.6% 81.0%开发时间减少相比传统方式减少49.3% 60.8%平均开发工作量综合四种应用平均减少57.2%原因分析代码量减少得益于Brick 扩展本体开发者可以用统一的方式表达所有数据需求无需为每种数据源编写独立的访问代码。时间减少开发者无需了解各数据源特有的数据模型和存储细节系统自动完成模式映射和数据提取。五、整体结论Cement-α 有效解决了建筑分析应用中多源异构数据访问的难题。通过扩展 Brick 本体并引入“建筑外围数据”的概念实现了建筑内部数据与外部数据的统一语义访问。显著降低了跨数据源的建筑分析开发复杂度极大提升了建筑分析应用的可移植性和开发效率。为未来智慧建筑中的数据集成与标准化提供了可行的技术路径。六、论文的定位与意义研究类型系统设计与验证型论文兼具方法论贡献和工程实现。应用场景智慧建筑、能源管理、数据驱动的建筑运维。技术栈本体工程RDF/OWL、数据集成、查询语言EnergonQL、时序数据处理。主要创新点首次系统性地将“外部数据”纳入建筑数据模型范畴提出并实现了从异构数据源到统一本体的自动化/半自动化映射流程验证了该方法在降低开发工作量方面的显著效果。这里是自己的论文阅读记录感兴趣的话可以参考一下如果需要阅读原文的话可以看这里如下所示摘要为提升数据驱动型建筑分析应用在不同建筑间的可移植性研究人员开发了数据模型以提供建筑数据的统一表示例如 Brick它定义了如何构建本体来捕获建筑实体的语义及其相互关系。然而现有数据模型均为建筑系统例如建筑的 HVAC 系统的数据而设计。但建筑分析可能还需要建筑系统外部的数据例如用于冷负荷预测的气象数据。此类外部数据可从外部来源如气象台获取但这些数据有其自身的数据模型和存储方式。为了实现面向建筑分析应用的、来自多数据源的可移植数据访问本文首先定义了建筑外围数据然后研究了开发一种数据模型的方法以支持既需要建筑数据又需要建筑外围数据的建筑分析应用。我们进一步开发了 Cement-α一个基于本体的数据访问系统用以提取建筑数据和建筑外围数据。我们通过四个真实的建筑分析应用对 Cement-α 进行了定性和定量评估发现使用多数据源的建筑分析应用的开发工作量平均减少了57.2%。CCS 概念信息系统 → 数据访问方法。关键词智慧建筑数据分析机器学习数据访问ACM 参考文献格式Fang He, Xiaoyang Zhang, and Dan Wang. 2022. Cement-α一种面向多数据源建筑分析应用的基于本体的数据访问系统. 收录于第十三届ACM国际未来能源系统会议 (e-Energy 22) 2022年6月28日-7月1日美国线上会议 2 页。 https://doi.org/10.1145/3538637.35388381 引言数据驱动的建筑分析如负荷预测、系统控制和故障检测利用机器学习ML模型来预测建筑组件的状态在建筑能源追踪、管理和效率提升方面正发挥着越来越重要的作用 [2, 6]。访问所需数据是建筑分析开发中非常初期的阶段该过程与具体建筑紧密耦合阻碍了建筑分析在不同建筑间的可移植性。为此研究人员开发了数据模型以提供建筑数据的统一表示。在数据模型标准化和促进数据访问方面已付出了巨大努力例如 Brick它基于资源描述框架RDF三元组 [3] 提供了一个统一的元数据模式来为建筑构建本体。Brick 本体描述了实体、资产及其相互关系使得基于 Brick 本体的建筑数据访问得以统一从而使建筑分析在不同建筑间具有可移植性。然而现有的数据模型如 Brick、BuildingSync 和 Project Haystack均为建筑组件例如建筑的 HVAC 系统的数据而设计 [1, 3]。但是建筑分析可能需要建筑组件外部的数据。例如冷负荷预测需要来自冷水机组的监测数据包括水温、流量以及目标建筑周围的气象读数如室外温度。此类外部气象数据可从外部来源如气象台获取但这些数据有其自身的数据模型和存储方式。由于建筑分析所需数据与实际可访问方式之间存在差距这些外部数据源无法被现有的建筑数据模型直接访问。因此有必要扩展对这些“外部数据”的数据访问。我们称这些数据为建筑外围数据它们有助于建筑分析开发中的模型训练并描述与建筑相关的间接对象。建筑外围数据通常可以从建筑自动化系统BASs以外的数据源例如基于关系数据模型的外部数据平台获取。在本文中我们首先研究通过扩展 Brick 模型来构建用于建筑分析中数据访问的数据模型的方法然后基于此数据模型开发一个数据访问系统。对于 Brick 扩展数据模型我们定义了 (1) 建筑外围数据(2) 如何构建建筑外围数据的本体以及 (3) 如何将建筑外围数据的本体与 Brick 本体集成形成 Brick 扩展本体。此外我们开发了 Cement-α一个基于本体的数据访问系统可以自动提取建筑数据和建筑外围数据。我们通过实施四个需要从多个数据源获取数据的真实建筑分析应用对 Cement-α 系统进行了定性和定量评估。2 CEMENT-α 系统支持诸如冷负荷预测等建筑分析应用的关键在于管理来自多个数据源的模式。其基本思想是广义上建筑分析应用的所有者仍然是建筑组件。因此在 Cement-α 中我们开发了一个建筑外围数据辅助的本体生成BPOG模块该模块可以接收建筑数据模型如 Brick以及其他数据源例如关系数据库模式。如图 1 所示。BPOG 模块将输出一个 Brick 扩展本体本质上它仍是一个 Brick 本体但我们在本文中使用“Brick 扩展本体”这一术语以区别于文献 [3] 中专门定义的 Brick 本体。Cement-α 的 BPOG 模块可以同时接收 Brick 本体和关系数据库模式并生成一个 Brick 扩展本体以辅助本体辅助数据提取ODE模块。在 ODE 模块中我们采用 EnergonQL 查询语言来表达建筑分析所需的数据。此外ODE 模块可以访问各种数据源并自动提取用户查询所定义的数据。图 1Cement-α 架构支持诸如冷负荷预测等建筑分析应用的关键在于管理来自多个数据源的模式。其基本思想是广义上建筑分析应用的所有者仍然是建筑组件。因此在 Cement-α 中我们开发了一个建筑外围数据辅助的本体生成BPOG模块该模块可以接收建筑数据模型如 Brick以及其他数据源例如关系数据库模式。如图 1 所示。BPOG 模块将输出一个 Brick 扩展本体本质上它仍是一个 Brick 本体但我们在本文中使用“Brick 扩展本体”这一术语以区别于文献 [3] 中专门定义的 Brick 本体。Cement-α 的 BPOG 模块可以同时接收 Brick 本体和关系数据库模式并生成一个 Brick 扩展本体以辅助本体辅助数据提取ODE模块。在 ODE 模块中我们采用 EnergonQL 查询语言来表达建筑分析所需的数据。此外ODE 模块可以访问各种数据源并自动提取用户查询所定义的数据。建筑外围数据辅助的本体生成BPOG 模块访问建筑外围数据源通过“建筑外围本体生成”子模块转换其数据模式并最终通过“建筑本体集成”子模块生成一个 Brick 扩展模式。本体辅助的数据提取ODE 模块通过“声明式查询处理器”接收用户查询然后对 Brick 扩展本体执行“建筑本体遍历”并访问跨数据源存储的时序数据以执行“时序数据提取”。3 评估我们开发了以下四个需要使用多数据源的建筑分析应用以比较使用 Cement-α 与使用多个独立数据提取过程时的开发工作量。冷负荷预测 (CLF)。该 CLF 分析应用使用来自 HVAC 系统的历史数据如冷水温度和流量以及外围数据如室外温度、湿度、降雨量和紫外线来预测目标建筑第二天的制冷需求。我们实现了文献 [4] 中典型的 CLF 模型。冷水机组性能分析 (CP)。该分析应用使用机器学习模型来预测冷水机组的实时性能系数COP。我们训练了表 1Cement-α 与传统两步法开发工作量的比较分析方法方法代码行数开发时间分钟CLFBrickRDB3597.6Cement-α11 (-68.6%)40.6 (-58.4%)CPBrickRDB5791.5Cement-α12 (-78.9%)36.3 (-60.3%)BICBrickRDB45114.2Cement-α12 (-73.3%)57.9 (-49.3%)ECPBrickRDB58117.8Cement-α11 (-81.0%)46.2 (-60.8%)文献 [7] 中描述的模型该模型需要来自冷水机组的机械数据和目标建筑的外围气象数据。建筑集成控制 (BIC)。BIC 联合控制多个系统以保持室内舒适度。我们实现了文献 [6] 中提到的 BIC通过系统的集成控制来维持区域的视觉舒适度。用于预测区域状态的机器学习模型需要来自系统的设定点数据和外围光照条件数据。能耗预测 (ECP)。ECP 使用模型来预测某组系统的能耗。该过程涉及影响太阳能电池板效率的外围数据如太阳辐射。我们实现了文献 [2] 中的特定分析应用。开发工作量针对上述四种类型的建筑分析应用我们通过比较使用 Cement-α 提取数据与分别提取 Brick 数据和外围数据时的代码行数和开发时间来评估开发工作量。对于 Brick数据可以通过 Mortar 平台一个基于 Brick 本体 [5] 提取数据的平台的方式访问。为了分析使用多数据源进行数据提取的工作量我们使用了基于关系数据库RDB的不同外围数据源来支持所需数据。表 1 展示了结果。我们注意到使用 Cement-α 的代码行数分别减少了68.6%、78.9%、73.3%和81.0%。这归功于生成的 Brick 扩展本体它允许开发者以统一的方式表达所需数据。所花费的时间分别减少了58.4%、60.3%、49.3%和60.8%。这是因为开发者无需了解不同数据源特有的数据模型即可访问数据。