《建筑信息模型设计交付标准[附条文说明]》GB/T 51301-2018

中华人民共和国国家标准

建筑信息模型设计交付标准

Standard for design delivery of building information modeling

GB/T 51301-2018

主编部门：中华人民共和国住房和城乡建设部

批准部门：中华人民共和国住房和城乡建设部

施行日期：2 0 1 9 年 6 月 1 日

中华人民共和国住房和城乡建设部公告

2018年第345号

住房和城乡建设部关于发布国家标准《建筑信息模型设计交付标准》的公告

现批准《建筑信息模型设计交付标准》为国家标准，编号为GB/T 51301-2018， 自2019年6月1日起实施。

本标准在住房和城乡建设部门户网站(www.mohurd.gov.cn)公开，并由住房和城乡建设部标准定额研究所组织中国建筑工业出版社出版发行。

中华人民共和国住房和城乡建设部

2018年12月26日

前言

根据住房和城乡建设部《关于印发<2012年工程建设标准制订、修订计划>的通知》(建标[2012]5号)的要求，标准编制组经广泛调查研究，认真总结实践经验，参考有关国际标准和国外先进标准，并在广泛征求意见的基础上，编制了本标准。

本标准的主要技术内容是：1.总则；2.术语；3.基本规定；4.交付准备；5.交付物；6.交付协同。

本标准由住房和城乡建设部负责管理，由中国建筑标准设计研究院有限公司负责具体技术内容的解释。执行过程中如有意见和建议，请寄送中国建筑标准设计研究院有限公司(地址：北京市海淀区首体南路9号主语国际2号楼，邮编：100048)。

本标准主编单位：中国建筑标准设计研究院有限公司

本标准参编单位：中国建筑设计院有限公司

上海现代建筑设计(集团)有限公司

北京市建筑设计研究院有限公司

清华大学建筑设计研究院有限公司

欧特克软件(中国)有限公司

上海市地下空间设计研究总院有限公司

北京金土木信息技术有限公司

中国电子工程设计院

中国石油管道局工程有限公司

中国建筑西北设计研究院有限公司

中建一局集团建设发展有限公司

华科优建(武汉)工程信息发展有限公司

上海市城市建设设计研究总院(集团)有限公司

图软香港有限公司北京代表处

江苏省苏中建设集团股份有限公司

中国建筑第八工程局有限公司

深圳市华阳国际工程设计股份有限公司

中国建筑第七工程局有限公司

北京柏慕进业工程咨询有限公司

北京理正软件股份有限公司

上海市政工程设计研究总院(集团)有限公司

上海凯德数值信息科技有限公司

清华大学建筑学院

同济大学

天津大学

华中科技大学

悉地国际设计顾问(深圳)有限公司

中信和业投资有限公司

同济大学建筑设计研究院(集团)有限公司

中国五洲工程设计集团有限公司

奔特力软件(北京)有限公司

上海大学

艾奕康咨询(深圳)有限公司

河北建筑工程学院

深圳市建筑科学研究院

建研科技股份有限公司

中国建筑东北设计研究院有限公司

北京华思维泰克科技有限公司

北京建谊投资发展(集团)有限公司

苏州金螳螂建筑装饰股份有限公司

上海鲁班软件有限公司

深圳市建筑设计研究总院有限公司

四川省建筑设计研究院

中国中铁航空港建设集团有限公司

卓达房地产集团有限公司

南通沿海开发集团城镇建设有限公司

重庆筑智建建筑科技有限公司

本标准主要起草人员：魏来 罗文斌 于洁 高承勇 邓明胜 谢卫 王玉卿 宋国清 张亚立 王春光 李嘉军 徐昱洋 卜一秋 庄惟敏 陈宇军 李邵建 张学生 熊诚 辛佐先 周立 张洪伟 张杨 苏亚武 王乔恒 杨峥 崔旸 冯志江 曲昌盛 杨海涛 赵昂 唐小卫 欧均胜 张吕伟 王广斌 黄亚斌 黄琨 汪丛军 徐卫国 姚守俨 刘守奎 许蓁 张金月 骆汉宾 穆威 过俊 张学斌 陈继良 张东升 侯本才 何立波 喻钢 龙辉元 焦安亮 张炜 金新阳 马恩成 陈勇 李和庆 吴小员 刘立明 杨志 吴俊书 魏有光 杨帆 熊婧彤 张宇宁 刘锋 郭阴生 刘培贵 石飞 赵亮

本标准主要审查人员：孟建民 王丹 张鸿辉 张建平 欧阳东 王国俭 刘莹 王蕴 孟凡贵 于晓明 李久林 杨富春

1.0.1  为规范建筑信息模型设计交付，提高建筑信息模型的应用水平，制定本标准。

▼ 展开条文说明
1.0.1  本条明确了制定本标准的目的。

1.0.2  本标准适用于建筑工程设计中应用建筑信息模型建立和交付设计信息，以及各参与方之间和参与方内部信息传递的过程。

▼ 展开条文说明
1.0.2  本条规定了本标准的使用范围。从国际标准和大多数国家(地区)的标准编制情况来看，应用建筑信息模型进行设计信息的交付是一个较为复杂并且持续的信息化过程，只有对信息建立过程加以约束，才能保障信息的完备性和交付的规范性，交付并不是单一行为，包含交付准备、交付物、交付协同三个方面。

1.0.3  建筑信息模型设计交付，除应符合本标准外，尚应符合国家现行有关标准的规定。

2.0.1  设计交付  design delivery

   根据工程项目的应用需求，将设计信息传递给需求方的行为。

▼ 展开条文说明
2.0.1  设计交付既指建筑工程阶段性交付，也包含某一阶段内，参与方内部协同的过程中的交付行为。

2.0.2  设计信息  design information

   建筑工程设计工作所形成的描述建筑(物理实体)本体特征的信息集合。

▼ 展开条文说明
2.0.2  本条参考了国家标准《民用建筑设计术语标准》GB/T 50504-2009关于建筑物的定义。在该标准中，建筑物是指“用建筑材料构筑的空间和实体，供人们居住和进行各种活动的场所”；广义的建筑设计是指“设计一个建筑物(群)要做的全部工作”。结合当前的工程实践，在信息化领域，设计信息可以理解为全生命周期内对建筑物(包括构筑物)自身全部特征的描述，而且是全局性信息。

