行业分析：无完美BIM数据集可跨全生命周期原样使用，应构建数字连续性层

原创 明祥决策研究室 2026-09-19 00:01 广东

从工程建造走向建筑长期价值

这些年做 BIM、数字孪生、CIM、资产管理，我们似乎一直隐含着一个愿望：

如果设计阶段把数据建得足够完整、足够规范，竣工时再认真补齐一次，那么这套数据是不是就可以一路传给运维，甚至陪伴建筑几十年？

于是行业不断追求更高的模型完整度、更完整的属性、更严格的交付标准、更庞大的竣工模型。

设计阶段缺什么，就要求设计补。

施工阶段变了，就要求施工补。

竣工以后，希望把所有东西一次性交给运营。

这个逻辑听起来非常合理。

但研究建筑真正的长期生命周期以后，我越来越意识到：

这个目标从一开始可能就设错了。

不是因为 BIM 做得不够好。

而是因为：

根本不存在一份“完美 BIM 数据集”，能够从设计阶段开始，在施工、运营、维修、更新、改造乃至几十年后的再次建设中，原封不动地持续使用。

问题并不是数据还不够完整。

问题是——建筑的现实在变，使用数据的人在变，责任在变，问题也在变。

一、设计阶段需要的数据，本来就不是运营阶段需要的数据

设计师面对的是一个尚未完全成为现实的建筑。

设计阶段最关心的是：

应该建成什么？

一台空调机组，需要回答：

它服务哪个区域？

设计风量是多少？

冷量是多少？

设备空间是否满足？

管线怎样连接？

性能目标是什么？

设计依据是什么？

这是一套典型的Design Intent。

但是建筑建成以后，运营人员面对的问题已经变成：

现在实际上是什么？

真正安装的是哪个厂家？

哪个型号？

哪个序列号？

哪一天调试完成？

保修到什么时候？

最近三年坏过几次？

哪个零件换过？

现在的运行参数是多少？

昨天报警以后做了什么？

维修以后问题到底有没有真正消失？

这已经不是设计问题。

更不是靠不断给设计 BIM “补字段”就能解决的问题。

ISO 19650 本身就没有假设全生命周期只存在一份静态信息集合。ISO 19650-1 面向从规划、设计、施工，到日常运营、维护、翻新、维修乃至报废的整个 built asset 生命周期；ISO 19650-3 又专门针对运营阶段规定了独立的信息管理过程和信息交换。

换句话说：

生命周期连续，不等于信息需求不变。

二、甚至“应该交什么数据”，本来就是随用途变化的

这也是为什么 buildingSMART 后来会发展 IDS——Information Delivery Specification。

IDS 的意义并不是再发明一个更大的 BIM。

恰恰相反。

它允许针对一个具体用途，机器可读地声明：

这一次，我到底需要哪些对象、分类、属性、材料、数量、关系和值。

而不是说：

所有对象从出生起，就应该永远携带所有可能需要的数据。

buildingSMART 对 IDS 的定位非常明确：它用于定义use-case-specific information requirements，并自动检查 IFC 是否满足这些要求。

ISO 23387:2025 也采取类似方向：它提供生命周期对象的 machine-interpretable data template 结构，但并不规定一套世界统一、永不变化的模板内容。

这背后其实隐含着一个很重要的事实：

不存在“一次定义、终身适用”的完美对象数据模板。

不同业务场景，需要不同的信息切片。

三、施工以后，连“这个对象是谁”都会发生变化

这可能比属性变化更加根本。

设计模型里有一台：

AHU-01。

设计阶段，它首先代表的是：

这里需要一个满足某种性能要求的空气处理功能。

施工采购以后，现实世界出现了一台真正的机器：

某厂家。

某型号。

Serial No. 123456。

十年以后，这台机器报废，被另一台：

Serial No. 789012

替换。

问题来了：

AHU-01 还是不是 AHU-01？

答案是：

看你问的是哪一层。

如果问：

B2 东区那个空气处理功能位还在不在？

可能还在。

如果问：

2028 年安装的那台物理设备还是不是原来那台？

当然不是。

所以：

长期功能对象

和

某一次物理实例

本来就不是一回事。

ISO 81346-12 很值得注意。它专门处理建筑和建筑设备的系统结构与 reference designation，同时明确指出，这套 reference designation 并不是用于 serial number、inventory number 等具体 product individual。

这实际上已经在告诉我们：

“建筑里的那个功能对象”与“今天安装的这一台实体设备”需要被分开理解。

四、而且很多时候，对象根本不是“一换一”

设备替换还算简单。

空间更麻烦。

一个会议室用了十年以后，被隔成两个办公室：

Room 0312

     ↓

Room 0312A

Room 0312B

