面向既有建筑数字孪生的数据库驱动IFC框架

《AUTOMATION IN CONSTRUCTION》：Database-driven IFC framework for digital twins of existing structures

　　

•将IFC转换为结构化关系型数据库的流水线
•将检查数据和结构健康监测（SHM）数据关联起来的语义扩展策略
•用于组织与查询传感器数据的双模式数据建模策略
•超越文件交换的数字孪生运营IFC数据管理方法
•传感器规模与模型规模下关系型存储与RDF存储的性能比较

1. 引言

建筑信息建模（BIM）被广泛认为是整合多学科数据、增强设计、施工和运营阶段协调性的关键手段，并为智慧建造和设施管理提供了坚实基础[1]，[2]。BIM与传感技术及物联网（IoT）基础设施的融合加速了数字孪生（DT）的发展[3]，[4]，数字孪生能够动态映射物理资产的演变状态，从而支持结构健康监测（SHM）、基于检查的缺陷记录、结构性能分析和数据驱动的决策制定[5]，[6]。然而，上述技术目前依赖于分散且孤立的数据存储，这阻碍了数字孪生在多参与方项目中的应用。针对这一问题，Web技术凭借其强大的实时交互和跨平台互操作支持，为整合与可视化BIM、IoT及传感数据提供了天然平台。

在BIM工作流中，互操作性依赖于开放且标准化的数据规范。建筑工业基础类（IFC）是一项经ISO认证的开放标准[7]，提供对建成资产丰富的语义和几何描述，构成BIM内部信息交换的核心机制[8]。然而，尽管IFC具有很强的表示能力，其最初主要是作为面向交换的数据标准而设计的，旨在支持异构软件平台之间的互操作性[8]，[9]。buildingSMART已指出，这种基于文件的定位方式并不便于支持运营、维护和实时协作所需的结构化存储与快速访问[10]，[11]。因此，基于标准产品数据交换规范（STEP）的IFC模型[12]在面向SHM的数字孪生等新兴的以Web为中心的应用中展现出了固有的局限性。例如，访问模型的特定部分仍然需要解析整个IFC文件，这会带来巨大的计算开销[13]。任何客户端的修改都需要重新保存并重新分发整个文件，使得文件级的信息孤岛与现代协作工作流不相容[14]。现有的机制如IfcPropertyTableValue或IfcSensor不适合处理大规模、高频且持续生成的传感器数据流[15]。最后，尽管模型扩展和外部链接策略已被探讨[4]，但由于IFC本身缺乏时间语义[16]，[17]，其在时间表示和动态数据绑定方面存在局限。随着BIM在建筑全生命周期中的部署日益增加，设计、施工和运营阶段的集成管理已成为一个关键的研究课题[18]，[19]。当前IFC日益明显的结构局限限制了其在基于数字孪生的运维工作流中的更广泛应用，尤其是涉及SHM和自动化检查的工作流[20]，[21]。

为应对上述挑战，本研究旨在开发一个数据库驱动的IFC框架，能够连接结构几何的静态语义与高频动态监测数据，以促进高效查询、实时交互和面向数字孪生的应用。所提出框架的贡献体现在以下特性：
•一种数据库驱动的IFC数据统一转换、管理和检索方法，在保留原生IFC语义的同时，为全模型计数、属性检索和面向传感器的查询提供查询性能优势。
•一种面向SHM数据的数据库支撑双模式建模策略，以及一种面向检查数据的基于IFC的语义表示策略，在保留IFC空间语义的同时支持灵活的分析查询。
•一种基于IFC属性集（Pset）的IfcSensor语义扩展，建立了建筑构件与传感器观测之间可追溯且一致的关联。
•一种基于RESTful API的服务导向数据访问机制，为关系型IFC结构提供互操作且细粒度的访问，并支持对SHM和检查数据的分析查询。

本文结构如下。第2节回顾关于IFC数据管理以及IFC与SHM、IoT和检查数据整合的现有研究。第3节描述所提出的框架，包括IFC到数据库的映射、时间序列数据建模以及传感器和检查信息的表示。第4节提出用于访问IFC、SHM和检查数据的服务导向方法。第5节提供WebIFC+服务器和客户端的实现细节。第6节通过建筑SHM和桥梁检查案例、性能实验以及结果讨论对提出的框架进行评估。最后，第7节总结结论、局限性和未来工作方向。

2. 相关工作

本节回顾与IFC数据管理及其与基于BIM的数字孪生集成相关的现有研究，包括语义表示、替代序列化、在线访问以及SHM、IoT和检查数据的整合。

2.1 IFC规范

当前IFC遵循ISO 16739-1:2024标准，该标准正式定义了其结构和信息表示[7]。该标准基于更广泛的ISO 10303（STEP）系列标准，后者提供了跨行业产品数据表示和交换的统一框架[12]。在STEP中，EXPRESS语言用于定义模型中的实体、属性和约束[22]。IFC的主要交换格式是STEP物理文件（IFC-SPF），这是一种基于文本的实例格式，将数据编码为顺序且位置依赖的属性值，以确保跨平台的解析一致性[8]。然而，IFC与EXPRESS以及基于STEP的序列化紧密耦合的特性使其不适合现代的基于Web的环境[23]。在IFC5的战略路线图中，buildingSMART International明确指出这些结构局限性是IFC4固有的[10]。

针对这些约束，研究人员探索了多个方向以增强IFC的可用性。在语义网集成方面，Pauwels和Terkaj[24]开发了IFC Web本体语言（ifcOWL），将基于EXPRESS的IFC架构映射为OWL本体，允许IFC模型实例以RDF图的形式表示，通常以Turtle（TTL）格式序列化，并使用SPARQL查询。然而，通过ifcOWL表示IFC将基于EXPRESS的实体-属性结构重新诠释为RDF图，这使得后续更新同步回原生IFC模型仍然具有挑战性。Rasmussen等人[25]系统地提出了建筑拓扑本体（BOT），为表示空间结构、建筑构件及其拓扑关系提供了轻量的链接建筑数据词汇表。Hamdan等人[26]提出了损伤拓扑本体（DOT），支持对施工相关损伤、损伤拓扑及其与受影响构件或空间区域关系的语义表示。Li等人[27]开发了桥梁结构与健康监测（BSHM）本体，通过扩展现有传感器本体，为桥梁结构、监测系统、传感器和异构观测数据提供统一的语义表示。J?kel等人[28]提出了结构诊断本体（SODIA），在基于RDF的语义模型中集成了源自IFC的结构信息、损伤观测、传感器测量和诊断知识。BOT、DOT、BSHM和SODIA定义了独立于原生IFC数据模型的语义表示。虽然它们可以与IFC实体关联，但建立和维护这些关联需要额外的映射、工具集成和同步机制。

在基于本体的建模之外，Hagedorn等人[29]研究了信息容器链接文档交付（ICDD）的使用，以连接异构工程文档、BIM模型和链接资源用于基础设施资产管理。然而，作者指出，建立和维护大量现有数据、BIM模型及相关信息之间的关联仍然具有挑战性。最近，Kosse等人[30]开发了模块化语义数字孪生参考架构，通过将资产管理壳（AAS）、ICDD、链接数据和基于本体的语义层相结合，通过SPARQL和基于REST的服务将BIM衍生的语义数据与时间序列传感器数据集成。然而，他们也报告称基于链接数据的数字孪生实现仍然需要大量的本体建模和SPARQL专业知识，工具支持和自动化程度有限，并且增量更新和一致性维护仍然具有挑战性。