从方案设计阶段到深化设计阶段，直至竣工移交之前，设计信息不仅仅是指设计方的工作内容，还包括由承包方、生产方所提供的深化和完善建筑物自身描述的信息。竣工移交之后，建筑物或构筑物进入长期的使用过程，此时使用者关注的也往往是建筑物自身的描述信息。在这些过程中，设计信息是各类应用的数字基础，在建筑信息模型(BIM)领域，用来承载设计信息的模型即体现为建筑物或构筑物的数字化内核，基于此，可进行节能分析、施工组织、工程审批、数字化存档、智能建筑乃至智慧城市等多方面的应用。

2.0.3  设计阶段  design phases

   工程项目竣工交付之前，根据基本建设程序而划分的重要设计交付过程分划。

▼ 展开条文说明
2.0.3  设计阶段是设计过程的分划，也是建筑物或构筑物本体设计信息逐步完善的过程中，工程参与方相互协同设计信息的重要里程碑。

2.0.4  应用需求  application requirements

   依据工程操作目标而确定的对于建筑信息模型的需求。

▼ 展开条文说明
2.0.4  应用需求是指建筑信息模型的应用目的，应在信息模型创建之前约定，并可根据项目进展修正。

2.0.5  交付物  deliverable

   基于建筑信息模型交付的成果。

2.0.6  协同  collaboration

   基于建筑信息模型进行数据共享及相互操作的过程。

▼ 展开条文说明
2.0.6  协同主要包括建筑工程项目参与方之间的协同、各参与方内部不同角色之间的协同以及上下游阶段之间的数据传递及反馈等。

2.0.7  工程对象  engineering object

   构成建筑工程的建筑物、系统、设施、设备、零件等物理实体的集合。

2.0.8  模型单元  model unit

   建筑信息模型中承载建筑信息的实体及其相关属性的集合，是工程对象的数字化表述。

▼ 展开条文说明
2.0.7、2.0.8  基于建筑信息模型的建筑描述方式与传统的图示表达差异很大。根据建筑信息模型技术的特点，将建筑物或构筑物认知为功能空间和产品(部品)的组合，这种模式在国际上也是共识，体现在IFC架构当中。IFC即为Industry Foundation Classes，其相关的国际标准为ISO 16739。功能空间和产品(部品)在物理世界中体现为“工程对象”，映射在建筑信息模型数字化环境中体现为“模型单元”。同时，模型单元体现了模型的单元化架构组织，即由项目级、功能级、构件级和零件级单元嵌套组成，而不是各类模型散乱的堆砌。模型单元在实体和属性两个维度上体现描述能力，例如一扇窗户，窗户本身即为实体，其相应的几何尺寸、材质、价格等均为属性。

2.0.9  模型架构 model framework

   组成建筑信息模型的各级模型单元之间组合和拆分等构成关系。

▼ 展开条文说明
2.0.9  在分解模型单元时，不同的工程应用需求会产生不同的分解方式，另外随着工程阶段的发展，对建筑的描述趋于丰富和详尽。模型单元也趋于细微，从而产生“最小模型单元”的概念。最小模型单元体现了建筑信息模型描述设计信息的细致程度。

2.0.10  最小模型单元  minimal model unit

    根据建筑工程项目的应用需求而分解和交付的最小拆分等级的模型单元。

2.0.11  模型精细度  level of model definition

   建筑信息模型中所容纳的模型单元丰富程度的衡量指标。

▼ 展开条文说明
2.0.11  模型精细度是全球通行的衡量建筑信息模型完备程度的指标。但如何定义模型精细度，当前并没有共识。Level of Development简称LOD，概念起源于美国，由美国建筑师协会(AIA)等组织根据工程阶段特点划分为LOD100、200、300、400乃至500。然而由于版权关系，其他多数国家采用不同的说法。如英国标准BS1192采用了Level of Definition。本标准采用Level of Model Definition，日常使用时，也可简称为LOD。

2.0.12  几何表达精度  level of geometric detail

   模型单元在视觉呈现时，几何表达真实性和精确性的衡量指标。

▼ 展开条文说明
2.0.12  几何表达精度体现模型单元在视觉呈现上的描述能力。基于目前的软硬件技术，并结合工程实际需求，建筑信息模型无法也没有必要表达出构件或产品的全部几何变化真实细节。应根据应用需求，选择适当的几何表达精度等级。几何精度等级也可简称为Gx。

2.0.13  信息深度  level of information detail

   模型单元承载属性信息详细程度的衡量指标。

▼ 展开条文说明
2.0.13  信息是模型单元最重要的特征。信息随着工程阶段的推进而逐步丰富。应根据应用需求，选择适当的信息深度等级。信息深度等级也可简称为Nx。

3.1.1  建筑信息模型设计交付应包括设计阶段的交付和面向应用的交付。交付应包含交付准备、交付物和交付协同等方面内容。

▼ 展开条文说明
3.1.1  建筑信息模型的设计交付通常需要满足阶段性交付要求，但是并不能涵盖全部建筑信息模型的应用场景，因此面向应用的交付也构成了重要的环节，这些应用直接关系到项目的各项管理。一个完整的交付过程，由三个要素组成，其一是以建筑信息模型体现设计信息，其二是由建筑信息模型输出为交付物，第三是交付过程中各参与方之间的协同。

3.1.2  建筑工程设计应包括方案设计、初步设计、施工图设计、深化设计等阶段，施工图设计和深化设计阶段的信息模型宜用于形成竣工移交成果。建筑信息模型的交付准备、交付物和交付协同应满足各阶段设计深度的要求。

▼ 展开条文说明
3.1.2  设计阶段的划分并没有统一的依据。在住房和城乡建设部颁布的《建筑工程设计文件编制深度规定》中，将设计过程划分为方案设计、初步设计、施工图设计和专项设计四个阶段。其中专项设计也仅列出了幕墙设计、基坑与边坡工程设计、建筑智能化设计三种，考虑到当前工程实践的习惯，将专项设计拓展为深化设计，涵盖施工图设计阶段之后所有关于建筑本体的细化设计过程。另外设计信息与竣工移交关联性很大，也是为了兼顾设计信息在向运维阶段传递时的完整性。

