标准导读｜ISO 29481-1:2025 建筑信息模型 信息交付手册 第 1 部分：方法与格式

前面几期讲过，早期针对 BIM 的技术体系，给出了三个支点：IFD、IFC、IDM。今天讲讲 IDM。IDM 即信息交付手册（information delivery manual），是关于业务流程中信息传递的标准。

注：之所以说早期，是后来有了 ISO 19650 系列，负责信息管理方面，形成了四个支点。

现在假设一座轨道交通车站即将移交运营。建设单位提供了机电模型和一批设备说明书，运维单位却仍然会感到困惑：哪份说明书对应哪台风机？设备的保养周期从哪一天算起？发现资料有误后，由谁补正、何时再交？这也就是说，文件已经“交付”，信息却不能融入业务过程。这揭示了一个常见问题，交付物的组成、形式、使用目的和责任关系，不能只靠“提交 BIM 模型”一句话来约定。那么问题来了：能否把需求用“说明文”的形式，以自然语言规范化地表述出来？

ISO 29481-1:2025《建筑信息模型　信息交付手册　第 1 部分：方法与格式》（Building information models — Information delivery manual — Part 1: Methodology and format）给出了编制方法，指导各方如何把一个用例所需的信息说清楚。2025 年第三版的范围明确覆盖建筑和基础设施资产的全生命周期。标准还强调，IDM 可以用于任何触发信息管理活动的事件，包括合同以外的业务，例如合规审查。

注：有用的小知识，按相关规定，文件名称由引导元素、主体元素和补充元素组成，自一般到特殊排列：引导元素表示文件所属的领域，主体元素表示该领域内的标准化对象，补充元素表示对象的特定方面，或区分系列中的各个部分。“Building information models”是引导元素，“Information delivery manual”是主体元素，“Part 1: Methodology and format”是补充元素。值得注意的是，引导元素用的是 models，而不是 modelling，这意味着这一系列标准所属的领域是信息模型本身，也就是交付出去的结果。

注：一个有趣且无用的小知识，在上一版（2016）的 ISO 29481-1 中，information delivery manual（IDM）的术语注释写明，它也可称为 information delivery specification（IDS）。后来 buildingSMART 国际“挪用”了 IDS 这个术语，形成了新的“信息交付规范”，后迅速被全球所接受（这就是 buildingSMART 的影响力）。今天，IDM 与 IDS 具有不同含义，其适用的目标和范围，以及技术方式均有一定区别，但可以联合使用，见本文后面的示例。

标准档案

一、从用例推导交换要求

IDM 概括为三个组件：用例（use case）、业务情境（business context）和交换要求（exchange requirement，ER）。用例说明信息为何而用（目的）；业务情境确定哪些角色（role）在什么活动或互动中产生、使用、传递信息（过程）；交换要求则把需要交出的信息具体化（要求）。其价值在于，让要求清单中的每一项都有可追溯的用途，脱离无目的的罗列，避免漏掉真正需要的内容以及要求生产方填写无人使用的数据。

IDM 需能够明确表述出至少以下要素：

• IDM 所针对的用例的描述；
• 对业务情境中信息交换需求的描述；
• 信息交换的参与者（actor）的身份；
• 对活动或交互的定义和描述，在这些活动或交互中，参与者之间为提供服务或生产最终产品而创建、使用或交换信息；
• 能够被理解的定义、规范（specification）和描述（注：使用各参与者都能识别的语言和语义）；
• 交换要求的详细规范，包括对结构化信息容器中相关对象的识别。

IDM 要可辨识、可修订和可复用。这就要求 IDM 各组件具备共同的管理信息，包括完整名称、简称、全局唯一标识（GUID），以及作者和变更记录，还需给出用例目的、范围、用途、地区背景和相关项目阶段。复用一份 IDM 时，编制者要靠这些信息判断它针对哪类资产、“移交”对应的是什么地区、哪个工作阶段、新增字段由谁提出。版本和适用边界不清，再详细的清单也会被用错场景。