在替代序列化方面，Krijnen和Beetz[13]提出了使用分层数据格式第5版（HDF5）存储IFC模型，以利用分块存储和局部寻址来改善部分访问。然而，HDF5本质上仍是基于文件的，对增量和事务性数据修改的支持有限。Zhu等人[31]开发了IFC-Graph，将IFC数据转换为带属性的图结构，通过图查询语言实现拓扑和依赖查询。然而，他们也指出了图生成效率、几何信息处理和多模型管理方面的局限性，这些限制使其难以直接应用于持续更新的基于Web的数字孪生。还开发了Web友好的编码格式如ifcXML[32]和ifcJSON[33]，以改善与基于HTTP的交换和浏览器端处理的兼容性[23]。然而，尽管这些编码可以在Web环境中直接解析，但它们仍然是面向文档的结构，缺乏原生索引、事务控制和在运营数字孪生中对持续组件级查询和更新的高效支持。综上所述，这些方法改善了IFC数据的可访问性、表示和部分检索能力，但尚未完全满足运营型基于Web的数字孪生的数据管理需求。

其他研究还探索了增强基于IFC的协作和运营数据管理的方法。Isikdag[34]提出了BIM AJAX、BIM SOAP门面和RESTful BIM模式，通过服务和资源导向的Web架构暴露BIM和IFC数据。Beetz等人[35]开发了开源的IFC模型服务器BIMserver.org，可与BIMQL[36]配合使用以实现多用户在线访问和结构化模型视图管理。基于他们的工作，Das等人[37]推出了Social BIMCloud，这是一个分布式基于云的协作平台，用于协调模型视图、权限和版本控制。Werbrouck等人[38]提出了一种基于链接建筑数据和Solid生态系统构建的分布式通用数据环境，用于分布式BIM数据共享和细粒度访问控制。这些研究改善了IFC的在线访问和协作模型管理，但主要侧重于模型服务工作流，而非多源运营数据的组织和管理。

总体而言，现有研究改善了IFC数据的语义表示、替代序列化、在线访问和协作管理，但仍然没有完全解决运营数据管理的需求。

2.2 数字孪生中的互操作性

实时传感网络是建筑与基础设施系统数字孪生开发的关键组成部分。近年来，环境监测和SHM传感器的成本大幅下降[39]，[40]，随之而来的是部署规模的迅速增加[41]，[42]。越来越多的研究探索了实时数据流与BIM的集成，以支持SHM、预测性维护和资产管理[43]，[44]。BIM与数字孪生的融合被广泛认为是整合建筑全生命周期中异构来源信息的关键。将几何模型与检查数据和动态监测数据相结合，可以显著增强可持续性评估和智能设施管理[45]，[46]。在SHM领域，BIM与传感网络的耦合被认为是提高结构状态感知和支持监测数据集成与3D可视化的有效手段[21]，[47]。基于BIM的SHM框架也已应用于结构状态评估和早期预警[48]。BIM和数字孪生越来越多地被研究其在状态评估、缺陷记录和维护规划方面的适用性[49]。BIM与各种数据源之间的这些协作日益对传统的基于文件的数据交换工作流提出挑战[10]，而工程数据日益增长的规模和复杂性进一步加大了这一难度[14]，[50]。

为应对这些局限性，研究人员进行了广泛的尝试。在传感器数据表示方面，Kang等人[51]开发了一个BIM-IoT监测框架，采用MQTT协议和InfluxDB时间序列数据库来收集和存储环境数据，并使用BIM进行3D可视化和性能分析。其原型展示了通过BIM与时间序列数据库耦合实现动态数据集成的可行性。在IFC生态系统中，Hu等人[15]通过定义专门的属性集扩展了IfcSensor，并利用IfcPropertyTableValue将实时监测数据直接嵌入IFC文件中。然而，该方法受到基于文件的序列化的结构局限性的制约，无法支持高频追加、增量更新和并发访问。Chung和Shelden[52]引入了一种基于ifcJSON的数字孪生框架，将IFC-SPF格式转换为ifcJSON，使得BIM信息能够在链接数据环境中与IoT传感器数据和领域本体进行语义集成。

尽管该框架提升了网页解析效率和跨本体互操作性，但其将BIM主要用作静态语义锚点，并未为数字孪生（DTs）场景下的大规模时序建模或查询优化提供统一机制。在检测记录的表示方面，Hüthwohl等人[53], [54]使用IfcTask、IfcElementAssembly和IfcSurfaceFeature在IFC中表示桥梁检测缺陷，并通过属性集（Psets）和纹理映射来关联缺陷属性和图像。Sacks等人[55]进一步将该实体映射框架嵌入模型视图定义（MVD）工作流中，以提高交换一致性和模型验证能力。Isailovi?等人[56]将这一思路进一步延伸，将点云检测到的损伤以三角化几何体的形式写回IFC，并与桥梁构件进行关联。在我们先前的工作[57]中，该基于IFC的表示范式被适配应用于受损钢筋混凝土梁，裂缝信息与结构分析结果相关联。Artus[58]开发了一种面向对象的损伤信息模型（DIM），利用现有的IFC实体和关系实现了语义、几何和基于图像的损伤信息建模。Santos等人[59]则着重强调了桥梁管理系统（BMS）与IFC之间的互操作性，主要使用IfcBridgePart、IfcTask和自定义属性集来集成构件级别的检测数据。与这些以IFC为中心的方法互补，Hamdan等人[60]提出了一种基于本体的方法，将检测到的损伤及其上下文信息与BIM和结构模型关联，以支持基于规则的损伤评估。在系统集成与网页互操作性领域，研究者主要致力于开发实践应用中的接口级和跨平台集成策略。Chatsuwan等人[61]提出将异构物联网数据映射到IFC/JSON结构中以实现异构物联网数据的统一表示，从而减少接口异构性。Tang等人[62]开发了一种将IFC与BACnet集成的协作框架，以促进楼宇自动化系统与BIM之间的语义耦合以及解决运营数据孤岛问题。为实现实时交互和跨领域链接，Herlé和Blankenbach[63]引入了一种超媒体驱动的RESTful模式，使客户端能够在BIM、地理信息系统（GIS）和物联网领域之间进行语义导航，这是迈向原生网页数字孪生的一步。其他研究还探索了物联网平台、实时流处理和多传感器融合技术，以支持高频监测和事件触发分析[64], [65]。尽管这些研究在BIM、结构健康监测（SHM）、物联网和检测数据的集成方面取得了实质性进展，但大多数研究侧重于表示、语义链接或接口级互操作性。较少有研究关注如何将IFC派生的模型信息、检测记录和持续更新的SHM观测数据组织为面向网页数字孪生应用的操作数据层。具体而言，现有研究表明，基于本体和链接数据的方法在基于ifcOWL的建筑数据复杂查询构建和长期运行应用中的持续数据更新方面可能面临实际挑战[66], [67]。本研究开发的数据库驱动方法预计能够补充这些方法，通过提供可维护的操作数据层来支持构件级查询、增量更新和长期数字孪生数据管理。

下载：下载高分辨率图像（871KB）下载：下载完整尺寸图像

图1 所提框架的工作流程。

3. 所提框架

图1展示了所提的数据库驱动的IFC框架，该框架在IFC模型内系统地建模多源传感器信息，然后将其映射到关系数据库中。这为建筑全生命周期内的语义映射、数据协作、交互和实时可视化提供了统一的数据基础。所提框架包含三个紧密集成的核心组件：

(1) 一种IFC到数据库的转换方法，将富化的IFC模型转换为关系数据库以实现协作数据管理；

(2) 一种面向SHM数据的双模式数据建模策略和一种基于IFC的检测数据语义表示策略，二者均促进高效查询；

(3) 一种语义扩展策略，将BIM组件与SHM数据和检测数据关联，以支持语义映射、交互和实时可视化。

所有组件均在服务器端实现，并通过RESTful接口层暴露，以提供标准化的信息服务和交互访问。

