返回 BIM 与 IFC 博客
交付与 ISO 19650 · 2026-10-01 · 10 分钟
从 IFC 生成 COBie：运维团队真正需要什么（以及交付前如何检查）
COBie 是好 BIM 的葬身之地：项目最后一周才生成的电子表格，满是空单元格，运维团队从来不打开。尽早从 IFC 中提取它，并衡量它的完整程度，就能改变这一点。
从 IFC 生成 COBie：运维团队真正需要什么（以及交付前如何检查） — IFC Viewer Online article cover
问一位设施经理，他们最近一栋新楼的 COBie 用来做了什么，最常见的回答是一阵沉默。表格是有的：交付了，满足了合同，有十八个工作表。而 Component 工作表——列出需要维护的东西的那张——有一半是空的，因为直到交付那一周都没人看过它。
解决办法不是在最后用一个更好的 COBie 工具，而是尽早、经常地从 IFC 中提取 COBie，在还有时间建模的时候衡量缺了什么。
COBie 是 IFC 的一个视图，而不是单独的交付物
每张 COBie 工作表都是 IFC 实体的一个视图。Component、Space 和 Type 承载了运维所需的大部分信息。
COBie 里每一行重要的数据，都对应 IFC 中的某样东西。Floor 是 IfcBuildingStorey；Space 是 IfcSpace；Type 是构件类型，例如 IfcDoorType；Component 是构件实例——某一扇具体的门、某一台具体的水泵。COBie 要求的属性，都保存在 IFC 的属性和属性集中。
| COBie 工作表 | 来源 | 运维用途 |
|---|
| Facility | IfcProject、IfcSite、IfcBuilding | 确认是哪栋建筑 |
| Floor | IfcBuildingStorey | 在资产台账中导航 |
| Space | IfcSpace（名称、长名称、面积） | 房间清单、保洁、空间管理 |
| Zone | IfcZone 及空间分组 | 防火、暖通和安防分区 |
| Type | 构件类型及其 pset | 产品数据、质保、备件 |
| Component | 构件实例 | 需要维护的资产——COBie 存在的意义 |
| System | IfcSystem 及其分配关系 | 哪些组件构成一个系统 |
结论既让人不舒服，又很有用：COBie 差，说明模型差。在最后一周手工修补表格，得到的文档与它所谓的来源模型并不一致——下一次交付还得再来一遍。
为什么大多数 COBie 交付物是空的
- 空间从未建模，或建模时没有命名。没有空间就没有 Space 工作表，每个 Component 也都失去了位置。
- 组件没有稳定的标识。如果 GlobalId 在多次导出之间变化，资产台账就无法用后续模型更新，只能重建。
- 类型缺失或过于笼统。两百扇门都指向同一个叫“门”的类型，技术上算有 Type 工作表，实际上毫无用处。
- 制造商、型号和质保数据在模型冻结后才到，被直接录入表格，而不是录入模型。
第二点会悄无声息地毁掉整件事的价值。为什么每次导出 IFC GUID 都会变 解释了原因，以及各建模软件的修复方法。
交付前衡量完整度
不需要 COBie 专家，也能判断模型是否在正轨上。从设计冻结开始，在每个阶段问三个问题，几乎就能发现所有问题：
- 组件：有多大比例同时具备名称和 GlobalId？一项资产需要可读的名称和稳定的 ID 才能交付。
- 空间：有多大比例已命名？未命名的空间，运营建筑的人根本找不到。
- 类型：组件到底有没有对应的类型？
我们的 COBie 提取功能正好回答这三个问题，并把它们合成一个运维就绪度指标——Components 权重最高，其次是 Spaces，再次是 Types——同时附上每张工作表的明细。它刻意被设计为完整度指标，而不是合规证书：它告诉你运维团队依赖的数据是否齐全，而且就用这样的措辞来说明。
编写模型能够满足的 COBie 要求
COBie 要求应写进 EIR，最好还写成供应商可以自行运行的 IDS 文件。“每个 IfcSpace 都有 Name 和 LongName”“每个 IfcDoorType 都带有 Manufacturer 和 ModelReference”——每一条都是一条 IDS 规范，都能在每个版本中检查，远早于有人打开电子表格的时候。
如何编写这些规范见 IDS 详解。COBie 在其他交付文件中的位置见 交付 IFC 模型时还应附带什么。
COBie 不是在交付时生成的，而是在交付时被揭示的——到那时，已经来不及改变它揭示的东西了。
从 IFC 生成 COBie：运维团队真正需要什么（以及交付前如何检查）