3.1.3  面向应用的交付宜包括建筑全生命期内有关设计信息的各项应用，建筑信息模型的交付准备、交付物和交付协同应满足应用需求。

▼ 展开条文说明
3.1.3  面向应用的交付场景非常多，如建筑的性能化分析、冲突检测、造价分析、建筑表现、施工组织等。各种应用所需的设计信息、交付深度、交付物形式、协同模式等均需要根据应用自身特点去分析和考量，从而所有的要求均体现为应用需求，面向应用的交付过程以此为基石。

3.1.4  建筑信息模型交付过程中，应根据设计信息建立建筑信息模型，并输出交付物，交付协同应以交付物为依据，工程各参与方应基于协调一致的交付物进行协同。

3.2.1  建筑信息模型及其交付物的命名应简明且易于辨识。

▼ 展开条文说明
3.2.1  科学的对象以及参数命名，有利于模型正确使用，对于协同也非常重要。因此有必要对模型单元以及属性命名方式加以规定。考虑到各类工程实际情况复杂，因此本条规定一般原则。

3.2.2  模型单元及其属性命名宜符合下列规定：

   1  宜使用汉字、英文字符、数字、半角下划线“_”和半角连字符“-”的组合；

   2  字段内部组合宜使用半角连字符“-”，字段之间宜使用半角下划线“_  ”分隔；

   3  各字符之间、符号之间、字符与符号之间均不宜留空格。

▼ 展开条文说明
3.2.2  对象和参数的命名应使用较少类型的符号，以避免混乱的命名符号。另外考虑到部分软件无法识别中英文命名的区别，因此要谨慎使用英语词汇，既要符合专业习惯，又不至于引起混乱。例如混凝土，其命名不宜表示为Concrete，但混凝土的强度等级，可表示为C20。

3.2.3  电子文件夹的名称宜由顺序码、项目简称、分区或系统、设计阶段、文件夹类型和描述依次组成，以半角下划线“_”隔开，字段内部的词组宜以半角连字符“-”隔开，并宜符合下列规定：

   1  顺序码宜采用文件夹管理的编码，可自定义；

   2  项目简称宜采用识别项目的简要称号，可采用英文或拼音，项目简称不宜空缺；

   3  分区或系统应简述项目子项、局部或系统，应使用汉字、英文字符、数字的组合；

   4  设计阶段应划分为方案设计、初步设计、施工图设计、深化设计等阶段；

   5  文件夹类型宜符合表3.2.3的规定；

表3.2.3  文件夹类型

   6  用于进一步说明文件夹特征的描述信息可自定义。

▼ 展开条文说明
3.2.3  科学的文件夹命名有利于项目协同。考虑到各类工程实际情况复杂，且各应用单位习惯不一，因此本条规定一般原则。状态代码参照了英国有关BIM标准，“工作中数据”是指各专业分部尚未确定或未完成审核手续的设计文档或数据；“共享数据”是指各专业分部已经确定并完成审核手续的设计文档或数据，其他专业可作为设计依据；“出版数据”是指完成审核手续并对外交付的交付物；“存档数据”是指用于存档的交付物；“外部参考数据”是指来自外部的设计条件数据；“资源库数据”是指各类内部资源，包括标准文档、模板库、构件库、定额库等。

3.2.4  电子文件的名称宜由项目编号、项目简称、模型单元简述、专业代码、描述依次组成，以半角下划线“_”隔开，字段内部的词组宜以半角连字符“-”隔开，并宜符合下列规定：

   1  项目编号宜采用项目管理的数字编码，无项目编码时宜以“000”替代；

   2  项目简称宜采用识别项目的简要称号，可采用英文或拼音，项目简称不宜空缺；

   3  模型单元简述宜采用模型单元的主要特征简要描述；

   4  专业代码宜符合表3.2.4的规定，当涉及多专业时可并列所涉及的专业；

表3.2.4  专业代码

    5  用于进一步说明文件内容的描述信息可自定义。

▼ 展开条文说明
3.2.4  电子文件的命名可协助快速识别文件内容，对于社会广泛协同也有重要意义，因此有必要加以较为详细地统一规定。
考虑到多种情况，在文件名最后设立“描述”字段，可自行定义，用于补充说明其他情况。

3.3.1  建筑信息模型的电子文件夹和文件，在交付过程中均应进行版本管理，并宜在命名字段中标识。

▼ 展开条文说明
3.3.1  建筑信息模型的版本管理是加强信息痕迹管理的一种手段。相较于传统的二维图纸交付，由于信息化的数据复杂等特点，信息追溯时会遇到查询上的困难，因此有必要进行科学的版本管理。

3.3.2  文件夹的版本管理宜在文件夹类型字段中标识，并宜符合下列规定：

   1  设计阶段的交付中，交付物文件所在的文件夹类型宜为出版，交付完成后，建筑信息模型及交付物均宜根据设计阶段分别存档管理，全部文件所在的文件夹类型宜为存档；

   2  面向应用的交付中，交付物文件所在的文件夹类型宜为共享，交付完成后，建筑信息模型及交付物均宜根据应用类别分别存档管理，全部文件所在的文件夹类型宜为存档。

3.3.3  文件的版本管理应符合下列规定：

   1  设计阶段交付时，应写明设计阶段的名称；

   2  面向应用交付时，应写明所有正在进行或已经完成的应用需求的代号。

3.3.4  同一设计阶段或面向同一应用需求多次交付时，文件夹和文件版本应在标识中添加版本号，版本号宜由英文字母A～Z依次表示。

4.1.1  建筑信息模型交付准备过程中，应根据交付深度、交付物形式、交付协同要求安排模型架构和选取适宜的模型精细度，并应根据设计信息输入模型内容。

▼ 展开条文说明
4.1.1  建筑信息模型包含丰富的模型元素，然而众多的模型元素如果不能以合理的架构组织起来，势必会导致模型散乱，信息含混不清，从而给模型应用带来困难。因此，模型在良好的架构基础上，加载充分的内容是非常必要的。

4.1.2  建筑信息模型应由模型单元组成，交付全过程应以模型单元作为基本操作对象。

