一、研究背景与问题定义

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 个真实的建筑分析应用进行定性和定量评估：

  1. 冷负荷预测（CLF）

  2. 冷水机组性能分析（CP）

  3. 建筑集成控制（BIC）

  4. 能耗预测（ECP）

四、评估结果

原因分析

• 代码量减少：得益于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.3538838

1 引言

数据驱动的建筑分析，如负荷预测、系统控制和故障检测，利用机器学习（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 模块可以访问各种数据源，并自动提取用户查询所定义的数据。

图 1：Cement-α 架构

支持诸如冷负荷预测等建筑分析应用的关键在于管理来自多个数据源的模式。其基本思想是，广义上，建筑分析应用的所有者仍然是建筑组件。因此，在 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）。我们训练了

表 1：Cement-α 与传统两步法开发工作量的比较

文献 [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%。这是因为开发者无需了解不同数据源特有的数据模型即可访问数据。