以移交通风设备中的通风机为例，用例可以写成“运营单位接收通风设备并建立预防性维护计划”。边界限于设备移交和首次维护计划，不涉及全部机电系统的设计审查。IDM 以角色描述参与方，如移交资料的承包方、核对设备的运营方。按标准第 3.1.2 条，角色是参与者（个人、组织或组织单元）在某一时点承担的职能，由所做的事和产出决定，不一定对应职业或工种。图 1 以这一示例展示三个组成部分的推导关系。

图 1　通风机移交示例：从用例到交换要求。

查看图 1 大图

业务情境不能只写“承包方交给运营方”，还要找出触发交换的过程活动与时点。标准推荐两种业务情境图式：过程图（process map）侧重活动的先后、承担活动的角色以及活动所需的输入；交互图（interaction map）侧重角色之间的事务，每个事务都有发起方和执行方，交互框架的计算机可解释格式由第 2 部分规定。复杂场景可以逐层展开，不必把所有细节塞进一张图。

注：标准推荐过程图采用 business process modelling notation (BPMN) 的方法绘制，具体规定见 ISO/IEC 19510。BPMN 是一种被广泛采纳的标准化的泳道式流程图示意方法，且计算机可读。

注：交互图采用 design and engineering method for organisations (DEMO) 的方法绘制。撰写本文时，发现 ISO 29481-1:2025 中提供的参考链接已经失效，具体信息请见 Enterprise Engineering Institute 的教育出版物页面。DEMO 是基于荷兰 Jan Dietz 教授等创立的企业本体论（Enterprise Ontology）提出的方法，这里中文“企业”是行业通用翻译，但是并不准确，英文原意还涵盖事业单位、政府组织等。该理论强调人与人之间通过承诺、委派与沟通协调（Speech Acts）来实现业务目的。荷兰很推介这套方法，编制了 ISO 29481-2（多么典型的“标准走出去”）。我本人虽然参编了 ISO 29481-1/2，但是对于这种小众理论和方法形成国际标准，仍然存有一定的疑虑。这里多说一点是为了将来介绍第 2 部分做一点铺垫。

例如，过程图可以把“承包方整理风机资料→运营方核对设备标识→运营方生成维护计划”排成活动序列。核对活动若需要先取得安装位置和设备编号，图上就出现一个明确的信息输入点，在一方的活动需要另一方输入之处识别为信息交换。交互图则把同一件事看作一个事务，用消息（message）作为信息沟通单元。运营方作为发起方请求移交维护资料，承包方作为执行方提交；资料缺项时运营方不予接受，承包方补正后再次提交。仅画第一张图，容易忽略退回后的责任；仅画第二张图，又可能看不出运营方为何需要保养周期。标准因此将两种图视为互补，允许结合使用。

沿着运营方“建立维护计划”这项活动反推，交换要求便不能停留在“提供设备资料”。至少要辨明设备标识、安装位置、型号、保养周期，以及说明书与设备的对应关系等。完整的信息单元（information unit）清单见后文的 IDM 示例。

信息单元在标准中定义为对一项信息的描述，交换要求就是实现用例所需的一组信息单元。按需要为信息单元补充信息约束（information constraint），可以说明数据类型、使用规则和核验条件。比如只写“保养周期：6”，接收方无法判断是 6 个月、6 周，还是投运后第 6 次检查。在本例中，可以约定周期的计量单位与起算条件、安装位置采用的空间标识，以及说明书与设备的关联方式。约束的细化程度取决于接收方如何核对和使用这些信息。

信息单元小至对象的属性，大至整个信息容器（information container，即可在文件、系统或应用的存储层级中检索的具名持久信息集合），例如招标邀请或资产模型。编制通风机移交要求时，可以先把“每台风机的维护资料”作为一组，再拆分设备标识、位置、说明书和周期。拆分到什么程度，取决于接收方要如何查找与核对。例如“说明书已提交”只能证明存在文件，不能证明文件与这台风机的型号和版本相符，需要补上关联规则才可能进行有效检查。

