返回 BIM 与 IFC 博客
几乎每一份 EIR 里都有类似“所有门都应标注耐火等级”的句子。而在每个项目里，这句话的检查方式都一样：有人打开模型，点几扇门，然后认定“应该没问题”。要求是精确的，检查却全凭感觉。
IDS（Information Delivery Specification）就是为弥补这道缺口而生的。它是一种小巧的 XML 格式，由 buildingSMART 标准化为 IDS 1.0，用机器可以测试的方式表达信息要求。要求只写一次，把 .ids 文件交给每个供应商，“应该没问题”就变成了“418 扇门中 412 扇通过，这是没通过的 6 扇”。
要点
- IDS 检查的是信息，不是几何：类、属性、属性集、分类、材料和关系。
- 每条规范都分两半：适用于哪些构件，以及这些构件必须具备什么。大多数有问题的 IDS 文件错在前一半。
- IDS 是合同文件。它应与 BEP 放在一起、做好版本管理，并在建模开始前发给供应商，而不是在第一次退回之后。
一条规范的结构
一条 IDS 规范读起来就是一句话：对每个符合适用范围的构件，检查其是否满足要求。
IDS 文件是一组规范的列表。每条规范读起来都像一个有主语和谓语的句子：“对每个符合这个条件的构件，要求那个。”主语是适用范围，谓语是要求。
<specification name="Doors carry a fire rating" ifcVersion="IFC4">
<applicability minOccurs="1">
<entity><name><simpleValue>IFCDOOR</simpleValue></name></entity>
</applicability>
<requirements>
<property dataType="IFCLABEL">
<propertySet><simpleValue>Pset_DoorCommon</simpleValue></propertySet>
<baseName><simpleValue>FireRating</simpleValue></baseName>
</property>
</requirements>
</specification>
把它读出来，就是 EIR 里的那句话：每个 IfcDoor 都必须在 Pset_DoorCommon 中有 FireRating，并以 label 类型存储。适用范围上的 minOccurs="1" 还附加了一条容易被忽略的要求：模型中至少要有一扇门。没有它，一个完全没有门的模型也会通过——这很少是任何人的本意。
六种 facet，以及它们真正检查什么
| Facet | 检查内容 | 典型要求 | 常见陷阱 |
|---|
| Entity | IFC 类和预定义类型 | 墙是 IfcWall，而不是 IfcBuildingElementProxy | 忽略子类型：在 IFC2x3 中 IfcWallStandardCase 也是 IfcWall |
| Attribute | 直接 IFC 属性（Name、Description、Tag…） | 每个空间都有 Name 和 LongName | 空字符串是“存在但无效”，而不是“缺失” |
| Property | 属性集中的属性，带数据类型和值 | Pset_WallCommon.IsExternal 为 TRUE 或 FALSE | 值对了，数据类型错了（要求布尔值却给了 label） |
| Classification | 分类引用及其编码 | 每个构件都有 Uniclass Ss 编码 | 只检查编码，不检查它所属的分类体系 |
| Material | 关联的材料名称或类别 | 结构柱声明了材料 | 材料挂在类型上，而不是实例上 |
| PartOf | 与父级构件的关系 | 每个构件都包含在某个楼层中 | 把聚合关系和空间包含关系混为一谈 |
每种 facet 都可以出现在适用范围中（用于筛选构件），或出现在要求中（用于对构件提出要求）。其中两个陷阱值得多讲几句，因为第一次运行 IDS 时看到的误报，大多出自它们。
类型与实例
属性可能挂在类型上而不是实例上。IDS 检查工具必须沿类型查找，否则会误判正常构件不合格。
Revit、ArchiCAD 和 Tekla 经常把属性和材料写在类型对象（IfcWallType）上，而不是每一面墙上。IDS 的语义很明确：从类型继承的信息对实例同样有效。只看实例的检查工具，会让一个完全正常的模型里的每一面墙都不合格。如果 IDS 告诉你 100% 的构件都缺少一个你在属性面板里明明看得到的属性，原因几乎总是这个——错在检查工具，不在你。
USERDEFINED 预定义类型
当预定义类型为 USERDEFINED 时，真实类型保存在 ObjectType（实例上）或 ElementType（类型上）。一个要求 IFCWALL 且预定义类型为 PARAPET 的 entity facet，应该匹配 PredefinedType 为 USERDEFINED、ObjectType 为 PARAPET 的墙。只比较原始枚举值的检查工具会把它们全部漏掉。
让 IDS 失效的五个错误
- 适用范围过宽。“所有构件都必须有 Uniclass 编码”会把洞口、注释和没人去分类的空间构件也卷进来。把每条规范限定在要求真正针对的类上。
- 只写值、不写数据类型。FireRating = “EI 60”这个要求并没有说明应如何存储；同样的文字作为描述存在另一个 pset 里，照样不合格。把意思说完整，包括数据类型。
- 本该用模式却写死了精确值。真实数据里会有“EI60”“EI 60”和“EI-60”。使用 xs:pattern 或枚举，并在 BEP 中约定规范写法。
- 一条巨型规范。一条规范里塞四十个要求，每个构件只得到一个通过或不通过，报告没人能据此行动。一条规范一个要求，并用通俗语言命名，结果才可读。
- 先有模型、后写 IDS。随第一次退回发出的 IDS 是一条新要求；随委托发出的 IDS 才是要求。只有后者能被强制执行。
最后一点的合同层面——哪些条款让 IDS 具有约束力，交付不满足时会怎样——见 真正能防止糟糕 IFC 交付的 BEP 条款 和 IFC 验收标准。
逐步用 IDS 检查你的模型
- 打开 IFC 把模型拖进查看器。它在你的浏览器中解析，不会上传任何内容。
- 加载 .ids 文件 打开 IDS 面板并选择你的文件；如果想先了解格式，也可以从内置的示例规范开始。
- 运行检查 每条规范都会用全部六种 facet 进行评估。大模型会按阶段显示进度，并且可以随时取消。
- 按规范、构件或类阅读结果 按你打算修复的方式对问题分组。每个问题都用通俗语言说明原因：缺少属性、值错误、数据类型错误、类错误。
- 在 3D 中查看 “高亮”会在模型中给不合格构件着色；“隔离”会隐藏其他所有内容。两者都只需一次点击——一串 GlobalId 就这样变成了与建模人员的对话。
跨版本的 IDS
一次 IDS 运行只是一张快照。协调员真正需要的是趋势：第 7 版修复了第 6 版提出的问题吗？又引入了新问题吗？由于结果以 GlobalId 为键，同一条规范可以在模型的两个版本之间比较——前提是你的 GlobalId 在多次导出之间保持稳定。如果不稳定，先解决这个问题：为什么每次导出 IFC GUID 都会变。比较本身见 如何比较 IFC 模型的两个版本。
IDS 的边界
IDS 不检查几何。它不会告诉你两根风管发生碰撞、某扇门对轮椅来说太窄，或者模型离测量控制点有两公里远。它也不检查 IFC 在结构上是否健康——一个带有重复 GlobalId 或损坏定位的文件，完全可以顺利通过 IDS。
这不是缺陷，而是边界。用 IDS 检查信息要求，用模型检查工具检查结构和几何，并在交付时把两份报告并排提交。完整流程见 如何验证 IFC 文件。
IDS 详解：如何用 Information Delivery Specification 检查 IFC 模型