▼ 展开条文说明
4.1.2  用来表达工程对象的模型及其承载的信息组成了一个有机整体，具有明显的单元化架构特征，因此模型单元是建筑信息模型的基本组成，也是基本处理对象。例如在施工图交付阶段，构件级模型单元大量出现，继而在深化设计以及采购、安装过程中，这些模型单元往往会迭代为明确的厂家产品。例如窗户，其作为构件级模型单元，从设计师的要求，到厂家生产，再到安装完毕的过程中，均可作为独立的处理对象。

4.1.3  模型单元应以几何信息和属性信息描述工程对象的设计信息，可使用二维图形、文字、文档、多媒体等方式补充和增强表达设计信息。

▼ 展开条文说明
4.1.3  模型单元承载的信息，可视化体现为几何信息的呈现，自身的定义体现为属性信息。鉴于当前的信息技术能力和工程实践状况，仅使用三维模型并不足以表述建筑信息，因此需要其他种类的介质来补充和进一步说明。

4.1.4  当模型单元的几何信息与属性信息不一致时，应优先采信属性信息。

▼ 展开条文说明
4.1.4  由于技术条件的限制和实际操作的需要，建筑信息模型所包含的信息不一定能够全部以几何方式全部可视化表达出来，例如家具，在某些要求下，可以二维的方式制图，但其对应的属性信息可具备更加丰富的信息内容，包括椅子的重量、体积、材质等。此类情况下，应以模型所承载的非几何信息作为优先的有效信息。

4.2.1  建筑信息模型所包含的模型单元应分级建立，可嵌套设置，分级应符合表4.2.1的规定。

表4.2.1  模型单元的分级

▼ 展开条文说明
4.2.1  考虑到多种交付情况，因此模型单元划分为四个级别。项目级模型单元可描述项目整体和局部；功能级模型单元由多种构配件或产品组成，可描述诸如手术室、整体卫浴等具备完整功能的建筑模块或空间；构件级模型单元可描述墙体、梁、电梯、配电柜等单一的构配件或产品。多个相同构件级模型单元也可成组设置，但仍然属于构件级模型单元；零件级模型单元可描述钢筋、螺钉、电梯导轨、设备接口等不独立承担使用功能的零件或组件。模型单元会随着工程的发展逐渐趋于细微。模型单元可具有嵌套关系，低级别的模型单元可组合成高级别模型单元。

4.2.2  建筑信息模型包含的最小模型单元应由模型精细度等级衡量，模型精细度基本等级划分应符合表4.2.2的规定。根据工程项目的应用需求，可在基本等级之间扩充模型精细度等级。

表4.2.2  模型精细度基本等级划分

▼ 展开条文说明
4.2.2  尽管存在很大的争议，然而鉴于“模型精细度”(LOD)是比较普遍的概念，本标准采纳了这个说法，这样更有利于顺畅地理解建筑信息模型的发展程度。但为了规避版权风险，将LOD等级命名为LOD1.0、2.0、3.0和4.0。

4.3.1  建筑信息模型应包含下列内容：

   1  模型单元的系统分类；

   2  模型单元的关联关系；

   3  模型单元几何信息及几何表达精度；

   4  模型单元属性信息及信息深度；

   5  属性值的数据来源。

▼ 展开条文说明
4.3.1  为了保障信息有序而规范地传递，模型单元的描述方式关系到数据应用时能否进行数据定位。因此有必要制定共同规则，既约束模型单元的输入，也提供数据定位的方法。模型单元分为实体、属性两个维度，在传递过程中几个关键因素应被重点考虑：
1  模型单元的所处系统分类是本标准所采纳的建筑物或构筑物的首要构成逻辑。也就是建筑物所包含的工程对象，是依据外围护系统、其他建筑构件系统、给水排水系统、暖通空调系统、电气系统、智能化系统和动力系统组织在一起并完成特定的功能使命。因此界定模型单元的系统分类，有助于厘清建筑信息模型脉络，并使之与实际设计过程和使用功能一一对应起来。

某些模型单元可能同时属于多个系统，本标准要求在属性中一一列出。
2  部分模则单元之间是有关联性的，特别是属于同一系统之内，充分的关联关系使模型单元能够链接为有机整体，这样模型才能够充分表达系统性能。另外，建立关联关系，有助于生成系统简图，也可以使系统简图与模型建立实时的对应关系。
3  模型单元的视觉呈现效果，决定了在数字化领域人机互动时人类是否能够快速识别模型单元所表达的工程对象。当前的工程实践表明，模型单元并不需要呈现出与实际物体完全相同的几何细节。
4  模型单元所承载的信息，依靠属性来体现，同时属性定义了模型单元的实质，即所表达的工程对象的全部事实。然而考虑到不同的应用需求，所需要的属性完整程度也是不同的，另外，模型单元可能需要大量的属性来描述，因此有必要对属性加以分类，这样有利于信息的界定和定位查询。
模型单元的属性分类是信息组织的模式。鉴于建筑物属性繁多，因此本标准并未穷举属性名称。但从标准化的角度上看，应用方自行编制的标准体系中，应尽可能充分列举所需的属性名称，从而达到标准前置的目的。
属性名称与属性值一一对应。例如“某灯泡的额定功率是100W”这样一条描述信息，“某灯泡”是实体，“额定功率”是属性名称，“100W”是属性值。
属性值体现模型单元最终描述的结果。属性值可根据工程发展程度逐步体现，由掌握相应信息的输入方完成输入。某个模型单元的迭代过程主要体现为属性值的迭代。
5  正如第4款所述，模型单元的属性值随着工程发展而迭代，属性值的数据来源变得非常重要，不同的数据来源意味着不同的交付目的和采信程度。例如数据来源为设计，则属性值的涵义为设计要求，而来源为生产时，则属性值的涵义为产品的规格。

4.3.2  应根据设计信息将模型单元进行系统分类，并应在属性信息中表示。系统分类宜符合本标准附录A的规定。