拆分的粒度还可以借助信息需求等级（level of information need）来约定。信息需求等级在 ISO 7817 系列标准中给出了详细规定，该术语被定义为界定信息范围与粒度的框架，以几何信息、文字信息和文档三类内容描述。本例中，几何信息或许只需定位和外形尺寸，文字信息包括型号和保养周期，文档则是对应版本的说明书。信息为何而用、何时交付、由谁提供与接收、针对哪些对象，是确定信息需求等级的前提，但信息需求等级本身不规定这些前提。

注：信息容器和信息需求等级都是 ISO 19650 系列标准提出的术语。

二、两种“交换要求”不要混用

ISO 29481-1 的交换要求（ER）与 ISO 19650 系列的交换信息要求（exchange information requirement，EIR）名称相近，所处层次却不同。IDM 中的 ER 以通用的参与者类型描述所需信息，例如“资产运营方在接收设备时需要承包方提供哪些资料”；ISO 19650 中的 EIR 针对某一次具体委托，例如某车站项目的建设单位向 BIM 咨询团队提出的交付要求。因此，一项 EIR 可能对应多项 ER。信息需求等级对两者都适用，ISO 29481-1 也将委托方把 IDM 全部或部分纳入合约列为一种使用情境。项目采用通用 IDM 时，还需在该次委托中明确适用范围、责任、时点和例外；仅附上模板，不能替代这些具体约定。

这一区分对编制标准也有直接意义。行业标准可以研究某类业务的典型用例及其通用信息需求，项目再按资产类型、工作阶段和委托边界选用、增删并明确责任。若项目要求只写“按标准执行”，承担交付的团队就无从判断具体范围。两层之间需要一份可检查的映射，说明采用了哪些通用 ER、如何形成该项目的 EIR、例外由谁决定。buildingSMART 国际的“用例管理”（Use Case Management，UCM）项目就是这类收集和整理全球通用用例的一种服务。

技术要点： 对一个行业或企业而言，都应针对通用用例制定 IDM 库，以增强信息标准化能力，提高数据的复用价值。

三、从业务语言走向可检验的数据

再说说技术实现。IDM 毕竟是用于人类之间进行技术沟通的，而 BIM 天然要求计算机深度参与，且执行全部数据处理工作。因此，让交换要求具有足够的计算机可读性（readable）、可解释性（interpretable）和可执行性（executable），是 IDM 能够实现的必要路径。ISO 16739-1 的 IFC 数据模式可以表达资产对象、属性和关系，却不会自行决定运营方在这个时点需要什么。通风机示例可以用 IFC 表达设备及其空间位置，并以约定的标识关联说明书；也可以交付结构化清单或文档。但把“需要什么”转成“软件怎样读和检查”，仍有两道工作。

其一是概念对齐：设计编号、出厂序列号和安装位置标识，在不同单位可能都被叫作“设备编号”。ISO 12006-3 可使 IDM 中表示信息单元的术语结构化，并与其他术语映射；但具体采用哪一个概念，仍需交付各方约定，当然最佳实践是采用 ISO 12006-3 给定的数据字典的方法。

其二是技术绑定：把信息单元和约束对应到可交换的数据结构及检验规则。ISO 29481-1 为此采用“交换视图定义”（exchange view definition，EVD）这一术语，指满足交换要求所需的一个或多个数据模型（或其部分）的计算机可解释表达。ISO 29481-3:2022 则以名为 idmXSD 的 XML 模式，使 IDM 本身可以被机器读取、交换和复用（非常类似于标准数字化，对条文进行标记，以后有机会详细介绍）。

注：众所周知的 MVD（model view definition）可以看作 EVD 在 IFC 范畴中的特化形式。