在第一个组件中，增强的IfcOpenShell工作流将原生IFC模型重构为关系数据库，通过将建筑元素、空间层级、属性集和几何表示系统地映射到结构化表中，从而促进多利益相关方之间的高效查询和协作。第二个组件利用IoTDB的组织原则开发了一种基于路径的时序模型，按照"建筑→楼层→构件→传感器"的层级结构编码传感器观测值。该层级结构与IFC模型的组织结构在语义上保持一致，从而实现连贯的存储、索引和基于时间窗口的检索。第三个组件采用自定义属性集扩展IfcSensor、IfcTask和IfcSurfaceFeature等核心实体，在几何组件与传感器监测数据、检测任务和表面缺陷数据等生命周期数据之间建立可追溯的链接。这确保了关系数据库与时序数据库之间的统一表示和协调访问。

3.1 IFC到数据库转换方法

将IFC模型映射到关系数据库中需要保留其层级分解语义、实体间关系和可扩展的属性表示。关系数据库还应支持基本的创建、读取、更新和删除（CRUD）操作。为此，本研究基于IfcOpenShell[68]提供的功能开发了一种自动化的IFC到数据库转换方法（ITDA）。IfcOpenShell提供了解析IFC-SPF文件、访问IFC架构信息和遍历实体实例的基本功能。基于解析的IFC数据，使用本研究实现的IFC到数据库方法构建了关系数据库。该实现旨在支持面向数字孪生的IFC信息组织，使相关实体、属性、关系和属性信息能够被结构化处理，以支持后续的数据库查询、语义关联、可视化以及与传感器和检测数据的集成。

ITDA的转换工作流程如图2所示。首先，将IFC-SPF文件解析为内存中的IFC模型表示，其中实体实例、属性和实体间引用均可用。在数据库架构初始化后，根据IFC架构创建IFC实体表，并按类逐类插入实例。每个STEP行标识符被保留为ifc_id。值类型为IFC实体引用的属性存储被引用实例的ifc_id，而聚合属性（如值或实体引用的列表或集合）在必要时序列化为JSON。全局id_map表记录每个ifc_id与其IFC类之间的对应关系，使得在不同实体表之间插入后的引用可以被解析。在此设计中，STEP行标识符充当稳定的逻辑引用键，与id_map表一起用于解析不同IFC实体表之间的引用。因此，被引用实体无需在引用实体之前插入，转换过程也无需多次解析迭代来维持引用一致性。

下载：下载高分辨率图像（625KB）下载：下载完整尺寸图像

图2 IFC到数据库转换过程的流程。

基于这种引用键映射机制，IFC类标识和多态引用通过架构级实体表和引用键解析得以保留。每个实例存储在其实体的具体IFC实体类型表中，同时其类信息保留在id_map表中以及（用于查询导向的对象摘要的）辅助元素表中。对于多态或基于SELECT的引用，存储的ifc_id可通过id_map解析为实际目标类。在启用时，逆关系从解析的IFC实例图中提取并作为引用列表存储。

常用关系信息被进一步重组为查询导向的辅助表。具体而言，最初通过IfcRelDefinesByProperties、IfcPropertySet和相关属性实体表示的属性赋值信息被扁平化到Psets表中，其中每条记录将一个IFC实体与属性集名称、属性名称和属性值关联。类型定义信息被提取到relationships表中，IfcRelDefinesByType表示为对象实例与其对应类型对象之间的实例-类型链接。当特定应用场景需要时，该表可扩展到其他选定的IFC关系类型。最初通过IfcRelAssociatesMaterial和不同材料集结构表示的材料关联信息被重组到materials表中，以提供对材料名称、材料类别、材料层、轮廓或组分的直接访问。

ITDA将IFC实体扁平化为SQL表，并将生成的关系数据库组织为两层四类，如图3所示。核心数据层包含三类表：元数据、几何-材料和Psets-关系。这些表共同定义了标识符、几何、材料和属性数据的基础结构。语义数据层包含从IFC模型派生的所有实体表，确保其语义信息在关系数据库中得以保留。

下载：下载高分辨率图像（526KB）下载：下载完整尺寸图像

图3 IFC数据库架构。

在核心数据层中，元数据表包括id_map、metadata和elements表。id_map和metadata表记录标识符映射和配置信息，这对于溯源管理至关重要。elements表建立了跨实体关联，将IFC派生实体与其对应的几何、形状和材料表示链接起来。这种组织在不引入额外结构开销的情况下，在异构表之间维持了可追溯的连接。属性值由语义类型映射确定，并以适当的数据类型存储，而复杂聚合值则序列化为JSON格式以确保兼容性和可扩展性。可选的逆关系保留在relationships表中以实现双向查询。属性数据基于扁平化的四字段表示统一存储在整合的Psets表中，这显著提高了属性级查询性能并减少了与嵌套STEP结构相关的检索开销。

对于几何信息，采用并行化处理流程从可见元素中提取网格级数据。提取的数据包括顶点、边、面、材料索引和表面样式元数据，存储在geometry表中。同时，变换矩阵、局部坐标原点和几何到实体的映射维护在shape表中。材料定义单独存储在materials表中以维持与几何实体的显式链接。同时，原始的IFC原生几何定义（包括对象放置、产品表示、形状表示、表示项、轮廓及其他几何相关的IFC实体）保留在相应的实体表中以实现语义可追溯性。虽然几何提取增加了转换成本，但基于IFC的可视化在某个阶段需要网格生成。通过将提取的几何数据与ifc_id关联存储，几何数据可以与构件属性、材料、SHM关联和检测记录在统一数据层中一起检索。当不需要几何可视化时，可以省略网格级提取。几何提取引入的性能开销在第7节中进一步讨论。

下载：下载高分辨率图像（1MB）下载：下载完整尺寸图像

图4 与Pset相关的IFC实体映射到关系表的示例。

语义数据层由从IFC架构派生的实体-关系表组成。图4以Pset相关实体的一小部分为例说明了这种实体级映射。在完整架构模式下，ITDA为IFC4中定义的所有876个实体类创建关系表，从而保留对原始IFC模型的完整架构级覆盖。在实例驱动模式下，仅将输入IFC模型中实际实例化的实体类型映射到数据库表中，这更适合轻量级部署。虽然完整架构模式在架构初始化期间引入了额外开销，但由于常规构件级查询不遍历未使用的表，因此对查询性能影响有限。空表的存储开销也很小，因为它们主要贡献数据库元数据而非实例记录。显式几何提取引起的额外转换开销将在第7节中量化和讨论。

除了结构化重组之外，ITDA还支持灵活配置以满足不同应用的需求。用户可以根据具体项目需求调整导出参数，如启用或禁用几何提取、展开嵌套属性、保留逆关系或选择目标数据库类型。这种参数化设计增强了跨不同项目规模和应用领域的适应性和可重用性。例如，轻量级部署可能仅保留属性数据，而涉及可视化和空间分析的任务可采用完整的几何提取。因此，ITDA在语义、几何和属性级别实现了IFC模型的结构化重组，为所提框架中更广泛的语义映射和多源数据集成奠定了坚实基础。

3.2 时序数据建模策略

在数字孪生的背景下，数据表示必须支持高效查询、多尺度聚合、高频数据摄入和实时访问。