请问哪个才是原来的 Room 0312？

如果按照几何面积判断：

可能 0312A 占了原来 70%，于是系统说：

A 就是原来的房间。

但这其实是人为制造“身份连续”。

真实情况更合理的表达是：

原 Room 0312 的身份结束了。

但它的历史并没有消失。

它变成了两个新空间的 predecessor。

也就是说：

Identity Continuity 结束。

但：

Lineage Continuity 仍然存在。

反过来，两个房间打通变成一个大房间也是一样。

建筑几十年的生命周期里，会不断发生：

Replace、Split、Merge、Relocate、Reclassify、Renovate。

所以所谓长期连续性，从来不可能只是：

给每个 BIM Object 一个永远不变的 GUID。

五、GUID 也不是现实世界本身

IFC 有自己的 IfcGloballyUniqueId。

它非常重要。

它能够唯一标识一个 IFC object instance。

但这并不意味着：

IFC GUID = 建筑现实对象几十年的永久身份。

第二次改造的时候，设计院可能重新建模。

原来的：

GUID-A

变成：

GUID-X。

现实中的设备根本没换。

反过来，也可能模型制作者错误复用了旧 GUID，但现实中的设备早已换了一代。

所以真正的问题不是：

GUID 是否稳定？

而是：

数字世界里的这个表示，现在究竟指向现实世界里的谁？

NIST 在 Digital Thread 研究中也发现了类似问题。2024 年的一项研究指出，跨生命周期追踪非常依赖 persistent identifiers，但广泛使用的产品数据标准和商业工程软件仍不足以完整支持这种长期唯一标识。

但即便 UUID 问题彻底解决，也仍然解决不了：

一变二、二合一、旧设备替换、新设备复用、功能重新分配。

因为这些不是 ID 格式问题。

而是：

Identity Evolution。

六、责任也不可能几十年不变

设计师负责设计意图。

供应商负责产品。

施工单位负责安装。

调试单位负责调试结果。

建设单位负责验收。

运营团队负责日常使用。

维修商负责某一次维修。

专业检测机构可能在二十年以后重新给出安全鉴定。

因此我们也不能简单给一个对象写：

Owner = XXX

然后认为责任问题解决了。

更加准确的问题应该是：

谁在什么时间，有权对这个对象的什么事实作出声明？

施工单位可以声明：

已安装。

但它未必有权单独声明：

结构安全。

BMS 可以记录：

当前温度 31℃。

但温度传感器不是“设备是否符合验收标准”的 Authority。

PROV-O 已经提供了 Entity、Activity、Agent 等 provenance 基础，专门表达什么东西通过什么活动产生、由什么主体承担责任。

所以未来真正重要的不是简单问：

数据是谁上传的？

而是：

这个事实是谁声明的？他的 Authority 是什么？证据在哪里？这条声明在什么时间有效？

七、时间也是数据本身的一部分

建筑不是一个只存在“当前状态”的对象。

比如：

设备实际在 2038 年就完成了替换。

但因为旧系统数据没有迁移，2040 年做新一轮改造时，我们才从施工档案里发现这件事情。

于是存在两个不同的时间：

Reality Time：

2038 年，设备真的换了。

Knowledge Time：

2040 年，新的系统才知道设备在 2038 年换过。

如果数据库直接写：

current equipment = SN002

过去就被抹掉了。

而建筑长期价值真正依赖的是：

历史可以被重新理解，但历史不能被无痕覆盖。

OWL-Time 这样的国际时间模型早已说明，真实世界的信息不仅有时间点，还有时间区间、前后关系、包含关系和持续时间。

八、这就是为什么“竣工交一份完美 BIM”解决不了全部问题

这不是说竣工 BIM 不重要。

恰恰相反，它非常重要。

但它只是一个时间点的高价值数字表达。

COBie 的思想很有启发性。

它从来没有假设所有生命周期信息必须一次性在设计阶段完成。

COBie 明确支持不同阶段的 interim deliverables，也就是 data drops：

概念设计结束一次；

深化设计结束一次；

施工文件阶段一次；

甚至建筑投入使用后，还可以按固定周期持续发生数据交付。

这背后的逻辑其实很清楚：

信息随着建筑生命周期逐步产生，也会随着用途不断变化。

所以真正该追求的不是：

一个永远完美的数据快照。

而是：

一个可靠的连续过程。

九、Digital Twin 同样不能天然解决这个问题

人们很容易说：

那就做 Digital Twin。

但 Digital Twin 本身也可能只是某一个阶段的数据世界。

NIST 对产品全生命周期 Digital Twin 的研究指出，目前多数 Digital Twin implementation 仍然聚焦某一个 lifecycle stage，形成不同 silo；真正困难的是把不同生命周期阶段的异构数据流整合起来。Digital Thread 正是为了表示贯穿产品生命周期的信息流。