四、IDM 示例：通风机维护资料移交

把前文的通风机案例按标准组件顺序整理，可以得到下面这份 IDM 的主体内容（这是说明性示例，字段取舍、约束取值和代码均为假设）。

用例与管理信息

标识和编制信息、用例内容，可以整理成下表。

注：对于项目阶段，IDM 采用了 ISO 22263，但由于我国没有转化 ISO 22263，所以表中按照我国实际情况填写。

若以 ISO 29481-3:2022 的格式保存，这份用例还需要一个 IDM 代码，依次由规格类型、主要用途、起止项目阶段、地区、语言、英文简称、作者、首稿日期和文件状态组成，各项以下划线连接：

uc_PlanMaintenance_PR_MA_CHN_ZH_FanHandover_Example_20261011_WD

不打开文件，就能从代码看出这是一份用例规格，主要用途是编制维护计划，覆盖生产至维护阶段（PR、MA 是 ISO 29481-3 为生产、维护两个阶段规定的代号），面向中国（CHN）、以中文（ZH）编写，目前是工作草案（WD）。地区按 ISO 3166-1 取三字母代码，语言按 ISO 639-1 取值，作者一项此处以 Example 代替。

业务情境

业务情境部分说明边界内哪些活动或事务需要交换信息，并在图上标出对应的交换要求。图 2 是本例按 BPMN 绘制的过程图。整张图为一个池（pool），以过程名称命名；运营方、承包方各占一条泳道，两者之间另设一条交换要求泳道，“通风机维护资料”作为数据对象（data object）画在其中，并以点线关联到从“整理并提交通风机资料”流向“核对设备标识与资料”的顺序流。资料不全时，排他网关（带 × 的菱形）把流程转到承包方“补正缺项资料”，补正后再回到核对；资料完整，运营方才生成预防性维护计划。单设交换要求泳道的画法沿用 buildingSMART 的 IDM 编制指南。交互图只含一个事务“移交维护资料”，发起方为运营方，执行方为承包方。

图 2　通风机维护资料移交过程图（BPMN 示例）。

查看图 2 大图

交换要求

交换要求的头部同样带有名称、简称和标识，主体是信息单元及其约束。本例还要求项目先确认设备编号规则：规则未定，设备标识一项就无从核对。

按信息需求等级的三类划分，前六项属于文字信息，说明书属于文档，外形与检修空间属于几何信息。“必需”一栏写明缺项时能否接受，也就决定了交互图中运营方何时退回资料。

映射到 IFC 与 IDS

若以 IFC 交付，表中多数信息单元能在 ISO 16739-1:2024 中找到对应位置。通风机用 IfcFan 表达；制造商和型号可放入 Pset_ManufacturerTypeInformation 的 Manufacturer 与 ModelReference；说明书以 IfcDocumentReference 经 IfcRelAssociatesDocument 关联到通风机；安装位置通过 IfcRelContainedInSpatialStructure 归入所在房间。保养周期可写入 Pset_MaintenanceTriggerDuration 的 DurationMaintenanceLevel，其取值类型 IfcDuration 采用 ISO 8601 的时长写法，6 个月记作 P6M，单位随数值一并保存。投运日期等在标准属性集中找不到合适对应项的信息单元，由项目约定自定义属性。

设备标识最需要约束。IfcElement 的 Tag 属性按定义既可存放序列号，也可存放位置编号；出厂序列号另有 Pset_ManufacturerOccurrence 中的 SerialNumber 可用。IDM 的约束应写明本项目把哪一种编号放在哪里，否则两家单位提交的模型都“有编号”，却无法相互对照。

其中属性取值和空间包含关系可以写成 IDS 规则，下面一条规则要求模型中至少有一台风机，且每台都在 Pset_MaintenanceTriggerDuration 中给出 IfcDuration 类型的维护间隔。下面是一个简单的 IDS 的例子（非 IDS 编制人员不必逐句看懂，了解大致形式即可）。