4.3.3  具有关联的模型单元应表明直接关联关系，并应符合下列规定：

   1  属于建筑外围护系统、其他建筑构件系统的模型单元应符合下列规定：

    1)构件级模型单元宜表明直接的连接关系；

    2)零件级模型单元宜表明直接的从属关系。

   2  属于给水排水系统、暖通空调系统、电气系统、智能化系统和动力系统的模型单元应符合下列规定：

    1)功能级模型单元和构件级模型单元宜表明直接的控制关系；

    2)无控制关系的构件级模型单元宜表明直接的连接关系；

    3)零件级模型单元宜表明直接的从属关系。

▼ 展开条文说明
4.3.3  本标准要求在属性中体现模型单元直接的系统关联关系。这样有利于厘清建筑信息模型的系统脉络，也有利于模型单元组成一个有机体，有效建立数据链接，使整个建筑信息模型更加有逻辑，从而形成关系数据库，避免了模型堆砌。考虑到墙体、门窗、梁、柱等普通建筑构件之间不具有很强的控制关系，因此建筑外围护系统和其他建筑构件系统只需界定连接关系和从属关系。对于给水排水系统、暖通空调系统、电气系统、智能化系统和动力系统的模型单元，控制关系显得相对重要。在某些情况下，管线没有必要三维建模，但只要管线所衔接设备的直接控制关系能够体现出来，就可以保障系统的完整性。另外，清晰的关联关系有助于系统图与模型建立良好的对应关系。

4.3.4  模型单元的几何信息应符合下列规定：

   1  应选取适宜的几何表达精度呈现模型单元几何信息；

   2  在满足设计深度和应用需求的前提下，应选取较低等级的几何表达精度；

   3  不同的模型单元可选取不同的几何表达精度。

▼ 展开条文说明
4.3.4  模型单元的视觉呈现水平，由几何表达精度衡量，体现模型单元与物理实体的真实逼近程度。例如一台设备，既可以表达为一个简单的几何形体，甚至一个符号，也可以表达得非常真实，描述出细微的形状变化。本标准规定的四个级别，与工程阶段顺序没有一一对应关系。而是根据不同类型的项目应用需求，采纳不同等级的几何表达精度。例如方案设计阶段，需要对设计理念进行描述时，可能需要G4精度，来更加真实地演示设计效果。而在初步设计和施工图设计中，往往会采用G3精度。
在满足应用需求的前提下，采用较低的Gx，包括几何描述在内的更多描述，以信息或者属性的形式表达出来，避免过度建模情况的发生，也有利于控制BIM模型文件的大小，提高运算效率。
本标准作为国家标准，仅作出框架定义，更为详尽的关于几何表达精度的规定，应参照其他相关标准。

4.3.5  几何表达精度的等级划分应符合表4.3.5的规定。

表4.3.5  几何表达精度的等级划分

4.3.6  模型单元的属性信息应符合下列规定：

   1  应选取适宜的信息深度体现模型单元属性信息；

   2  属性应分类设置，属性分类宜符合本标准附录B的要求；

   3  属性宜包括中文字段名称、编码、数据类型、数据格式、计量单位、值域、约束条件；交付表达时，应至少包括中文字段名称、计量单位；

   4  属性值应根据设计阶段的发展而逐步完善，并应符合下列规定：

     1)应符合唯一性原则，即属性值和属性应一一对应，在单个应用场景中属性值应唯一；

    2)应符合一致性原则，即同一类型的属性、格式和精度应一致。

▼ 展开条文说明
4.3.6  信息深度会随着工程阶段的发展而逐步深入。信息深度等级的划分，体现了工程参与方对信息丰富程度的一种基本共同观念。信息深度等级体现了BIM的核心能力。对于单个项目，随着工程的进展，所需的信息会越来越丰富。宜根据每一项应用需求，为所涉及的模型单元选取相应的信息深度(Nx)。信息深度应与本标准第3.2.4条所规定的几何表达精度配合使用，以便充分且必要地描述每一个模型单元。

4.3.7  模型单元信息深度等级的划分应符合表4.3.7的规定。

表4.3.7  信息深度等级的划分

4.3.8  模型单元属性值宜标记数据来源。属性值数据来源分类宜符合表4.3.8的规定。

表4.3.8  属性值数据来源分类

5.1.1  建筑工程各参与方应根据设计阶段要求和应用需求，从设计阶段建筑信息模型中提取所需的信息形成交付物。

▼ 展开条文说明
5.1.1  建筑信息模型交付物具有多种形式。鉴于当前的工程实践，面向特定的应用需求或交付场景，应选取适合的交付物，以便应用更加顺畅。

5.1.2  建筑信息模型主要交付物的代码及类别应符合表5.1.2的规定。

表5.1.2  交付物的代码及类别

   注：工程图纸包含电子工程图纸文件。

▼ 展开条文说明
5.1.2  建筑信息模型交付物本质上是数据载体。本条规定的交付物中：
1  建筑信息模型(D1类交付物)，不仅仅包括三维模型，也包含相互关联的二维图形、注释、说明以及相关文档等所有的信息介质，是最为全面的交付物。
2  属性信息表(D2类交付物)用来交付模型单元属性信息。
3  工程图纸(D3类交付物)是常规的二维图纸。然而事实表明，仅交付工程图纸并不能很好地完成建筑信息模型所要求的信息传递和协同。
4  项目需求书(D4类交付物)用来交付项目需求信息。
5  建筑信息模型执行计划(D5类交付物)用来交付模型建立和组织状况的说明。
6  建筑指标表(D6类交付物)用来交付项目的各类技术经济指标。
7  工程量清单(D7类交付物)用来交付从模型提取的工程量。

5.2.1  建筑信息模型应包含设计阶段交付所需的全部设计信息。

▼ 展开条文说明
5.2.1  建筑信息模型是承载设计信息的载体，应具有充分性，足以表达各个阶段所需的设计信息。

5.2.2  建筑信息模型应基于模型单元进行信息交换和迭代，并应将阶段交付物存档管理。

▼ 展开条文说明
5.2.2  在设计过程中，尽量避免对模型整体的重建或者干扰，否则容易造成信息丢失或失效。应根据工程参与方业务能力和特点，以模型单元作为信息协同的基本对象。在设计阶段交付之后，原阶段的设计信息模型应予存档。

5.2.3  建筑信息模型可索引其他类别的交付物。交付时，应一同交付，并应确保索引路径有效。