尽管IFC在表示构件语义、几何信息和空间层次方面提供了广泛的能力，但由于其仅提供有限的构造来记录时间信息，并且缺乏表示时间演化的原生机制，因此它本质上仍然是静态的。虽然它提供了多种可扩展机制，利用IfcPropertyDefinition层次结构（包括Pset、代理构件和IfcPropertyTableValue等结构），但这些机制主要设计用于辅助性、静态或更新频率较低的信息。它们不适用于管理大规模、高频且持续积累的传感器观测数据。具体来说，更新IfcPropertyTableValue需要重写整个模型，而大量动态数据会导致模型膨胀并 complicates 语义管理。基于文本的格式（如IFC-SPF）缺乏原生的时间索引和并发访问支持，这限制了实时分析和持续监控的能力。尽管关系数据库已在多个领域被证明有效，但它们并未针对大规模传感器网络所特有的高写入、时间索引和范围查询工作负载进行优化[69][70]。因此，制定一种专门针对结构健康监测（SHM）数据特征的策略至关重要，以实现可扩展性、存储效率和低延迟查询。

为满足这些需求，开发了一种双模式数据建模策略，该策略整合了IoTDB[71]的组织原则以实现高吞吐数据摄入和多维索引，同时保留了IFC模型的分层语义。在语义层面，分层组织确保了建筑构件与其监测数据之间的空间和语义对齐。在存储层面，基于标签的索引机制实现了跨设备属性、空间层次和功能区域的多维查询和聚合。这两种机制相互补充，确保语义一致性和提升大规模SHM数据的数据访问效率。在建筑环境中，传感器部署通常遵循设施的空间层次结构。在大型公共建筑中，传感器分布在多个空间层级：从建筑到楼层、功能区域、房间，再到单个设备。在BIM中，这种层次结构由IfcBuilding、IfcBuildingStorey和IfcSpace等嵌套实体表示，可以空间分解为树状结构。

下载：下载高分辨率图片（701KB）下载：下载全尺寸图片

图5.传感器数据映射的数据建模策略。

图5展示了所采用的基于路径的分层数据建模策略，以确保SHM数据与BIM之间的语义一致性，其中每个传感器观测值都被分配一个唯一路径，编码了多个语义层级，包括数据库名称、建筑标识、楼层编号、区域标签、设备ID和测点。例如，图6展示了A栋建筑3层301室中一个加速度计在BIM中的表示：IfcBuilding(A) → IfcBuildingStorey(3F) → IfcSpace(Room301) → IfcSensor(Accelerometer01)。在存储模型中，对应的层次路径表示为root.A.3F.Room301.Accelerometer01。这种路径结构保留了建筑的空间语义，并支持高效的前缀查询。例如，可以使用通配符查询来检索第三层所有加速度计的读数（例如，root.A.3F.*.Accelerometer*.*）。这种层次结构为依赖空间一致性和位置敏感分析的场景提供了独特优势，包括结构健康监测、环境感知和基于规则的事件检测。

并行地，引入了一种基于属性的组织机制，专门用于支持面向设备的运维分析，即按设备组织观测数据。每种设备类型的测量值存储在统一表中，其中时间列作为主索引，标签列记录静态属性（如设备ID、楼层和区域），字段列包含时间测量值（包括加速度、速度和位移）。标签列上的复合索引实现了结合时间和属性过滤的高效多维查询。例如，可以通过使用floor = 3F和point = Accelerometer来查询第三层所有加速度计的加速度测量值。通过协调分层的语义组织和基于标签的索引，该数据建模策略支持跨层空间聚合和多属性过滤，为短期运维监控和长期趋势分析提供统一的数据基础。

下载：下载高分辨率图片（525KB）下载：下载全尺寸图片

图6.加速度计的层次路径。

下载：下载高分辨率图片（355KB）下载：下载全尺寸图片

图7.Pset语义扩展策略。

下载：下载高分辨率图片（420KB）下载：下载全尺寸图片

图8.检查和损伤信息的IFC建模。

下载：下载高分辨率图片（973KB）下载：下载全尺寸图片

图9.IFC中的检查与损伤关联。

3.3. IFC框架

IFC通过使用对象实体、属性实体和实体化关系来表示建筑和基础设施，其中对象实体表示具有物理或功能意义的构件，属性实体指定其描述性特征，而实体化关系显式捕获它们的语义关联。层次结构以抽象实体IfcRoot为根，它定义了全局唯一标识符（GUID）、所有权和修订元数据以及基本描述属性。具有空间或几何意义的IfcObject子类被特化为IfcProduct，并进一步细化为IfcElement，以表示墙体、梁、楼板或桥梁等结构构件。构件连接通过IfcRelConnectsElements表示。场地、建筑、楼层和空间的空间层次结构通过IfcSpatialElement家族进行组织。对象与产品之间的关联通过IfcRelAssignsToProduct定义，而组级别的组织通过IfcGroup或IfcSystem结合IfcRelAssignsToGroup表示。IFC使用这种分层实体和关系结构来表示语义组织、空间层次和几何表达。

相比之下，IFC仅提供部分支持来表示传感器、监测信息和检查记录。传感器相关信息主要由IfcSensor以及有限的一组跨域实体表示。尽管ObjectType属性和若干标准化Pset允许进行基本分类，但IFC目前仅定义了24种传感器类型，其中大多数源自建筑自动化领域，如温度、压力和烟雾检测。面向结构健康监测的传感器（如加速度计、应变计和位移计）尚未被明确表示。同时，传感器与构件之间的关联通过通用的IfcRelAssignsToProduct关系建立，这缺乏可语义追溯或机器可解释的SHM语义。

为克服这些局限性并容纳面向SHM的传感需求，需要对IFC模型进行扩展。IFC有三种扩展机制：代理构件、对象类型和Pset。代理构件作为占位符使用，但会造成大量语义损失，因此不适用于严格定义的监控系统。对象类型允许用户自定义细化，但缺乏机器可解释的约束，增加了语义不一致的风险。Pset通过可扩展的键值对表达，只要自定义扩展能够保持语义清晰，它们是最灵活的选择。因此，采用了一种基于Pset的扩展策略，以实现SHM应用所需的表达能力，同时保持与IFC的语义兼容性。如图7所示，引入了三个结构化Pset来容纳设备属性、监测关系和数据接口语义。

(1) ePset_SensorProperty定义了传感器的物理和功能特征。

(2) ePset_SensorCore编码了传感器与所监测结构构件之间的语义和空间关系。

(3) ePset_SensorData提供了基于路径的标识符，引用外部SHM数据源，从而建立了与动态信息的语义链接。

转换为关系形式后，扩展的传感器语义映射到现有的关系数据库上。尽管映射方法很大程度上遵循了传统建筑构件的方式，但纳入了若干传感特定的机制。传感器坐标和局部参考系记录在形状表的专用列中，以支持空间分析和可视化。三个扩展Pset中的键值对被扁平化到Pset表中，并带有专用命名空间前缀，以便于属性级别的精确查询。引用外部SHM数据库的路径标识符作为固有属性存储在元素表中，以建立静态实体与其动态传感器数据之间的持久链接。

除基于传感器的监控外，检查活动也是SHM的重要组成部分。先前的研究提出了多种基于IFC和基于本体的方法来组织检查和损伤信息，在IFC中检查过程通常使用过程相关实体IfcTask来表示。尽管基于本体的方法提供了更丰富的语义表达能力，但使用损伤本体（如DOT[26]）与原生IFC一起会引入额外的基于RDF的语义层，这需要本体建模、映射和同步。因此，本研究采用了Bellon等人[72]提出的原生IFC方法，其表示结果可直接被本文提出的数据库映射机制处理。具体来说，如图8所示，每次检查表示为一个IfcTask实例，由唯一的检查ID标识。检查任务通过IfcRelAssignsToProduct关系与被检查的结构构件和相应的损伤实例关联。每个损伤实例由IfcSurfaceFeature实体表示，其中包含裂缝或剥落等局部表面缺陷信息。与该方法不同，检查结果（主要是照片记录）作为包含图像统一资源标识符（URI）的属性值存储，而非通过IfcDocumentReference。如图9所示，直接将图像URI作为属性值存储避免了额外的文档引用实体，并便于在关系数据库中进行映射和管理。所有检查相关信息同样被映射到关系数据库中，以便与传感器数据进行集成查询和管理。