另一项 NIST 研究甚至指出，如果试图把全生命周期所有数据都集中到一个中央 repository，随着不同阶段数据持续进入和变化，数据 reconciliation 的负担会迅速变得困难，因此研究转向使用 graph 去连接不同生命周期域的数据。

这给建筑数字化一个非常重要的启发：

长期连续，不一定意味着把全部数据放进一个巨大平台。

连续性完全可能来自：

连接。

而不是：

集中。

十、真正应该几十年持续的，可能根本不是“数据集”

这是我现在最大的认知变化。

以前总在问：

怎样让 BIM 数据陪建筑走几十年？

现在我认为更准确的问题应该是：

当 BIM、系统、物理设备、使用功能、项目和责任主体不断变化时，什么东西必须保持连续？

我现在倾向于只有几样东西真正值得长期维持：

第一，Identity

我们现在说的是谁？

第二，Lineage

它从哪里来？

后来变成了什么？

第三，Time

这个事实什么时候在现实中成立？

我们又是什么时候知道的？

第四，Authority

谁有权声明这个事实？

第五，Evidence

为什么相信这条声明？

证据在哪里？

第六，Binding

今天 IFC、CMMS、BMS、ERP、IoT 里的那些不同 ID，究竟分别指向现实中的谁？

这些东西才像建筑几十年的“骨架”。

至于：

模型、

图纸、

工单、

传感器时序、

报告、

照片、

合同、

算法结果，

完全可以继续存在于最适合它们的专业系统里。

十一、所以真正需要轻量化的，不是 BIM，而是连续性

这可能是一个更重要的方向。

我们一直试图让：

模型越来越重，数据越来越全。

也许长期建筑真正需要的反而是一层非常薄的基础设施：

设计 BIM

施工系统

CDE

ERP

质量系统

        │

        │

────────┼────────────────

   Continuity Layer

────────┼────────────────

        │

CMMS

BMS

IoT

能源系统

检测鉴定

下一次改造 BIM

它不拥有所有数据。

只负责回答：

这是同一个对象吗？

如果不是，它和以前那个对象是什么关系？

什么时候发生的变化？

是谁确认的？

证据在哪里？

下一次 Project 如何继续接上？

十二、这也改变了“建筑全生命周期数字化”的目标

过去很容易把全生命周期数字化理解成：

把设计、施工、运营所有数据汇聚起来。

现在我越来越倾向于另一种定义：

全生命周期数字化的真正难点，不是让所有数据永远存在于同一个系统，而是让不断变化的数据仍然指向同一个可信的现实历史。

这是两个完全不同的目标。

前一个目标容易走向：

超级平台。

后一个目标更接近：

Digital Thread。

也更接近建筑长期价值真正需要的东西。

十三、一个建筑活五十年，真正不应该丢失的是什么？

不是 2028 年那份 BIM 文件必须原封不动活到 2078 年。

那几乎是不现实的。

五十年里：

设计软件会换。

IFC 版本会换。

业主可能会换。

物业会换。

CMMS 会换。

BMS 会换。

设备会换。

房间会拆。

系统会重组。

建筑会经历一次又一次新的 Project。

真正不能丢的是：

这个建筑是谁。

这个长期对象是谁。

它过去由什么现实实体实现。

后来发生了什么。

什么东西被替换了。

什么空间被拆分或合并了。

哪些判断是谁在什么依据下作出的。

今天看到的现实，是怎样从过去一步一步演化来的。

这才是几十年的建筑数字连续性。

十四、终于明白，“完美 BIM”可能从来就不是正确目标

BIM 并没有失去价值。

恰恰相反：

设计 BIM、施工 BIM、竣工 BIM、改造 BIM，都应该在它们自己的阶段尽可能准确。

但是：

每一个 BIM 都是某一时间、某一任务和某一责任结构下，对建筑现实的一次数字表达。

它不需要承担：

永远成为建筑本身。

真正需要长期存在的，应该是这些不同表达之间的：

continuity。

所以未来值得研究的问题可能不再是：

怎样做一份越来越大的“全生命周期 BIM”？

而是：

怎样让不同阶段、不同系统、不同项目产生的数据，不需要被强行统一，却仍然能够保持长期身份、时间、责任、证据和谱系连续？

如果这个问题成立，那么建筑数字化的架构也许应该从：

One Perfect Model

转向：

Many Changing Models + One Persistent Continuity

中文可以说：

不是让一份数据活几十年，而是让建筑的数字连续性活几十年。

这也许才是真正从工程建造走向建筑长期价值的那一步。

跳转微信打开