▼ 展开条文说明
5.2.3  根据建筑信息模型的技术特点和要求，交付物“建筑信息模型”并不仅指模型本身，而是一个数据体系或者数据库，包括所有已经操作的设计信息集合，因此，除了三维模型外，其他必要的信息交付物均可包含在交付物“建筑信息模型”中。

5.2.4  建筑信息模型的表达方式宜包括模型视图、表格、文档、图像、点云、多媒体及网页，各种表达方式间应具有关联访问关系。

▼ 展开条文说明
5.2.4  各种表达方式具有不同的表达能力，根据需要采取多种表达方式，并且表达方式之间建立良好的访问方式，这样能够充分利用信息化的优势。

5.2.5  交付和应用建筑信息模型时，宜集中管理并设置数据访问权限。

▼ 展开条文说明
5.2.5  为了保障信息传递过程中的正确性和完整性，模型应该是工程对象的唯一数字描述。采用移动介质等方式分发交付，容易导致版本混乱。另外，为了信息安全，设置信息访问权限是必要的措施。

5.3.1  项目级、功能级或构件级模型单元应分别制定属性信息表。

▼ 展开条文说明
5.3.1  人机信息交互时，为了快速地掌握模型单元所承载的信息，以及高效的数据定位，有必要使用信息模板规范信息条目组织，避免陷入“信息海洋”。
属性信息表是信息移交的良好方式，也是国际BIM标准的共同关注点。其中有关的标准有COBie标准(Construction Oprations Building Information Exchange，建设运维建筑信息交换)以及building SMART Date Dictionary(简称bSDD)等，这些标准的基本原理都是建立充分的数据模板，用来体现工程对象的属性。而这些数据模板应用在具体实践中，即形成“属性信息表”。

5.3.2  属性信息表电子文件的名称可由表格编号、模型单元名称、表格生成时间、数据格式、描述依次组成，由半角下划线“_”隔开，字段内部的词组宜由半角连字符“-”隔开。

5.3.3  属性信息表内容应包含下列内容：

   1  版本相关信息；

   2  模型单元基本信息；

   3  模型单元属性信息。

5.4.1  工程图纸应基于建筑信息模型的视图和表格加工而成。

▼ 展开条文说明
5.4.1  工程图纸即传统的二维图形交付物。考虑到当前的BIM实践水平，工程图纸仍然是必要的交付物。然而为了体现BIM的效益，要求工程图纸应主要基于建筑信息模型(Building Information Model)来生成，避免工程图纸与模型严重脱节。

5.4.2  电子工程图纸文件可索引其他交付物。交付时，应一同交付，并应确保索引路径有效。

5.4.3  工程图纸的制图应符合现行国家标准《房屋建筑制图统一标准》GB/T 50001的相关规定。

▼ 展开条文说明
5.4.3  由于工程图纸属于传统交付物，因此表达方法应符合国家现行有关标准的规定。

5.5.1  建筑信息模型建立之前，宜制定项目需求书。

▼ 展开条文说明
5.5.1  项目需求是项目实施BIM的起点。项目需求书应由工程建设单位提出，并交付BIM实施单位。

5.5.2  项目需求书应包含下列内容：

   1  项目计划概要，至少包含项目地点、规模、类型，项目坐标和高程；

   2  项目建筑信息模型的应用需求；

   3  项目参与方协同方式、数据存储和访问方式、数据访问权限；

   4  交付物类别和交付方式；

   5  建筑信息模型的权属。

5.6.1  根据项目需求书，应制定建筑信息模型执行计划。

▼ 展开条文说明
5.6.1  建筑信息模型执行汁划(BIM Execution Plan，简称BEP)是建筑信息模型及其应用过程中重要的说明书和指导原则。BEP在世界各国的BIM标准中都占据重要位置。有的国家BIM标准中也称为项目执行计划(Project Execution Plan简称PEP)。
不同于传统的工程图纸交付，BIM交付本质上是交付数据库，其所关联的数据组织、模型组织、文件组织等，如果缺乏说明文件，会给数据定位造成很大的困难。因此有必要交付一份说明文件，阐述模型组织、信息丰富程度、模型表达程度、交付物种类、协同方法等，以便BIM各参与方和使用者能够迅速达成数据架构上的共识。
另外，BEP也有助于非标准或者自定义内容的展示。

5.6.2  建筑信息模型执行计划应包含下列内容：

   1  项目简述，包含项目名称、项目简称、项目代码、项目类型、规模、应用需求等信息；

   2  项目中涉及的建筑信息模型属性信息命名、分类和编码，以及所采用的标准名称和版本；

   3  建筑信息模型的模型精细度说明；当不同的模型单元具备不同的建模精细度要求时，分项列出模型精细度；

   4  模型单元的几何表达精度和信息深度；

   5  交付物类别；

   6  软硬件工作环境，简要说明文件组织方式；

   7  项目的基础资源配置，人力资源配置；

   8  非相关标准规定的自定义的内容。

5.7.1  建筑指标表应基于建筑信息模型导出。

▼ 展开条文说明
5.7.1  对于工程项目，很多情况下建筑指标是重要的信息。基于BIM的方式，可以得到更为真实和详细的数据，但是应以建筑信息模型作为基本数据来源。

5.7.2  建筑指标表应包含下列内容：

   1  项目简述；

   2  建筑指标表应用目的；

   3  建筑指标名称及其编码；

   4  建筑指标值。

5.8.1  模型工程量清单应基于建筑信息模型导出。

▼ 展开条文说明
5.8.1  建筑信息模型的一个重点应用就是为工程量核算提供依据。然而需要注意的是，本条中的工程量，是指模型提供的工程量，与现行有关标准所要求的工程量相比，计算方法有差别。
根据模型提取的工程量，与最小模型单元水平、几何表达精度、信息深度等指标息息相关，因此在实际应用中，应首先完成建筑信息模型执行计划的复核，然后根据应用需求进行工程量提取。

5.8.2  模型工程量清单应包含下列内容：

   1  项目简述；

   2  模型工程量清单应用目的；

   3  模型单元工程量及编码。

6.1.1  建筑信息模型的交付协同应包括设计阶段的交付协同和面向应用的交付协同。