总之，该语义扩展策略以与IFC标准完全一致的方式表示传感器和检查相关信息，同时满足了数字孪生和SHM应用的关键需求。

4. RESTful API

本节描述用于将IFC衍生的模型数据、传感器信息和检查记录作为结构化资源暴露给基于Web的数字孪生应用的RESTful API层。

下载：下载高分辨率图片（551KB）下载：下载全尺寸图片

图10.IFC资源层次结构。

4.1. IFC API

IFC API提供了一个结构化的、语义一致的接口，用于访问从IFC模型派生的建筑信息。它受到OGC API组织原则的启发，通过资源抽象和层次映射实现细粒度访问和跨系统互操作性。IFC模型被解析为关系数据库，包含项目、实体、Pset、几何和材料，它们定义了API的资源范围，并各自按照统一的URI约定映射为可寻址资源，以确保语义完整性、可扩展性和可扩展性。使用面向资源的范式，将每个实体作为独立的RESTful资源暴露。IFC API支持对项目集合、构件实体、材料、Pset和几何数据的层次化访问，允许客户端按需检索特定资源而无需加载整个文件。响应以结构化JSON格式返回，并包含持久标识符，使客户端能够通过可预测的URI模式构造对相关资源的后续请求。这种基于标识符的链接方法实现了简化的跨资源导航，同时保持了轻量级且易于集成的API。图10展示了这些JSON输出的典型示例。

在语义上，IFC API反映了IFC模型中定义的空间和构件关系的层次组织。项目对应IfcProject实体，构件映射为IfcElement级别的资源，Pset和几何作为独立的资源层暴露。关系的空间分解可以通过/decompositions端点获取，该端点返回一个树状层次结构，其节点提供持久标识符，用于通过可预测的URI模式访问相关资源。该机制建立了一个自描述的空间框架，实现了上下文感知的信息访问。几何信息以轻量级格式提供，以最小化渲染开销并确保在Web环境中高效可视化。这种语义优先和按需数据的方法增强了跨异构应用领域的可解释性和适应性。

在查询层面，IFC API通过专用资源端点提供对不同语义层的访问。可以通过提供持久标识符直接访问特定构件、Pset、材料或几何表示，从而实现精确的、局部化的数据检索而无需加载无关内容。对于几何资源，既支持集合级别访问也支持基于标识符的访问，例如/api/v1/ifc/project/geometries用于获取几何元数据或资源集合，以及/api/v1/ifc/project/geometries/{id}用于检索与特定IFC实例或几何记录相关联的显示几何。返回的几何是经提取的面向可视化的几何，包括网格数据、变换信息、材料标识符和表面样式元数据，可被Web客户端直接用于模型加载、渲染、构件高亮和基于查询的交互。当前实现采用轻量级JSON导向的表示策略作为默认响应格式，几何数据通过专用几何端点提供，而非通过多种媒体类型的完整HTTP内容协商。

关系数据库保持了IFC模型的逻辑和语义结构，确保构件描述、Pset、材料和几何信息保持一致的组织。这些语义域作为数据库内部独立但相互关联的层维护，以便于清晰地表达它们之间的关系并实现可靠的跨层交叉引用。

基于此归一化表示，IFC API将每个域作为独立的资源类别进行表示，并在其响应格式中保留底层模型的结构清晰性。对于资源管理，IFC API遵循RESTful设计原则，提供受控的CRUD操作子集。组件实体、其关联的属性集（Psets）以及材料定义支持通过基于JSON的有效载荷在数据库层面执行选定的创建、替换和更新操作，从而允许在关系数据库中增量地维护操作属性和关联关系。表1总结了代表性端点，涵盖项目、组件、属性、材料、几何形状及相关资源层。完整的API规范，包括端点路径、HTTP方法、请求参数、响应模式、数据类型和状态码，作为OpenAPI 3.0 YAML文件提供在补充文档中。

**表1. RESTful API的端点。**

### 4.2 SHM与检测API

SHM与检测API扩展了IFC API，以促进对运行数据的结构化访问和管理。在SHM与检测API中，传感器被建模为IfcSensor实体，动态时间序列观测通过语义丰富的属性集来表示，其中ePset_SensorProperty、ePset_SensorCore和ePset_SensorData分别共同支持规格描述、对象空间关联和数据库链接。如图11所示，每个响应同时包含静态配置参数和动态数据路径引用，从而确保从设备定义到数据采集的语义完整性。DataSource字段编码了每个传感器在IoTDB架构中的层次化地址，这使得IFC组件与其对应的观测数据流之间可以进行直接的语义映射。图12展示了由API返回的传感器观测数据的代表性响应。

*下载：下载高分辨率图像（524KB）*
*下载：下载全尺寸图像*
**图11. 传感器属性集的响应。**

*下载：下载高分辨率图像（445KB）*
*下载：下载全尺寸图像*
**图12. 传感器数据的响应。**

SHM与检测API为信息检索和管理提供了基于模型和基于数据两种访问模式。在基于模型的模式下，用户可以遍历从结构组件到其关联传感器和相应观测序列的路径。基于数据的模式直接通过IoTDB层次结构中的DataSource路径检索时间序列记录。SHM与检测API还可以通过事件驱动的推送机制进行扩展，从而实现传感器数据更新与Web客户端可视化的自动同步，以满足实时监控和早期预警应用的需求。

对于涉及轻量级或低功耗传感设备的场景，还支持通过MQTT进行面向消息的通信。在这种情况下，传感器将测量数据流发布到由代理管理的MQTT主题上，而服务器订阅相应主题并将传入的消息作为时间序列数据存储。这种集成确保了可靠的高频数据摄入，并在传感器数据流与所提出的框架之间建立了无缝桥接。

所有传感数据资源均以RESTful端点的形式暴露，遵循与IFC API相同的命名和语义约定，从而确保静态域与动态域之间的统一交互。IFC、SHM和检测API共同建立了一个闭环架构，将语义模型表示与SHM及检测数据联系起来。IFC API提供对模型语义和几何形状的标准访问，而SHM与检测API在同一语义框架内引入了时间可观测性。这种统一设计支持实时可视化、基于模型的状况评估以及数字孪生的持续同步，为建筑环境的智能监控和面向生命周期的决策提供了集成化且语义一致的基础。

---

## 5. 实现

本节在实际应用场景中展示了所提出的数据库驱动IFC框架的实现。开发了一个名为WebIFC+的数字孪生环境，用于评估所提出框架中各组件的可行性和工程适用性。如图13所示，该数字孪生环境由两个相互链接的模块组成，它们协同工作以实现从语义到物理的映射以及静态模型与动态监测数据之间的交互式数据访问：服务器端数据服务模块（WebIFC+ Server）和Web客户端可视化模块（WebIFC+ Client）。

*下载：下载高分分辨率图像（317KB）*
*下载：下载全尺寸图像*
**图13. 数字孪生环境示意图。**

### 5.1 WebIFC+ Server

如图14所示，WebIFC+ Server是所提出框架中的中央数据服务模块，支持基于IFC的关系映射执行以及SHM和检测数据的语义建模。其核心职责包括建筑模型、SHM和检测数据的结构化管理，传感信息的语义关联，以及通过RESTful API提供统一的资源访问，以满足建筑运营和维护的需求。WebIFC+ Server使用FastAPI框架实现，采用轻量级数据库访问层进行关系数据的查询和管理。采用分层服务架构以增强可维护性和可扩展性。在数据访问方面，采用面向微服务的设计原则，将建筑模型管理与传感器数据处理解耦，从而允许对异构数据源进行协调处理，并促进可复用的服务逻辑。

