返回 BIM 与 IFC 博客
- 3 — 相互独立的验证层级
- 44 — 模型质量规则
- 6 — IDS 分面（buildingSMART 1.0）
- 0 — 上传字节数（仅在浏览器内处理）
每一次关于 IFC 交付的讨论，最后都会撞上同一堵墙。结构工程师说文件通过了验证工具的检查；BIM 协调员发现一半属性集缺失，追问用的是哪个验证工具；业主的信息交换要求（EIR）里规定了 IDS 要求，却没人检查过；公共数据环境（CDE）拒收了上传的文件。三周后，所有人都搞不清“有效”到底是什么意思。
这种混乱可以理解：“验证”这个词涵盖了三种完全不同、却共用一个名字的操作。把它们理清楚，是 BIM 协调员能为项目做的影响最深远的事情之一。
三种完全不同的验证问题
不妨以建筑许可申请为例。审批人员会分别核查三件事：图纸是否清晰完整（文件完整性）、设计是否符合建筑规范（质量与合规），以及是否满足业主的具体设计任务书（项目要求）。图纸清晰，却可能完全无视消防规范；满足消防规范的方案，也可能完全漏掉业主的声学要求。这是几个不同的问题，答案也各不相同。
第 1 层：IFC 完整性
文件是否符合 ISO 10303-21 和 ISO 16739-1，是有效的 IFC？GlobalId 是否唯一且格式合规？空间层级是否连贯？这是模式层面的二元检查，只有通过或不通过。
第 2 层：模型质量
数据是否真正能用于协调？属性集是否已填写？构件是否遵循命名规范？分类编码是否齐全？真正决定交付成败的是这一层，而不是模式合规性。
第 3 层：IDS 验证
模型是否满足本项目合同约定的信息要求？EIR 和资产信息要求（AIR）被编码为机器可读的 IDS 规范，逐个分面地对每一个构件进行检查。
这三个层级完全相互独立。一个文件可以通过第 1 层模式验证，却因为没有导出任何属性集而对协调毫无用处。IDS 检查可以在所有声明的要求上全部通过，而模型里却有 400 个重复 GUID。Health Score（健康评分）达到 91，也无法说明业主的耐火等级要求是否已被编码并得到满足。每一层回答的是不同的问题，正式交付前三层缺一不可。
第 1 层：IFC 文件完整性——文件是有效的 IFC 吗？
第 1 层是模式检查，回答的是一个非此即彼的问题：该文件是否符合 IFC 模式（ISO 16739-1）和物理文件格式（ISO 10303-21 STEP）？大多数 IFC 解析器会默默接受未通过第 1 层检查的文件。它们在设计上就很宽容，因为严格拒收会让太多工作流程无法运转。这种宽容把损害掩盖起来，直到它在下游暴露出来。
第 1 层完整性检查涵盖哪些内容
- GlobalId 唯一性：每个 IfcRoot 实体都必须有一个唯一的、22 个字符的 GlobalId，并使用 IFC 的 base-64 字母表。重复的 GlobalId 属于模式违规，解析器虽然接受，却会悄无声息地破坏 BCF 工作流程、CDE 版本管理和设施管理（FM）资产台账。
- GlobalId 格式合规：有效 IFC GlobalId 的首字符只能编码 0–3 的值（对应 128 位 UUID 中的两个有效位）。简单粗暴地截断 UUID 的脚本会生成超出范围的首字符：按规范属于无效，大多数解析器可以容忍，严格的验证工具则会拒收。
- 空间层级完整性：IFC 模式规定了 IfcProject → IfcSite → IfcBuilding → IfcBuildingStorey 的层级。缺失节点（例如 Building 直接位于 Project 之下，或实体构件直接放在 IfcSite 中）属于模式违规，会在下游造成实实在在的后果。
- IfcRelAggregates 关系链的完整性：构建空间树的关系实体必须引用实际存在的实体。悬空引用（关系指向已删除或缺失的实体）会让所有下游工具都无法正常浏览这棵树。
- IfcRelContainedInSpatialStructure：实体构件必须包含在某个空间结构元素中（通常是 IfcBuildingStorey）。没有包含关系的构件就是孤立构件，在大多数工具的空间导航中都看不到。
- 有且仅有一个 IfcProject：每个有效的 IFC 文件都必须恰好包含一个 IfcProject 作为层级的根节点。省略了它的子模型解析时不会报错，但没有空间锚点。
- FILE_NAME 和 FILE_DESCRIPTION 文件头字段：STEP 文件头承载着可追溯性元数据。ISO 19650-2 要求填写这些字段，而大多数工具都把它们留成空字符串。
- 几何有效性：非流形网格、面积为零的面、法线绕向反转的几何体，以及在接收方工具中无法生成有效实体的自相交边界表示（B-rep）。
第 1 层不检查什么
- 属性集是否已填写、是否正确：一个没有任何 Pset 的模型，只要符合模式，就能通过第 1 层。
- 构件名称是否遵循项目的命名规范。
- 分类编码是否存在、是否正确、是否一致。
- 是否满足 LOD 的工程量要求（LOD 300 及以上的 IfcElementQuantity）。
- 模型是否满足任何项目特定或合同约定的信息要求。
用 buildingSMART Validation Service 做第 1 层检查
buildingSMART IFC Validation Service（validate.buildingsmart.org）是第 1 层模式合规性的权威参考，它使用的正是 IFC 软件认证所部署的引擎。以下情况应当使用它：你需要为自定义导出器的 IFC 输出做认证；你在排查一个不同解析器处理结果不一致的文件；或者合同条款明确要求提供 buildingSMART 模式合规证书。
它不做的事：检查数据质量、验证命名规范、检查属性集是否完整、检查 ISO 19650 元数据字段，或评估模型是否满足任何项目要求。它是一个模式工具，而不是项目交付关口。
查看一个复杂的真实 IFC：三个验证层级一次看全
一栋从 Revit 导出的多层办公楼。打开“验证”选项卡，查看完整的 44 条规则质量报告和 Health Score。然后试着加载一份 IDS 规范，看看同一个模型上的第 3 层检查。
IFC4 · 14 MB
打开交互式 IFC 查看器
第 2 层：模型质量检查——真正决定交付成败的一层
大多数 BIM 协调员说“IFC 验证”时，指的其实就是模型质量检查，尽管他们很少这样称呼它。它回答的是实际问题：数据在不在？对不对？是否一致？下游的人能否真正用这个模型来做协调、成本规划或设施管理？
与第 1 层不同，质量检查不是非此即彼的。模型不是简单地通过或不通过，而是在几十个维度上呈现出一个质量画像。Health Score（0–100）把这些维度汇总成一个数字，可以写进 BIM 执行计划（BEP），在各版本之间持续跟踪，并随文件传递单一起提交，作为交付质量的证据。
44 条规则的质量检查涵盖哪些内容
核心结构规则（18 条）
重复 GUID、孤立构件、包含关系错误、聚合关系断裂、缺少 IfcProject、构件名称为空、楼层放置无效。在实践中，正是这些规则导致了最多的 CDE 拒收。
空间与文件头（11 条）
IfcProject 上的 ISO 19650 元数据字段、FILE_NAME 中作者和组织的填写情况、场地放置与共享坐标是否一致、构件与楼层的关联、建筑楼层的完整性。
LOD、分类编码与机电（9 条）
LOD 300 及以上时是否存在 IfcElementQuantity、结构和建筑构件上的 IfcRelAssociatesClassification、机电（MEP）系统连通性、代理构件滥用（IfcBuildingElementProxy 在模型中的占比）。
几何与楼层完整性（6 条）
构件包围盒有效性、楼层标高顺序、位于地坪以下的构件、楼层中缺少楼板、坐标原点相对世界坐标系（WCS）的偏移、碰撞检查（可选规则，默认关闭）。
Health Score：用一个数字表达模型质量
Health Score 采用对数扣分权重。模式错误的权重是警告的 3 倍，警告的权重又是提示级检查的 3 倍。同一问题第 1,000 次出现所扣的分，远少于第 10 次。这样一来，在底层问题密度相同的情况下，大而密集的模型不会无端显得比小而稀疏的模型更差。一个有 800 条命名警告的模型可以得 83 分；一个有 12 处空间引用断裂的模型只有 41 分。决定分数的是严重程度，而不是数量。
- 31/100 — 严重：存在结构性缺陷，不得交付
- 58/100 — 较差：需要大量整改
- 74/100 — 一般：仅可用于内部评审
- 87/100 — 良好：可交付至 CDE
- 96/100 — 优秀：达到 ISO 19650 里程碑质量
模型质量检查不做什么
- 验证项目特定的信息要求：那是第 3 层（IDS）的事。质量规则是通用的最佳实践检查，不是你的 EIR。
- 修复模型：质量检查产出的是报告。整改要在建模软件中完成；如果是属性和 GUID 类问题，也可以在 IFC 属性编辑器中修复。
- 提供 buildingSMART 认证计划要求的模式合规证书：那属于第 1 层，要通过 buildingSMART Validation Service 获得。
- 告诉你模型在几何上是否正确：其中虽然包含一些几何完整性检查，但质量检查工具既不是碰撞检查工具，也不是 BIM 建模软件。
第 3 层：IDS 验证——把交换要求变成机器可读的代码
IDS（Information Delivery Specification，信息交付规范）是 buildingSMART 的一项标准，用机器可读的 XML 格式对项目特定的信息要求进行编码。EIR 本身是一份 Word 文档，IDS 正是它与验证引擎之间缺失的那一环，让引擎能够系统地对照 EIR 检查模型。IDS 1.0 于 2023 年成为 buildingSMART 正式标准。
buildingSMART IDS 究竟是什么
IDS 文件是一个 XML 文档，包含一条或多条规范（specification）。每条规范都有适用范围（applicability）部分，说明适用于哪些构件；以及要求（requirements）部分，说明这些构件必须具备什么。引擎会检查模型中所有符合适用范围的构件，核实其是否满足全部要求，并按构件、按规范报告通过或不通过。最终得到的，是一份由机器生成的合同合规审计记录。
buildingSMART 参考测试套件包含 100 个官方测试用例，定义了任何合规的 IDS 引擎应有的行为，它们就是以可运行形式存在的规范。通过全部 100 个测试用例的 IDS 引擎，已经证明它对 .ids 规范的解读与标准一致。
IDS 的六个分面
- Entity：按 IFC 实体类型（IFCWALL、IFCDOOR、IFCBEAM）以及可选的预定义类型，限定适用范围或要求。大多数规范都从这个筛选条件开始。
- Attribute：检查直接位于实体上的 IFC 直接属性（attribute）值，例如 Name、Description、ObjectType、Tag、PredefinedType。直接属性不同于属性集，检查方式也不同。
- Property：检查指定属性集中的指定属性（Pset_WallCommon.FireRating、Pset_DoorCommon.IsExternal）。这是最常用的分面，支持对属性值进行数据类型约束和正则表达式匹配。
- Classification：检查构件是否通过 IfcRelAssociatesClassification 带有分类引用，例如 Uniclass 2015、OmniClass、NBS 或自定义体系。可以约束分类体系的名称和编码格式。
- Material：检查构件是否通过 IfcMaterial、IfcMaterialLayerSet 或 IfcMaterialConstituentSet 指定了材料。还可以约束材料名称，适用于耐火或可持续性方面的要求。
- PartOf：检查构件是否处于规定的空间或逻辑关系中，例如包含在某个楼层中、聚合到某个建筑系统中，或位于某栋特定建筑内。要针对特定构件类型强制执行空间层级合规，靠的就是这个分面。
<?xml version="1.0" encoding="UTF-8"?>
<ids:ids xmlns:ids="http://standards.buildingsmart.org/IDS"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://standards.buildingsmart.org/IDS ids_09.xsd">
<ids:info>
<ids:title>Stage 3 Architecture — EIR Data Requirements</ids:title>
<ids:description>Fire safety and classification requirements.</ids:description>
<ids:ifcVersion>IFC4</ids:ifcVersion>
</ids:info>
<ids:specifications>
<!-- All walls must carry a fire rating property -->
<ids:specification name="Wall FireRating required" minOccurs="1">
<ids:applicability>
<ids:entity>
<ids:name><ids:simpleValue>IFCWALL</ids:simpleValue></ids:name>
</ids:entity>
</ids:applicability>
<ids:requirements>
<ids:property dataType="IFCLABEL">
<ids:propertySet><ids:simpleValue>Pset_WallCommon</ids:simpleValue></ids:propertySet>
<ids:baseName><ids:simpleValue>FireRating</ids:simpleValue></ids:baseName>
</ids:property>
</ids:requirements>
</ids:specification>
<!-- Structural walls must carry a Uniclass 2015 classification -->
<ids:specification name="Structural wall classification" minOccurs="0">
<ids:applicability>
<ids:entity>
<ids:name><ids:simpleValue>IFCWALL</ids:simpleValue></ids:name>
<ids:predefinedType><ids:simpleValue>SOLIDWALL</ids:simpleValue></ids:predefinedType>
</ids:entity>
</ids:applicability>
<ids:requirements>
<ids:classification>
<ids:system><ids:simpleValue>Uniclass 2015</ids:simpleValue></ids:system>
</ids:classification>
</ids:requirements>
</ids:specification>
</ids:specifications>
</ids:ids>
从 EIR 到 IDS：大多数团队跳过的转换步骤
EIR 规定业主需要哪些信息；IDS 把这些要求编码，让机器可以检查。两者之间的转换几乎没人去做，因为这需要一个既懂信息要求、又足够熟悉 IDS XML 模式的人，写出的规范要恰好测试 EIR 所要求的内容，不多也不少。
后果是：团队要么完全跳过 IDS，在交付时依靠非正式的人工审查；要么使用一份并不反映实际 EIR 的通用 IDS 文件。两种做法都会带来虚假的信心。对照通用规范通过的 IDS 检查，完全无法说明你的业主的具体要求是否得到满足。
基于模板的 IDS：务实的起点
并不是每个团队都要从零开始编写 IDS。一个务实的做法是维护一个可复用的 IDS 模板（profile）库：一个用于第 3 阶段的建筑专业，一个用于第 4 阶段的机电专业，一个用于结构移交。每个模板覆盖该阶段、该专业最常见的要求，再按项目补充业主的特定要求。IDS 模板可以直接加载到验证引擎中组合使用：你可以对同一个模型运行多个 .ids 文件，并汇总结果。
三个层级如何协同工作：验证流水线
三个层级构成一道质量关口，模型要按顺序依次通过。每一层的执行频率不同：第 1 层在每次导出时运行（健全性检查），第 2 层在每次上传 CDE 之前运行（质量关口），第 3 层在正式交付里程碑之前运行（合同检查）。打乱顺序只会浪费时间：对一个空间层级已经断裂的文件运行 IDS，没有任何意义。
┌──────────────────────────────────────────────────────┐
│ EXPORT IFC from authoring tool │
│ (Revit, ArchiCAD, Tekla, Allplan, Vectorworks…) │
└───────────────────────┬──────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────┐
│ LEVEL 1 — IFC Integrity │
│ • GlobalId uniqueness & format (leading char 0–3) │
│ • Spatial hierarchy: Project→Site→Building→Storey │
│ • IfcRelAggregates chain integrity │
│ • IfcRelContainedInSpatialStructure (no orphans) │
│ • Exactly one IfcProject │
│ • FILE_NAME header traceability fields │
└─────────┬────────────────────────────────────────────┘
Fail ◄────┤ Fix in authoring tool (or IFC property editor)
│ Pass
▼
┌──────────────────────────────────────────────────────┐
│ LEVEL 2 — Model Quality (44 rules) │
│ • Naming conventions / empty element names │
│ • Property set completeness (Pset_WallCommon etc.) │
│ • ISO 19650 metadata (IfcProject.LongName etc.) │
│ • Classification presence and consistency │
│ • LOD quantity sets, proxy audit, MEP connectivity │
│ → Health Score 0–100 │
└─────────┬────────────────────────────────────────────┘
Score<80 ◄┤ Fix properties / names in IFC editor or authoring tool
│ Score ≥ 80
▼
┌──────────────────────────────────────────────────────┐
│ LEVEL 3 — IDS Validation │
│ • Project-specific EIR / AIR requirements │
│ • .ids specification(s) for this milestone │
│ • Six facets: entity, attribute, property, │
│ classification, material, partOf │
└─────────┬────────────────────────────────────────────┘
Fail ◄────┤ Fix per IDS issue report → export BCF → remediate
│ All requirements met
▼
┌──────────────────────────────────────────────────────┐
│ DELIVER TO CDE │
│ Attach: Health Score report + IDS pass certificate │
└──────────────────────────────────────────────────────┘
对比表：第 1 层、第 2 层与第 3 层
| 维度 | L1：IFC 完整性 | L2：模型质量 | L3：IDS 验证 |
|---|
| 回答的问题 | 文件是否符合 IFC 模式？ | 数据能否用于协调？ | 是否满足项目信息要求？ |
| 依据标准 | ISO 10303-21（STEP）、ISO 16739-1（IFC） | BIM 最佳实践、ISO 19650 规范 | buildingSMART IDS 1.0（XML 模式） |
| 由谁定义 | buildingSMART（固定模式） | BIM 团队 / EIR（项目商定的规则） | 业主 / 委托方（按项目） |
| 输出结果 | 通过 / 不通过 + 模式错误清单 | Health Score 0–100 + 按优先级排列的问题清单 | 每条规范的通过 / 不通过 |
| 能否替代其他层？ | 否 | 否 | 否，三者缺一不可 |
| 执行频率 | 每次 IFC 导出 | 上传 CDE 之前 | 交付里程碑之前 |
| 本层通过、他层不通过的例子 | 没有 Pset、没有名称 → L1 通过，L2 不通过 | 缺少耐火等级（IDS 规范要求）→ L3 不通过 | 重复 GUID、层级断裂 |
| 工具示例 | bSmart Validator、IFC Viewer Online | IFC Viewer Online、Solibri、IfcOpenShell | IFC Viewer Online（IDS 引擎）、Solibri |
何时使用 buildingSMART Validation Service：客观评估
buildingSMART IFC Validation Service 使用一套由多个部分组成的引擎，对照官方模式检查文件：STEP 物理文件语法、IFC 模式的 EXPRESS 规则、从规范中推导出的非正式命题（informal proposition）规则，以及规范性的 IFC 约束规则。它是第 1 层模式合规性的参考工具。
适用情况
- 为自定义导出器的 IFC 输出做认证：buildingSMART 检查工具产出的是软件认证所用的参考结果。在认证场景中，其他任何工具的输出都无法替代它。
- 诊断解析器之间的不一致：当一个文件在某个工具中能正常打开、在另一个工具中却报错时，buildingSMART 检查工具可以判定哪种行为符合模式。即使文件在其他方面可用，这在诊断上也很有价值。
- 合同条款有要求：有些采购规范把 buildingSMART 模式合规列为交付要求。这时，能满足该条款的就是官方服务出具的证书。
- 验证 IDS 文件本身：buildingSMART 的 IDS 模式验证器检查的是你的 .ids 文件是否为有效的 IDS 文档，这与拿它去检查模型是两回事。
不要用它来替代
- 模型质量检查：该服务不检查属性集完整性、命名规范、分类编码或任何数据质量规则。
- 项目特定的验证：模式合规完全无法说明模型是否满足业主的 EIR。
- 上传 CDE 前的交付确认：一个属性集为空、名称空白但符合模式的模型，能通过 buildingSMART 检查工具，却过不了任何有意义的质量关口。
云端 IFC 验证工具与浏览器端 IFC 验证工具
云端验证（文件上传到远程服务器）与浏览器端验证（文件通过 WebAssembly 在本地处理）之间的区别，比大多数团队意识到的更重要，对政府、国防和敏感的商业项目尤其如此。
浏览器端验证
- IFC 文件从不离开设备
- 从设计上符合 GDPR：没有数据传输
- 可离线使用：现场踏勘、受限网络
- 没有上传配额或文件大小限制
- 即时反馈，没有网络往返延迟
- 性能稳定，不受服务器负载影响
- 无需账号、API 密钥或订阅
- 可在政府受限网络环境中使用
云端验证
- 文件上传到远程服务器进行处理
- 需签订数据处理协议（DPA）才能符合 GDPR
- 适合自动化的 CI/CD 验证流水线
- 跨项目、跨团队的集中审计日志
- 通过 API 和 Webhook 集成，实现交付自动化
- 可横向扩展，批量处理模型
- 无需浏览器会话，可无界面运行
- 可跨历史运行记录查询结果
何时适合用云端验证
- 自动化 CI/CD 流水线：每次提交或上传模型都应自动触发验证时，就像软件团队在每次推送代码时运行自动化测试一样。这种场景下，带 Webhook 的云端 API 才是正确的架构。
- 全组织范围的审计：BIM 经理需要集中记录多个项目、多个团队的验证运行情况时。云服务可以跨运行记录汇总数据、分析趋势，这是单机工具做不到的。
- 批量处理：审计一整批已有模型（比如过去两年交付到 CDE 的所有 IFC 文件），在云端批处理模式下切实可行，而在浏览器中手动完成则不现实。
- 非敏感模型：对于数据处理要求并不禁止云端上传的项目，云端验证工具提供的 CI/CD 集成是浏览器工具比不上的。
何时浏览器端是更好的选择
- 政府和国防项目：公共基础设施、国防设施和安全资产的模型，通常都带有禁止上传到第三方服务的数据处理限制。浏览器端验证是唯一合规的选择。
- 敏感的住宅和商业项目：BIM 模型中常常包含住户信息、业主地址，以及根据 GDPR 第 4 条属于个人数据的资产元数据。在没有有效 DPA 和合法依据的情况下，在第三方服务器上处理这些数据是不合规的。
- 现场使用：一个 200 MB 的 IFC 文件通过 4G 网络上传，既慢又不稳定。浏览器端验证在本地几秒钟就能处理完，完全不依赖上行带宽。
- 云端上传前的预验证：即使团队把云端验证工具作为正式关口，先在浏览器端检查一遍，也能在不上传的情况下发现明显问题，从而降低云端使用成本和上传频率。
BIM 团队常犯的六个验证错误，以及它们的真正含义
错误 1：“IDS 通过了，模型没问题”
IDS 只验证 .ids 规范中声明的内容。如果你的文件要求墙体具有 FireRating，而 EIR 还要求门具有 IsExternal、结构构件带有 Uniclass 编码、楼板具有工程量集，这些却都没有写进规范，那么引擎会报告所有要求均已满足，而你的 EIR 有一半根本没被检查。IDS 通过，是针对某一份特定规范的合同层面确认，而不是一份通用的质量证书。
错误 2：“buildingSMART 检查工具说它有效”
模式有效只是底线，而不是上限。一个所有构件都是 Name='' 且没有任何属性集的文件，完全符合模式。一个没有 IfcElementQuantity、没有分类编码、所有实体构件都直接放在 IfcSite 而不是楼层中的模型，同样完全符合模式。通过 buildingSMART 检查工具，只说明 STEP 文件格式正确，完全不能说明数据是否有用。
错误 3：“能在查看器里打开，就没问题”
IFC 查看器在设计上就很宽容：无论数据质量如何，它们都要能显示几何。一个拒绝打开模式无效或数据贫乏文件的查看器，根本没法用。几何显示正确，并不能说明属性集是否完整，也不能说明命名规范、GUID 稳定性、分类编码，或 44 个质量维度中任何一项的情况。查看文件与验证文件，是性质完全不同的两件事。
错误 4：只检查几何，忽略属性数据
一种常见的条件反射是：打开 IFC，看一眼三维模型，只要建筑看起来没问题，就宣布文件完成了。几何只占 IFC 文件价值的大约 30%。设施管理系统、造价管理人员和 CDE 资产台账真正使用的，是属性集、分类编码、构件名称、类型指定和工程量集。几何正确但属性集空白的文件，过不了移交这一关。
错误 5：只在交付截止时验证一次
把验证当作提交 CDE 前的最后一步，意味着要在毫无缓冲的压力下整改问题。一个在截止前一天才发现 800 个验证问题的模型，要么带着已知问题交付，要么错过截止日期。正确的节奏是：每次导出后做第 1 层，每次内部评审前做第 2 层（至少每周一次），每个正式里程碑前两周做第 3 层。
错误 6：忽视重复导出之间的 GUID 稳定性
文件内的重复 GUID 属于第 1 层问题，任何验证工具都能检测到。但重复导出之间的 GUID 不稳定（同一个构件每次导出都得到不同的 GlobalId），在单文件验证中是看不出来的。当 GlobalId 在版本之间漂移时，每一条 BCF 批注、每一个 CDE 构件引用和每一个 FM 资产标签，都会悄无声息地变成悬空引用。这需要对比两个版本并检查导出设置，而不能只靠单文件验证。
BIM 协调员的实用验证工作流程
- 每次 IFC 导出后：运行第 1 层检查。在任何浏览器端验证工具中都用不了 30 秒。趁 GlobalId 重复、孤立构件和空间层级断裂还没有随版本累积，就把它们修复掉。
- 每次内部评审前（每周或每个迭代周期）：运行完整的第 2 层质量检查，查看 Health Score 的变化趋势。分数随版本下降，说明有新问题被引入；要在它变成常态之前找到源头。
- 收到第三方的任何专业模型时：在整合之前先运行第 1 层和第 2 层。你收到的模型可能带有问题，一旦进入协调模型，这些问题就由你继承了。要立即发现它们，而不是在有问题的整合模型上协调了三周之后才发现。
- 任何正式里程碑交付前两周：运行全部三个层级。做 IDS 检查之前，Health Score 的目标是 ≥ 80。两周时间足以从容整改。有问题尽早提出，不要把缓冲时间耗掉。
- 上传到 CDE 之前：运行第 2 层和第 3 层，把 Health Score 证书和 IDS 通过报告附在文件传递单中。这样就形成了一份有据可查的审计记录，信息经理接收交付所需的一切也都齐了。
- 建模软件升级版本或修改导出设置之后：对比连续两次导出，重新建立 GUID 稳定性基线。Revit 升级或导出配置变更，都可能悄无声息地改变 GlobalId 的生成方式。
专家建议
按扣分排优先级，而不是按数量
不要按问题数量的多少来修复，而要按对 Health Score 的影响来修复。缺少 3 个 IfcProject 元数据字段可能扣掉 15 分，而 800 条命名警告总共可能只扣 8 分。利用严重程度分布，按影响大小排定优先级。
把导出设置锁定在模板中
每次手动重新配置导出设置，都有偏离到另一套配置的风险。在建模软件中创建一个命名的 IFC 导出设置，把它纳入项目样板，并在 BEP 中写明所需的设置。配置漂移，是大多数“上次还好好的”导出问题的根源。
项目一开始就把 EIR 转换为 IDS
在项目的头两周，把最关键的 EIR 条款转换成 IDS 规范。哪怕只是一份不完整的 .ids 文件（五六条规范），也比在交付时对 EIR 做全面的人工审查要好，而且能及早发现系统性的数据缺口，那时修复成本还很低。
整合前先验证每个专业模型
在整合模型中，一个专业模型的问题可能掩盖另一个专业模型的问题，或与之相互影响。输入干净，整合才干净。只在整合后的协调模型上做验证，会更难把问题分派给正确的责任方。
常见问题
通过第 1 层，是否就可以跳过第 2 层？
不可以。第 1 层和第 2 层衡量的是文件完全不同的特性。一个符合模式的文件（第 1 层）可能没有任何属性集、构件名称为空、没有分类编码、也没有 ISO 19650 元数据，在质量检查（第 2 层）中只能得 20 分。两者缺一不可。可以把第 1 层理解为“包裹打包正确”，把第 2 层理解为“包裹里装的正是所要求的东西”。
IDS 能取代 buildingSMART Validation Service 吗？
不能。IDS 检查的是项目特定的信息要求（第 3 层），buildingSMART Validation Service 检查的是模式合规性（第 1 层）。两者处于完全不同的层级，解决的也是不同的问题。一个通过 IDS 却未通过模式验证的模型，在逻辑上是自相矛盾的：第 1 层的完整性，是第 3 层检查有意义的前提。
对于常规 BIM 交付，应优先使用哪些 IDS 分面？
Property 分面覆盖了实际 EIR 要求中的 70–80%，因为大多数业主都要求在特定构件类型上填写特定的属性集值。对于采用 Uniclass 或 OmniClass 的项目，Classification 分面基本覆盖了其余部分。Entity 分面几乎出现在每一条规范中，用作适用范围筛选。Material 和 PartOf 则用于满足特定的合同要求。建议从 Entity + Property 起步，如果 EIR 有要求再加上 Classification，然后逐步扩展。
能否不上传到任何地方就验证 IFC？
可以。基于浏览器的验证工具借助 WebAssembly，完全在你的浏览器中处理文件。IFC 文件的字节从不离开你的设备：全部 44 条质量规则、Health Score 计算和完整的 IDS 引擎都在客户端运行。对于有数据处理限制的模型，例如政府资产、敏感的住宅数据、国防基础设施，这往往是唯一合规的选择。
BEP 中应规定多高的 Health Score 阈值？
≥ 80 是 CDE 交付和设计协调的标准阈值；LOD 300 及以上的扩初设计交付和 ISO 19650 正式里程碑提交要求 ≥ 90；概念阶段的内部评审可以接受 ≥ 70。低于 60，说明模型存在根本性的质量问题，在任何情况下都不应交付给任何外部单位。
一款工具能否覆盖全部三个验证层级？
有些工具可以。IFC Viewer Online 覆盖第 1 层（完整性规则，包括 GUID、层级和文件头检查）、第 2 层（含 Health Score 的 44 条规则质量检查）和第 3 层（IDS 1.0 引擎，已通过 bSI 全部 100 个官方测试用例的验证）。Solibri 覆盖第 2 层和第 3 层，规则引擎更成熟，但不支持在浏览器中处理。buildingSMART Validation Service 只覆盖第 1 层。IfcOpenShell 可以通过编写脚本实现第 1 层和第 2 层检查。
总结
符合模式，不等于满足项目要求；满足项目要求，也不等于符合 EIR。三个验证层级缺一不可，而把它们混为一谈，正是大多数正式交付失败的根源。
IFC Viewer 博客
第 1 层：每次导出都运行
模式完整性、GlobalId 唯一性与格式、空间层级。只需 30 秒，就能发现那些会在下游悄悄破坏 BCF、CDE 版本管理和 FM 资产台账的结构性问题。
第 2 层：为每次 CDE 交付把关
44 条质量规则、Health Score、命名规范、属性集完整性、ISO 19650 元数据。在 BEP 和 EIR 中要求 ≥ 80。正是这一层让模型真正有用，而不只是能被解析。
第 3 层：每个里程碑前核实
IDS 规范以机器可读的形式编码你的 EIR 和 AIR。在项目开始时就转换关键条款，而不是等到交付前一周。IDS 通过，就是一份有据可查的合同审计记录。
现在就对你当前的模型做一次完整的质量检查：在任何浏览器中都用不了 30 秒，也不上传任何内容。然后阅读 IFC Health Score 指南，了解分数是如何计算的，以及在 BEP 中应设置什么阈值。如果收到的文件需要修正属性值或 GUID，免费在线 IFC 编辑器指南介绍了如何以非破坏性的方式编辑属性，而无需再回到建模软件中走一遍。至于导致第 1 层拒收的最常见结构性问题，请参阅 7 个最常见的 IFC 验证错误。
IFC 模型检查完全指南：IFC 验证、模型质量与 IDS