▼ 展开条文说明
6.1.1  建筑信息模型的交付协同是交付的重要环节。设计阶段交付和面向应用的交付所涉及的参与方责任、交付深度不尽相同，因此分开规定。另外，版本管理也有利于提高协同效率，厘清各方责任。

6.1.2  交付协同过程中，应根据设计阶段要求或应用需求选取模型交付深度和交付物，项目各参与方应基于协调一致的建筑信息模型协同工作。

6.1.3  模型交付的深度应符合下列规定：

   1  应符合项目级、功能级和构件级模型单元的模型精细度要求；

   2  应符合项目级和功能级模型单元的信息深度要求；

   3  应符合构件级和零件级模型单元的几何表达精度和信息深度要求。

▼ 展开条文说明
6.1.3  模型精细度反映了最小模型单元的划分程度，零件级模型单元不能够再细分，因此不具有模型精细度水平。项目级和功能级模型单元往往是由多个构件级模型单元组成的一个体系，例如建筑电气系统，就是一个集合的概念，因此不具有几何表达精度，只具有信息深度。

6.1.4  交付物应包括建筑信息模型，宜包括属性信息表、工程图纸、项目需求书、建筑信息模型执行计划、建筑指标表、模型工程量清单。

▼ 展开条文说明
6.1.4  BIM的信息传递主要靠信息模型本身完成，因此发挥BIM效益的前提是将信息模型作为主要的交付物。

6.1.5  交付物宜集中管理并设置数据访问权限，不宜采用移动介质或其他方式分发交付。

▼ 展开条文说明
6.1.5  建筑信息模型携带了大量的工程信息，因此信息安全需要得到保障。类似于移动介质这样的交付方式不利于信息安全管理。

6.1.6  建筑信息模型及交付物提供方应保障所有文件链接、信息链接的有效性。

6.1.7  项目参与方在使用建筑信息模型时，应识别和复核下列信息：

   1  模型单元的系统类别及其编码；

   2  模型单元属性的分类、名称及其编码；

   3  模型单元的属性值；

   4  模型单元属性值的计量单位；

   5  模型单元属性值的数据来源。

▼ 展开条文说明
6.1.7  信息应用方在使用设计信息模型时，正确辨识模型单元的组织方式有助于快速并准确定位所需的数据。充分依靠编码信息有助于使用软硬件工具完成辨识过程，也是最直接和有效的信息化手段。在使用属性值进行运算之前，确认计量单位和数据来源非常重要，以避免得出错误的结果。

6.2.1  设计阶段的交付协同宜包括项目需求定义、模型实施和模型交付三个过程。

6.2.2  项目需求定义过程应由建设方完成，并应符合下列规定：

   1  应根据基本建设程序分阶段确定建筑信息模型应用目标；

   2  应根据应用目标制定项目需求文件，项目需求文件应符合本标准第5. 5节的有关规定，并应交付建筑信息模型提供方。

6.2.3  模型实施过程应由建筑信息模型提供方完成，并应符合下列规定：

   1  应根据项目需求文件制定建筑信息模型执行计划；

   2  根据建筑信息模型执行计划建立建筑信息模型。

6.2.4  模型交付过程应由建筑信息模型提供方和建设方共同完成，并应符合下列规定：

   1  提供方根据项目需求文件向建设方提供交付物；

   2  建设方应根据基本建设程序要求复核交付物及其提供的信息；

   3  建筑信息模型设计信息的修改应由提供方完成，并应将修改信息提供给建设方。

6.2.5  设计阶段交付和竣工移交的模型单元模型精细度宜符合下列规定：

   1  方案设计阶段模型精细度等级不宜低于LOD1.0：

   2  初步设计阶段模型精细度等级不宜低于LOD2.0；

   3  施工图设计阶段模型精细度等级不宜低于LOD3.0；

   4  深化设计阶段模型精细度等级不宜低于LOD3.0，具有加工要求的模型单元模型精细度不宜低于LOD4.0；

   5  竣工移交的模型精细度等级不宜低于LOD3.0。

▼ 展开条文说明
6.2.5  模型精细度与工程阶段并不存在严格对应关系，本标准提出最低要求。竣工移交对LOD的要求反而比深化设计可能有所降低是实际情况，因为在LOD4.0时，会出现零件级模型单元，这样细小的工程对象往往并非建筑物运营和维护的主要处理对象。
运维模型与竣工之前的设计和建造阶段不同，往往对几何表达精度不具有特别高的要求，而更关注运维管理对象的信息深度。因此本条的几何表达精度要求比深化设计阶段反而有所降低。

6.2.6  常见模型单元交付深度应符合本标准附录C的要求，表中未列出的模型单元交付深度可自定义，并应在建筑信息模型执行计划中写明。

6.2.7  设计阶段和竣工移交的交付物应符合表6.2.7的要求。

表6.2.7  设计阶段和竣工移交的交付物

   注：表中▲表示应具备，△表示宜具备，—表示可不具备。

6.2.8  施工图和深化设计阶段交付前应进行冲突检测，并应编制冲突检测报告，冲突检测报告可作为交付物。

▼ 展开条文说明
6.2.8  利用建筑信息模型进行冲突检测是一项操作简单、效益较高、应用广泛的操作。为了提高行业建筑信息模型交付质量，特作此规定。考虑到冲突情况比较复杂，值得注意的是，本条未规定模型应当完全消除冲突，事实上做到这一点比较困难也没有必要。但冲突检测操作方有责任说明检测的原则和方法，形成冲突检测报告。
建议将冲突检测报告列为协同文件，也可作为辅助交付物。冲突检测报告可包含下列内容：
1  项目工程阶段；
2  被检测模型的精细度；
3  冲突检测人、使用的软件及其版本、检测版本和检测日期；
4  冲突检测范围；
5  冲突检测规则和容错程度。

6.3.1  面向应用的交付宜包括需求定义、模型实施和模型交付三个过程。

▼ 展开条文说明
6.3.1  建筑信息模型的应用场景较多，不同的应用对信息的需求不尽相同。从应用的角度上看，需要对两个方面问题加以明确。一方面，信息应用方明确提出所需的信息；另一方面，确保信息提供方可以交付应用方所需的信息。