WebIFC+ Server由两层组成：语义服务层和接口层。语义服务层组织为两个模块。第一个模块处理从用户到数据库服务的前向流程，接受包括STEP、OWL和JSON在内的多种IFC文件格式，并通过ITDA将其转换为数据库。Bonsai和Revit用于将BIM与SHM和检测信息进行集成并导出。将IFC文件输入WebIFC+ Server后会自动生成SQL数据库。第二个模块处理从数据库服务返回到面向用户操作的逆向流程。它处理语义查询并管理添加、删除和更新操作。例如，当查询桥梁组件的加速度计记录时，它会解析组件与传感器的关联并从测量存储库中检索相应的观测序列。此外，它还支持根据指定的模型视图定义导出IFC文件。

*下载：下载高分辨率图像（647KB）*
*下载：下载全尺寸图像*
**图14. WebIFC+ Server架构。**

接口层将集成的模型语义和监测数据以RESTful Web服务的形式暴露，前端由Nginx实现，后端使用FastAPI实现可扩展的请求处理。它将几何片段、属性集和组件-传感器绑定打包为一致的资源表示，从而允许客户端通过单一的访问链检索模型内容和监测观测数据。

总体而言，WebIFC+ Server通过各层的协调运作，将IFC关系数据库与IoTDB时间序列存储集成在一起。数据服务层管理模型和传感器信息的提取、结构化和语义组织，以确保组件、传感器及其数据路径之间的一致关系。接口层为这些集成资源提供标准化的RESTful访问。这种安排将静态模型语义和动态观测数据整合为一个逻辑连贯且语义统一的基础，支持3D可视化、实时监控、状况评估和运营决策的数字孪生应用。

### 5.2 WebIFC+ Client

WebIFC+ Client是一个基于浏览器的3D可视化平台，使用React和Three.js开发，用于加载建筑组件几何形状、可视化语义属性、检索实时传感器数据，并提供带有交互式反馈的集成渲染。作为前端交互层，客户端直接与WebIFC+ Server的RESTful API通信，从而允许从语义信息到运行状态的动态可视化，并支持SHM和设施管理的交互式访问和态势感知。

当建筑模型加载时，客户端接收服务器解析的IFC数据，并在浏览器内重建层次化结构的3D场景，使用户能够通过选择、高亮和聚焦导航等基本操作与模型进行交互。这种设计实现了从全局空间探索到详细组件检查的无缝过渡。

当在3D查看器中选择某个建筑组件时，其语义描述会从基于IFC的关系数据库中自动检索，并根据存储的分配和分解关系推导出逻辑关联的传感器。对于每个识别出的传感器，其对应观测记录会在用户指定的时间区间内从服务器检索。检索到的观测数据在界面中的结构化数据面板中显示，同时锚定到3D场景中的相应传感器位置，从而允许在数字孪生环境中直观地识别和检查传感点及其关联测量值。

*下载：下载高分辨率图像（578KB）*
*下载：下载全尺寸图像*
**图15. WebIFC+ Client界面。**

如图15所示，界面组织为三个核心功能区域：左侧工具面板、中央3D视口和右侧模型导航与属性面板。左侧工具面板提供附加功能，包括基本模型编辑、损伤检测、损伤定位和IFC导出，使用户能够针对SHM和环境异常检测等目标定制可视化。中央3D视口提供交互式可视化，并分层控制几何模型、传感器叠加和告警标记的可见性。右侧面板集成层次化对象树以遍历IFC结构，以及元素属性视图，显示所选组件的语义属性、关联传感器的技术规格、最新传感器读数和历史异常记录。

---

## 6. 用例与讨论

为验证所提出的数据库驱动IFC框架，测试了两个用例，展示了完整的流程：语义映射、传感器数据集成、检测结果映射和可视化。

*下载：下载高分辨率图像（487KB）*
*下载：下载全尺寸图像*
**图16. 建筑A及其加速度计监测数据。**

### 6.1 既有建筑的SHM

第一个用例考察了所提出的数据库驱动IFC框架在建筑运营和维护场景中的适用性，特别关注部分模型访问和语义导航。安众大厦（建筑A）是一栋位于浙江大学校园（中国杭州）的九层办公楼，建于2006年（如图16所示）。建筑A的IFC模型（IFC4）通过WebIFC+ Server暴露为HTTP可访问资源，以实现按需检索和局部组件的语义检查，以及传感器数据的实时可视化，而无需加载整个IFC文件。

使用建筑A的原始IFC文件，其中包含完整的结构和空间层次信息。IFC文件首先通过ITDA转换生成关系数据库，包含元素、属性集、几何形状和形状等结构化表。转换后，所有组件的GUID、空间层次结构、属性集和网格数据被组织在关系数据库中，以支持按需访问和高效查询，如图17所示。该用例的工作流程如图18所示。

*下载：下载高分辨率图像（1MB）*
*下载：下载全尺寸图像*
**图17. 在DataGrip界面中展示的建筑A的IFC数据库可视化。**

*下载：下载高分辨率图像（827KB）*
*下载：下载全尺寸图像*
**图18. 既有建筑SHM的用例。**

**(1)** 为将建筑模型暴露为Web可访问资源，ITDA流程生成的关系数据库首先在WebIFC+ Server上注册，随后加载包括空间层次结构、元素索引和属性摘要在内的元数据，以建立后续查询的入口点。完成后，模型即可在客户端加载和渲染（图18(a)）。

**(2)** 为探索建筑的空间层次结构，WebIFC+ Client向WebIFC+ Server查询与建筑模型关联的预处理的建筑和结构元素层次结构。WebIFC+ Server以树结构返回该层次结构，随后由WebIFC+ Client在界面中渲染（图18(b)）。

**(3)** 当从空间层次结构中选择了IFC模型的特定部分时，WebIFC+ Server通过遍历数据库中存储的分解关系来检索相应的建筑组件。WebIFC+ Server随后返回这些元素的集合及其关键属性的结构化数据，WebIFC+ Client随后在3D查看器中渲染以实现交互式探索（图18(c)）。

**(4)** 为获取监测数据，WebIFC+ Client发出包含设备级过滤参数的GET请求。WebIFC+ Server解析这些约束，从数据库中检索相应的时间序列记录，并返回按时序排列的数据集，以便在WebIFC+ Client上进行实时可视化（图18(d)）。

### 6.2 桥梁检测与缺陷可视化

第二个用例展示了所提出的数据库驱动IFC框架在桥梁检测场景中的适用性。目标是实现在数字孪生环境中对缺陷信息进行结构化存储、语义关联和直观可视化，以促进检测驱动的分析和维护决策。

在中国杭州选择了一座简支桥梁进行基于无人机（UAV）的检测，如图19所示。

总共拍摄了 4333 张照片，记录了桥梁的几何和表面状况。采集的图像经过处理生成 3D 点云，随后重建为模型（IFC4 × 3），作为输入 IFC 模型。此用例的工作流如图 20 所示。
下载：下载高分辨率图像 (479KB)
下载：下载全尺寸图像
图 19. 测试桥梁及无人机的飞行路线。
下载：下载高分辨率图像 (861KB)
下载：下载全尺寸图像
图 20. 桥梁巡检和缺陷可视化的用例。
下载：下载高分辨率图像 (691KB)
下载：下载全尺寸图像
图 21. WebIFC+ 客户端中的裂缝可视化。

(1) 使用先前工作中开发的裂缝检测算法 [73] 分析无人机获取的巡检图像以检测表面缺陷。该算法自动识别包含裂缝的图像，分割相应的裂缝区域，并提取其几何和描述性属性。每个检测到的缺陷都标注了其空间位置和相关信息元数据，以形成结构化的缺陷数据集用于后续的语义集成（图 20(a)）。