<ids:specification name="通风机须给出维护间隔" ifcVersion="IFC4X3_ADD2">
  <ids:applicability minOccurs="1" maxOccurs="unbounded">
    <ids:entity>
      <ids:name><ids:simpleValue>IFCFAN</ids:simpleValue></ids:name>
    </ids:entity>
  </ids:applicability>
  <ids:requirements>
    <ids:property dataType="IFCDURATION" cardinality="required">
      <ids:propertySet>
        <ids:simpleValue>Pset_MaintenanceTriggerDuration</ids:simpleValue>
      </ids:propertySet>
      <ids:baseName>
        <ids:simpleValue>DurationMaintenanceLevel</ids:simpleValue>
      </ids:baseName>
    </ids:property>
  </ids:requirements>
</ids:specification>

以一个含三台风机的测试模型为例：EF-01 的维护间隔写为 P6M，通过；EF-02 没有这一属性集，不通过；EF-03 把维护间隔写成整数 6，因数据类型不符而不通过。第三种情况正是前文“保养周期：6”的问题，IDS 能在交付环节把它拦下。说明书内容是否与现场设备相符，这条规则仍无法判断，需要运营方核对。

五、结语

IDM 的最终作用，是把信息交付从一张文件清单推进为有业务理由、有时点、有责任、可逐项核对的约定。对于建设项目和标准编制工作，首先应问的不是“用哪一种模型格式”，而是“谁将在何时依据这些信息完成什么工作”。这个问题答得越具体，后续选择 IFC、文档、数据字典和自动检查规则，才越有依据。

参考文献

1. ISO. ISO 29481-1:2025, Building information models — Information delivery manual — Part 1: Methodology and format. Geneva: ISO, 2025.
2. ISO. ISO 29481-2:2025, Building information models — Information delivery manual — Part 2: Interaction framework. Geneva: ISO, 2025.
3. ISO. ISO 29481-3:2022, Building information models — Information delivery manual — Part 3: Data schema. Geneva: ISO, 2022.
4. ISO/IEC. ISO/IEC Directives, Part 2: Principles and rules for the structure and drafting of ISO and IEC documents. 9th ed. Geneva: ISO/IEC, 2021.
5. 国家市场监督管理总局，国家标准化管理委员会. GB/T 1.1—2020 标准化工作导则　第 1 部分：标准化文件的结构和起草规则. 2020-03-31 发布.
6. ISO/IEC. ISO/IEC 19510:2013, Information technology — Object Management Group Business Process Model and Notation. Geneva: ISO, 2013.
7. Dietz, J. L. G., & Mulder, M. A. T. DEMO Specification Language 3.7. Enterprise Engineering Institute, 2017.
8. ISO. ISO 22263:2008, Organization of information about construction works — Framework for management of project information. Geneva: ISO, 2008.
9. ISO. ISO 7817-1:2024, Building information modelling — Level of information need — Part 1: Concepts and principles. Geneva: ISO, 2024.
10. ISO. ISO 19650-1:2018, Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) — Information management using building information modelling — Part 1: Concepts and principles. Geneva: ISO, 2018.
11. ISO. ISO 16739-1:2024, Industry Foundation Classes (IFC) for data sharing in the construction and facility management industries — Part 1: Data schema. Geneva: ISO, 2024.
12. ISO. ISO 12006-3:2022, Building construction — Organization of information about construction works — Part 3: Framework for object-oriented information. Geneva: ISO, 2022.
13. buildingSMART International. Information Delivery Manual: Guide to Components and Development Methods（IDMC 004，Version 1.2）. 2010.
14. buildingSMART International. Use Case Management.
15. buildingSMART International. Information Delivery Specification (IDS).
16. buildingSMART International. Information Delivery Specification (IDS) v1.0 is Approved as a Final Standard. 2024-06-04.