在建筑的运营阶段，其系统在为居民提供舒适、健康和安全的室内环境方面发挥着关键作用[1]。随着对实时室内条件和延长占用时间的关注增加，能源消耗也随之增加[2]。因此，建筑系统的节能运行对于实现零碳建筑至关重要[3]。在此背景下，国际能源署（IEA）强调了建筑效率提升的未开发潜力[4]、[5]。数字化通过使能源系统更加智能化、互联、高效和具有弹性来增强其性能。根据IEA关于“数字化与能源”的报告[4]，整合建筑数字化及其相关技术可降低10%的建筑能源消耗。运营与建筑系统数字化之间的协同作用被认为具有巨大潜力。
最近，数字孪生技术已被设计用于建筑运营[6]、[7]、[8]、[9]。数字孪生包括一个物理资产、代表它的虚拟模型以及物理实体和虚拟实体之间的双向数据和信息交换[10]。从目标实体获取的数据被传输到虚拟模型，后者提供有关最佳运行的实时信息。利用这一概念的建筑运营展示了各种应用，如感知和监控[11]、[12]、分析[13]、故障检测和诊断（FDD）[14]、运营效率分析[15]、最优控制[16]和能源预测[17]。然而，考虑到建筑的工业特性和固有特性，存在一些限制。作为庞大的物理实体，建筑需要大量的实时数据，这在成本[18]和管理[19]方面带来了挑战。此外，在实验室环境中构建虚拟模型具有挑战性，因为设计实验模型的复杂性很高，而且每栋建筑都是独一无二的[7]。因此，在建筑的运营阶段，使用传感器进行可靠的数据收集对于虚拟模型的现场建模、管理和校准至关重要。在这一阶段有效应用数字孪生需要一个能够高效生成、处理和管理数据的信息丰富的传感器基础设施[20]。这对接能够生成、操作和管理数据的传感器基础设施提出了显著需求，因为传统传感器无法胜任这些复杂任务，因此需要使用传感器网络。传感器网络增强了实时监控、收集和传输数据的能力[21]，服务于异常检测、自动诊断和预测控制等应用，这些应用超出了基本的比例-积分-微分（PID）控制的范围。随着传感器数量的增加，数据收集和通信负载也随之增加，导致无线网络的成本和复杂性上升。在这种情况下，传感器管理和校准至关重要，因为物理传感器的不准确性可能对控制模型产生负面影响，从而降低建筑性能[22]、[23]、[24]、[25]。来自安装环境的系统错误无法通过传统校准方法得到充分解决[26]，由于系统老化[9]、[27]、设备或传感器更换[28]、运营模式变化[29]、虚拟传感器模型输入变量的传感器故障[30]以及电力和能源需求波动[31]等因素，需要持续的传感器管理。
在建筑环境中，虚拟传感器提供了一种灵活且经济高效的数字孪生替代方案，优于手动校准，提高了准确性和运营智能。虚拟传感器是一种数学模型，用于估计使用物理传感器难以直接实时测量的物理变量[32]。虽然它们是通过内置和现场建模方法开发的[20]，但根据功能的不同（如备份、观测、替换或虚拟化、验证和辅助[33]，它们有多种类型。在建筑运营领域，虚拟传感器与物理传感器和设施一起被视为有价值的资产，并在整个建筑生命周期中得到一致管理。这凸显了为建筑和基础设施运营中的虚拟传感器开发元数据模式的必要性。
建筑运营的元数据模式是一个数字框架，实现了智能建筑基础设施运营和数字孪生（DT）的概念[34]、[35]。通过建立这样的模式，就可以定义在行业中实施技术、管理建筑设施以及在整个建筑生命周期中协调数据和信息的流程。现有的建筑运营模式包括Green Button[36]、Project Haystack[37]、Brick模式[38]、Annex 66本体[39]等。Wu等人[40]提出了一个基于本体的框架，专注于使用Brick模式和建筑拓扑本体（BOT）进行建筑HVAC系统的能源模拟。为了支持带有元数据表示的建筑管理系统（BMS），已经开发了ICF和Project Haystack等著名模式[41]。建筑信息和区域能源分配网络模型主要是区域信息建模和管理用于能源减少（DIMMER）本体的目标，该本体用于基于本体的信息访问和可视化[42]。基于不同建筑运营的各种本体也存在，例如专注于建筑自动化系统的建筑自动化系统本体（BASont）[43]、专注于传感器和执行器的传感器网络（SSN）本体[44]、针对智能电器的智能应用参考（SAREF）[45]、用于能源使用分析、优化和存在分析的房地产核心（REC）[46]，以及其他一些本体，如与产品管理相关的产品本体（PRONTO）[47]和用于链接建筑系统内元素属性的属性本体（PROPS）[48]。在关注建筑和施工领域多个方面的模式中，Balaji等人[35]发现Brick模式能够高效表示HVAC系统，在实验建筑中覆盖了98%的BMS数据点。
如表1所示，只有少数几个本体，特别是Project Haystack、Brick模式、SSN/SOSA和SAREF，由于它们关注语义互操作性、传感器网络和全面的数据集成，因此显示出表示虚拟传感器的潜力。然而，这些潜在的本体都没有涵盖虚拟传感器元数据，导致缺乏虚拟传感器库、关系和属性。通过文献回顾，本研究确定了以下几个主要差距：
- •
Project Haystack：其灵活的标记（例如，equip、point、hisFunc）可以描述BAS，但缺乏正式结构，导致语义歧义，并限制了像计算传感器这样的虚拟数据流的表示[38]。
- •
SAREF：定义了saref:Device、saref:Sensor和saref:Measurement以支持IoT互操作性，但缺乏针对虚拟传感器的深入分类法和特定结构，排除了派生测量[49]。
- •
SSN/SOSA：使用sosa:Sensor、sosa:Observation和sosa:Procedure进行物理感知，但缺乏基于模拟或推理的虚拟传感器的机制，限制了BAS的应用[50]、[51]。
- •
Brick Schema：提供了严格的RDF/OWL分类法，包括brick:Point子类（Sensor、Setpoint、Command），用于BAS，实现了77%的点映射和100%的关系覆盖。然而，它缺乏使用物理或基于ML的模型的虚拟传感器实体、预测数据点、同步传感器决策或历史参数更新[38]、[52]。
基于问题框架和发现的差距，以下是三个明确的研究问题：
- 1.
如何扩展Brick以正式表示与物理传感器不同的虚拟传感器？
- 2.
描述虚拟传感器的建模和计算行为需要哪些语义属性？
- 3.
在Brick中表示虚拟传感器元数据是否可以提高AI代理的推理能力和系统的可解释性？
Brick模式提供了一个丰富的RDF/OWL类层次结构，具有明确的Sensor–Point–Measurement关系，使其可以通过子类化和语义属性继承来技术上扩展以定义虚拟传感器实体。因此，本研究的目的是使用Brick模式表达虚拟传感器的元数据。在这项研究中，通过包含一个虚拟传感器类来扩展Brick模式。理论上也可以通过引入一个单独的元数据模式来解决这个问题，类似于Brick如何结合形状约束语言（SHACL）；然而，这种方法将始终位于Brick核心结构之外。由于Brick已经提供了大量的物理传感器库（例如，brick:Point下的湿度传感器，用于测量湿度值而无需建模其底层行为），直接在模式中集成一个专用的虚拟传感器类填补了一个关键的语义空白，确保框架在表示传感器行为方面更加一致和详尽。这是首次将基于模型的虚拟传感器纳入Brick模式的研究。
本文的结构如下。第2节介绍了虚拟传感器和Brick模式的理论背景，概述了其现有特性和局限性，2.1–2.3小节详细介绍了各种类型的虚拟传感器、模式的关键组件以及表示虚拟传感器元数据的具体差距。第3节介绍了提出的本体扩展，定义了新的类、关系和属性以增强虚拟传感器的表示。第4节描述了系统框架和案例研究，包括HVAC设置、虚拟传感器配置以及扩展后的Brick模式的应用。第5节讨论了结果，分析了原始Brick模式和提出的Brick模式在表示虚拟传感器元数据方面的有效性。最后，第6节提供了结论，总结了研究的贡献、发现、局限性和未来方向。