(2) 将识别出的缺陷信息语义化地整合到桥梁模型中，以增强其巡检相关表示。每个巡检任务被定义为 IfcTask 实例，并通过标准的 IFC 关系链接到相应的结构组件和缺陷实体。损坏实例被表示为 IfcSurfaceFeature 实体，而相关的摄影记录则通过外部引用。因此，增强后的模型保持了巡检活动、缺陷特征和视觉文档之间的可追溯连接（图 20(b)）。

(3) 通过 ITDA 将包含巡检语义的更新 IFC 模型转换为关系数据库结构，并部署到 WebIFC+ 服务器。然后，用户可以通过 WebIFC+ 客户端交互地访问、查询和可视化巡检结果、缺陷信息、相应的图像采集位置以及相关的结构组件（图 20(c)）。

(4) 利用图像采集期间记录的无人机飞行轨迹和相机位姿信息，将检测到的裂缝区域与桥梁模型上的相应位置进行空间配准。通过将图像坐标与无人机的外方位角参数相结合，裂缝位置被准确地反投影到 3D 几何上。映射的缺陷在 WebIFC+ 客户端中可视化，以便直观地检查桥梁的表面状况和裂缝的空间分布（图 20(d) 和 21）。

6.3. 性能与适用性分析
性能评估旨在比较关系型方法和基于 RDF 三元组的方法。选择 MySQL 和 GraphDB 作为这两种方法具有代表性的成熟实现。为了隔离数据组织和查询执行的影响，两个数据集都从相同的 IFC 信息生成，并且没有将额外的领域特定本体或推理知识引入基于 RDF 三元组的表示中。

所有转换和查询实验均在同一台机器上进行。MySQL 服务、FastAPI 服务和 GraphDB 实例通过本地回环接口访问，以排除外部网络变化。硬件和软件配置总结在表 2 中。实验中使用的 GraphDB 免费许可仅限于一个 CPU 核心。为了保持可比的查询工作负载，MySQL 基准测试配置为通过一个活动连接进行顺序单客户端执行，以匹配 GraphDB 使用的顺序请求模式。

进行了三组实验。第一组使用 Anzhong 建筑 A 模型来比较四种 MySQL 映射配置和一种 RDF 工作流程的转换开销和输出大小，如表 3 所示。报告的转换时间涵盖了每个工作流程的一次完整执行。MySQL 输出大小是从表数据和索引长度计算的，而 RDF 输出大小指的是序列化的 Turtle 文件。因此，这些值提供的是实现级别的参考，而不是相同的物理存储度量。另外两组使用 IFC4 × 3 EON 建筑模型来评估查询的可扩展性，方法是独立变化传感器数量和整体 IFC 模型大小。传感器数量变体是通过添加唯一标识和定位的 IfcSensor 实例生成的，并带有相应的类型、空间包含、嵌套和属性集信息，而模型规模变体则作为单个 IfcProject 下的一到四个空间偏移的建筑内容副本生成。传感器数量实验保留了相同的建筑几何，而模型规模实验保留了相同的传感器数量，从而分离了两个扩展维度的影响。表 4 总结了生成的变体；S71 和 M1 使用相同的基准模型。

表 2. 实验环境。
项目 配置
操作系统 Windows
处理器 Intel Core i9-14900HX (32 个逻辑 CPU)
内存 64 GB DDR5 5200 MHz
存储 1 TB SSD
MySQL 8.4.2 (InnoDB)
GraphDB 11.3.3
Python 3.9.19
IfcOpenShell 0.7.11
FastAPI 0.128.8
MySQL Connector/Python 9.4.0

对于这两个可扩展性实验，MySQL 数据集在全模式模式下生成，不包含衍生网格提取，而 RDF 数据集则从相同的 IFC 实例和信息范围生成。实施了 11 个等效的查询任务，分别用 SQL 和 SPARQL 编写，如表 5 所示。Q1–Q8 用于两个实验中，而面向墙体的 Q9–Q11 则添加到模型规模实验中。所有列表查询都进行了排序并限制在前 100 条记录，以代表分页的 Web 请求。在计时之前，直接 MySQL、FastAPI 和 GraphDB 返回的完整结果经过了标准化并检查了等效性。所有评估的查询 - 变体组合都通过了此验证。

表 3. MySQL 和 RDF 工作流程的转换开销和存储比较。
工作流程/模式 转换时间 (s) 输出大小 (MB)
MySQL 全模式带几何 123.70 135.75
MySQL 全模式不带几何 87.24 132.89
MySQL 实例驱动带几何 117.06 113.31
MySQL 实例驱动不带几何 73.31 109.78
RDF 实例级表示 423.01 294.31

表 4. 传感器数量和模型规模变体的 IFC 和 RDF 大小。
变体 建筑物 传感器 IFC 实体 IFC 大小 (MB) RDF 三元组
S71 1 71 374,697 26.11 12,867,717
S250 1 250 385,097 26.89 02,949,480
S500 1 500 400,065 28.01 13,067,382
S750 1 750 414,666 29.10 43,182,246
S1000 1 1000 429,634 30.22 53,300,148
S1500 1 1500 459,203 32.44 03,532,914
S2000 1 2000 488,772 34.65 43,765,680
M1 1 71 374,697 26.11 12,867,717
M2 2 71 744,231 52.18 85,695,657
M3 3 71 1,113,765 78.47 28,523,597
M4 4 71 1,483,299 105.54 311,351,537

由于关系型和 RDF 存储在物理组织和索引机制上有所不同，无法强制实施完全等效的优化设置。因此，基准测试比较了实际的数据访问配置。MySQL 使用常规的索引和次索引来处理实体标识符和频繁查询的属性，而 GraphDB 使用其原生的 RDF 索引机制。这些配置在所有变体中保持不变。

表 5. 可扩展性实验中使用的查询任务。
ID 查询任务 结果范围
Q1 所有 IFC 实体计数 聚合
Q2 传感器计数 聚合
Q3 传感器列表 前 100 条记录
Q4 按 GlobalId 查找单个传感器 一个传感器
Q5 单个传感器属性查找 一个属性
Q6 传感器空间包含列表 前 100 条记录
Q7 传感器类型关联列表 前 100 条记录
Q8 传感器属性列表 前 100 条记录
Q9 墙体计数 聚合
Q10 墙体类型关联列表 前 100 条记录
Q11 墙体属性列表 前 100 条记录

性能评估比较了两种基于 HTTP 的数据访问方法：通过带有连接池数据库连接的 FastAPI 服务访问的 MySQL，以及通过其 SPARQL 端点访问的 GraphDB。两种方法都复用了持久的 HTTP 会话。包括通过持久连接器连接直接访问 MySQL，以量化由服务层引入的开销。请求由一个客户端顺序发出。执行时间使用单调计时器测量，包括查询执行、完整结果传输和客户端响应解析。在测量迭代期间禁用了 Python 垃圾回收。

基准测试测量的是预热后的运行延迟。每种访问模式下的每个查询执行了三次，以减轻初始化和缓存填充效应，随后进行 30 次测量迭代。为了减少系统性顺序效应，MySQL 本地、MySQL FastAPI 和 GraphDB 的执行顺序在连续迭代之间进行了轮换。报告 30 次测量迭代的算术平均值作为性能统计。传感器数量和模型规模实验的结果分别如图 22、图 23 所示。