6.3.2  需求定义过程应由建筑信息模型应用方完成，并应符合下列规定：

   1  应根据应用目标确定应用类别，主要应用类别宜符合表6.3.2的要求，表中未列出的应用类别可自定义，并应写明全部应用目标；

   2  应根据应用类别制定应用需求文件，应用需求文件应符合本标准第6.3.5条的规定，并应交付建筑信息模型提供方。

表 6.3.2 主要应用类别

▼ 展开条文说明
6.3.2  本条列出了当前业务实践中的常见应用需求，表中未列出的部分，可自行定义，在本表编号之后顺序扩充。

6.3.3  模型实施过程应由建筑信息模型提供方完成，并应符合下列规定：

   1  应根据应用需求文件制定建筑信息模型执行计划；

   2  应根据建筑信息模型执行计划建立建筑信息模型。

6.3.4  模型交付过程应由建筑信息模型提供方和应用方共同完成，并应符合下列规定：

   1  提供方应根据应用需求文件向应用方提供交付物；

   2  应用方应复核交付物及其提供的信息，并应提取所需的模型单元形成应用数据集；

   3  应用方可根据建筑信息模型的设计信息创建应用模型。应用模型创建和使用过程中，不应修改设计信息；

   4  建筑信息模型设计信息的修改应由提供方完成，并应将修改信息提供给应用方。

▼ 展开条文说明
6.3.4  对建筑信息模型设计信息的应用，包括施于组织等，均应在读取设计信息的基础上，形成相应的应用模型。应用模型是设计模型信息的单向使用，所有应用阶段对设计信息的追加、修改、删减，均应在设计模型中完成，并再次读取至应用模型中。另外，阶段性应用信息，例如楼板的施工段等，均应体现在应用模型中，而不应影响设计模型的建筑本体描述。

6.3.5  面向应用的交付，应用需求文件应作为交付物，并应包含下列内容：

   1  建筑信息模型的应用类别和应用目标；

   2  采用的编码体系名称和现行标准名称；

   3  模型单元的模型精细度、几何表达精度、信息深度，并列举必要的属性及其计量单位；

   4  交付物类别和交付方式。

▼ 展开条文说明
6.3.5  应用需求应作为标准化的一部分，在模型信息输入的时候应充分考虑应用需求，这样可使模型信息更加规范和完备，大大降低返工成本，因此有必要将应用需求以协同文件的形式前置到信息输入方。例如项目审批，需要审批方提前明确所需信息的列表，以及建模要求，这样设计方才可以充分地提供信息，并提交合格的交付物。
应用需求文件应根据应用的特点，尽可能详细列明各项要求，尤其是信息深度尤为重要。

A.0.1 建筑外围护系统分类应符合表A.0.1的规定。

表A.0.1 建筑外围护系统分类

A.0.2 其他建筑构件系统分类应符合表A.0.2的规定。

表A.0.2 其他建筑构件系统分类

A.0.3 给水排水系统分类应符合表A.0.3的规定。

表A.0.3 给水排水系统分类

A.0.4 暖通空调系统分类应符合表A.0.4的规定。

表A.0.4 暖通空调系统分类

A.0.5 电气系统分类应符合表A.0.5的规定。

表A.0.5 电气系统分类

A.0.6 智能化系统分类应符合表A.0.6的规定。

表A.0.6 智能化系统分类

A.0.7 动力系统分类应符合表A.0.7的规定。

表A.0.7 动力系统分类

表B 模型单元属性分类

注：1 表中未列出的属性组和属性可自定义进行补充；

2 属性应分项列举，属性代号应在属性组代号数字按整数顺序依次扩展；

3 系统分类应符合本标准第3.2.2条的规定；

4 关联关系应符合本标准第3.2.3条和第3.2.4条的规定；

5 产品设计性能基础数据应符合现行行业标准《建筑产品信息系统基础数据规范》JGJ/T 236的规定。

C.0.1 模型精细度为LOD1.0的模型单元均可不区分构造层次。

C.0.2 场地工程对象模型单元交付深度应符合表C.0.2的规定。

表C.0.2 场地工程对象模型单元交付深度

C.0.3 建筑工程对象模型单元交付深度应符合表C.0.3的规定。

表C.0.3 建筑工程对象模型单元交付深度

C.0.4 结构工程对象模型单元交付深度应符合表C.0.4的规定。

表C.0.4 结构工程对象模型单元交付深度

C.0.5 给水排水系统工程对象模型单元交付深度应分别符合表C.0.5-1和表C.0.5-2的规定。

表C.0.5-1 给水排水系统交付深度

表C.0.5-2 给水排水系统工程对象模型单元交付深度

C.0.6 暖通空调系统工程对象模型单元交付深度应分别符合表C.0.6-1和表C.0.6-2的规定。

表C.0.6-1 暖通空调系统交付深度

表C.0.6-2 暖通空调工程对象模型单元交付深度

C.0.7 电气系统工程对象模型单元交付深度应分别符合表C.0.7-1和表C.0.7-2的规定。

表C.0.7-1 电气系统交付深度

表C.0.7-2 电气工程对象模型单元交付深度

C.0.8 智能化系统工程对象模型单元交付深度应分别符合表C.0.8-1和表C.0.8-2的规定。

表C.0.8-1 智能化系统交付深度

表C.0.8-2 智能化工程对象模型单元交付深度

C.0.9 动力系统工程对象模型单元交付深度应分别符合表C.0.9-1和表C.0.9-2的规定。

表C.0.9-1 动力系统交付深度

表C.0.9-2 动力工程对象模型单元交付深度

本标准用词说明

1 为便于在执行本标准条文时区别对待，对要求严格程度不同的用词说明如下：

1)表示很严格，非这样做不可的：

正面词采用“必须”，反面词采用“严禁”；

2)表示严格，在正常情况下均应这样做的：

正面词采用“应”，反面词采用“不应”或“不得”；

3)表示允许稍有选择，在条件许可时首先应这样做的：

正面词采用“宜”，反面词采用“不宜”；

4)表示有选择，在一定条件下可以这样做的，采用“可”。

2 条文中指明应按其他有关标准执行的写法为“应符合……的规定”或“应按……执行”。

引用标准名录

1 《房屋建筑制图统一标准》GB/T 50001

2 《建筑产品信息系统基础数据规范》JGJ/T 236