图 22 报告了传感器数量实验。对于两种基于 HTTP 的方法，类型约束计数和索引点查找 (Q2, Q4 和 Q5) 保持几乎恒定。在有限的列表查询中，随着传感器数量从 71 增加到 2000，Q3 在 FastAPI 中保持稳定，但在 GraphDB 中增加了 4.60 倍。面向关系的 Q6 和 Q7 显示出类似的对比：FastAPI 增加了 1.11 和 1.38 倍，而 GraphDB 则为 4.43 和 5.56 倍。因此，将输出限制为 100 条记录并不能消除评估和排序不断增长的 RDF 候选集的影响。
下载：下载高分辨率图像 (610KB)
下载：下载全尺寸图像
图 22. 传感器数量扩展实验中的平均查询时间。

属性列表查询 Q8 对传感器体积最为敏感，在 FastAPI 中增加了 13.67 倍，在 GraphDB 中增加了 23.27 倍。在两种表示中，该查询必须扩展和排序不断增长数量的传感器属性记录；RDF 查询此外还遍历相应的属性子图。对于 Q8，FastAPI 在所有传感器数量变体中保持了更低的响应时间。

图 23 报告了模型规模实验。对于两种方法，类型约束的 Q3 和 Q9 保持几乎恒定，而全局实体计数 Q1 在 M1 和 M4 之间在 FastAPI 中增加了 1.98 倍，在 GraphDB 中增加了 4.39 倍。这种区别表明，类型约束查询可以随着数据集的增长而保持稳定，而覆盖完整表示的操作则对整体模型大小保持敏感。
下载：下载高分辨率图像 (553KB)
下载：下载全尺寸图像
图 23. 模型规模实验中的平均查询时间。

面向关系的查询显示出不同的模式。在传感器数量固定的情况下，GraphDB 在 Q6 和 Q7 上保持几乎恒定，而 FastAPI 增加了 2.41 和 2.45 倍。对于面向墙体的 Q10，FastAPI 和 GraphDB 分别增加了 2.63 和 1.79 倍。这些差异与 MySQL 中 JSON 编码的 IFC 关系集合的扩展和 GraphDB 中显式 RDF 边的遍历一致。面向属性的 Q11 在 FastAPI 中增加了 3.37 倍，在 GraphDB 中增加了 4.42 倍。总体而言，基于 FastAPI 的 MySQL 访问在全局计数和属性检索中保持了更低的响应时间，而 GraphDB 在某些关系遍历查询中具有优势。

6.4. 讨论
两个用例的实现验证了所提框架在集成 SHM 和巡检信息方面的有效性，并表明了在不同 IFC 模式版本之间具有一定的兼容性，因为办公楼案例和桥梁案例分别基于 IFC4 和 IFC4 × 3。通过在持久数据库环境中根据其模式重新组织 IFC 数据，该框架能够实现模型、传感器和巡检信息的一致性管理，并按需检索或修改。保留的 IFC 标识符和关系保持了操作记录与相应组件之间的关联，而通用的数据库表示支持模型、监控和巡检数据的集成管理。

受控的基准测试实验进一步评估了所提的关系表示在传感器数量和 IFC 模型大小增加下的表现。基于 FastAPI 的 MySQL 通常比 GraphDB 在全局计数、属性检索和面向传感器的查询中实现了更低的响应时间。这些操作构成了评估的 DT 工作流程中的经常性访问模式，表明所提的表示非常适合 IFC 和监控数据的常规管理及基于服务的检索。GraphDB 在较大模型中的某些关系遍历查询中表现更好，这表明在关系映射中处理 IFC 关系集合仍然是进一步优化领域。

7. 结论与未来工作
在本研究中，开发了一个数据库驱动的 IFC 框架，通过关系数据库和时间序列数据库以及统一的 RESTful API 将 IFC 语义与 SHM 和巡检数据集成。该框架保留了 IFC 原生结构，同时启用组件级查询、增量扩展以及对模型和观测数据的按需访问。通过建筑 SHM 和桥梁巡检用例证明了其可行性，而与基于 RDF 的工作流程在转换时间、存储成本和代表性查询性能方面的定量比较进一步验证了其适用性和效率。主要结论总结如下。

(1) ITDA 管线将 IFC 模型转换为结构化的关系数据库表示，同时保留实体、属性、关系、属性和几何信息。这使得能够对 IFC 衍生的数据进行细粒度管理和高效查询。

(2) 双模式数据建模策略结合层级空间路径和基于标签的索引来组织高频传感器数据。这种设计支持 DTs 应用中的空间聚合和多维查询。

(3) 语义扩展策略使用 IfcSensor 和 IfcSurfaceFeature 在 SHM 和巡检数据及其相应的结构组件之间建立可追溯的关联，同时将生成的语义保留在原生 IFC 表示中。

(4) 提出的面向服务的数据访问方法采用 RESTful APIs，以启用基于资源的、按需的与模型实体、几何、属性和观测数据的交互，适用于基于 Web 的 DT 应用。

(5) 与基于 RDF 三元组的 GraphDB 实现进行的对比实验证明了所提方法在全局计数、属性检索和面向传感器查询方面的优势。

尽管证明了所提框架的可行性，但在 IFC 编辑和同步、协作数据治理以及传感器语义标准化方面仍存在若干局限性。

(1) 数据库目前支持相对简单的修改，涉及实体属性、Psets、传感器元数据、巡检记录和组件关联。虽然通过保留 IFC 原生实体、STEP 行标识符和引用映射已实现数据库到 IFC-SPF 的同步，但全面的创建、删除和复杂更新仍然需要改进的事务控制、反向引用处理、一致性检查和模式验证。未来的工作将把现有的 IFC-SPF 编辑逻辑扩展到面向数据库的环境中。

(2) 当前的集中式实现主要适用于单个利益相关者或所有者运营的 DTs 场景。其在分布式和多组织环境中的应用需要额外的机制来处理冲突解决、访问控制、版本治理和合同数据交换。

进一步的研究应调查与去中心化的通用数据环境、链接数据平台、数据空间以及标准化数据合同的同步。(3) 自定义传感器相关的Psets仍然局限于项目特定性，限制了其语义互操作性和重用性。在存在相应概念的情况下，其各项属性可以与buildingSMART数据字典中的标识符进行链接，并与相关定义和单位保持一致。OGC SensorML和OGC SensorThings API可分别支持标准化的传感器描述和观测数据接口。(4) 尽管所提出的映射机制是从每个输入IFC模型所声明的EXPRESS模式导出关系模式的，因此并不内在地与单一IFC版本绑定，但其应用层面的验证迄今为止仅限于一个IFC4建筑模型和一个IFC4×3桥梁模型。这些案例覆盖的IFC实体、关系、传感器配置和检测场景范围有限。因此，该机制在多样资产类型和项目背景下的更广泛适用性仍有待评估。**CRediT作者贡献声明** Shu Jiangpeng：写作 – 审阅与编辑、监督、资源、项目管理、方法论、资金获取。Luo Yuhang：写作 – 审阅与编辑、写作 – 原稿、可视化、验证、软件、方法论。Song Jiawang：写作 – 审阅与编辑、调查、数据整理。Zhang Congguang：写作 – 审阅与编辑、资源、项目管理、方法论、数据整理、概念化。Zhang Jianhua：写作 – 审阅与编辑、监督、项目管理。Jia Nanfei：写作 – 审阅与编辑、监督、项目管理。Ji Wei：写作 – 审阅与编辑、监督、项目管理。**生成式AI及AI辅助技术在稿件准备过程中的声明** 在本文准备过程中，作者使用了ChatGPT来改善语言表述并辅助创建图中使用的图标。在使用该工具后，作者对内容进行了审阅和编辑，并对发表内容承担全部责任。Shu Jiangpeng | Luo Yuhang | Song Jiawang | Zhang Congguang | Zhang Jianhua | Jia Nanfei | Ji Wei