BIM 应用中建筑与结构专业之间数据的共享与转换

申玮

(北京盈建科软件股份有限公司)

十八世纪中叶以前，民用建筑的建造负责人并没有区分建筑设计师和结构工程师。后来，随着建筑设计和结构设计的理论、方法的持续发展和复杂化，建筑设计和结构设计逐渐分离，并由不同知识背景的专家负责。不过，道路、桥梁领域由于其自身特点，没有出现这种现象。

如今，由于计算机技术已经取得了极大的突破和发展，随之而来的，似乎有一种趋向，即计算机技术和BIM 正在驱动建筑设计和结构设计在虚拟世界重新融合。这实际上是从另一个角度表现出科学技术作为生产力的重要作用，以及科学技术为打破行业壁垒、实现高效生产做出的贡献。

但是，计算机仅仅是助手，而不是主宰。计算机要想达成预定目标，需要人的参与。本文将努力梳理出这个领域的实现路径，希望能为相关技术发展提供一些参考。

1.建筑信息传递标准

长期以来，建筑领域的CAD 技术主要可分为基于图素的策略和基于模型的策略[1]。基于图素的策略以AutoCAD为代表，通过点、线、面另加自定义实体，在设计院取得全面成功。但如今，以基于模型的策略实现的软件正在广泛进入人们的视野，并且使用范围大量增加。

本质上，这并不是二维设计和三维设计的区别，因此，无论是二维设计，还是三维设计，在基于模型的思想指导下，都有可能在专业协同中发挥重要作用。实际上，加强专业协同对建筑全生命周期各个阶段相关参与者的创新活动都有积极影响[2]。通过基于模型的策略实现专业协同时，尤其强调参与方整体系统性的应用和工作创新[3]。

本文重点关注设计阶段的配合问题。首先学习和研究国际上的建筑领域信息传递标准，作为分析的开始。

1.1 Domain specific data schemas

以IFC4_ADD2_TC1 Schemas为例，其中在Domain specific data schemas（领域特定）层级下，可看到IfcArchitectureDomain（建筑设计）、IfcStructuralAnalysisDomain（结构分析）、IfcStructuralElementsDomain（结构设计部件）这三个子类别。

在IfcArchitectureDomain 子类别下，包括IfcDoorStyle（门）、IfcWindowStyle（窗）等。

在IfcStructuralElementsDomain 子类别下，包括 IfcFooting（基础）、IfcReinforcingBar（钢筋）等。

在IfcStructuralAnalysisDomain子类别下，包括IfcStructuralMember（单元）、IfcStructuralLoadCase（荷载）、IfcStructuralConnection（连接）等。

可见，在Domain specific data schemas（领域特定）层级下的数据，是严格区分建筑设计专业和结构设计专业各自特定的内容，不存在相互重叠。

1.2 Shared element data schemas

以IFC4_ADD2_TC1 Schemas为例，其中在Shared element data schemas（共享定义）层级下，可看到IfcSharedComponentElements（组件）、IfcSharedBldgElements（构件）。在IfcSharedComponentElements 子类别下，包括IfcBuildingElementPart（部件，如三明治墙的各层子墙）、IfcElementComponent（附属件，如埋件、连接件等）。

在IfcSharedBldgElements 子类别下，包括IfcBeam（梁）、IfcColumn（柱）、IfcSlab（板）、IfcStair（楼梯）、IfcWall（墙）、IfcCovering（可表示如天花板、地板、踢脚线等）、IfcCurtainWall（幕墙）、IfcMember（支撑、弦杆、梁单元等结构单元）、IfcRoof 等。

以IfcWall（墙）为例，进一步看其属性信息，可分为MOVABLE（如折叠墙）、PARAPET（如阳台边缘防护栏）、PARTITIONING（如石膏板墙）、PLUMBINGWALL（如封闭卫生室中的管道的一个墩或外壳）、SHEAR（如挡土墙）、SOLIDWALL（承重墙，包括现浇混凝土墙和预制混凝土墙）、STANDARD（常规墙，墙厚不延路径变化）、POLYGONAL（多边形垂直拉伸墙，墙厚延路径变化，已弃用）、ELEMENTEDWALL（一种用螺柱框架的螺柱墙）、USERDEFINED（用户定义）等。

可见，在Shared element data schemas（共享定义）层级下的数据，没有按专业区分，一般是各专业共同使用的数据。

1.3 小结

按照IFC Schemas 的思想，意在Shared element data schemas（共享定义）层级，实现建筑设计和结构设计的构件定义融合。

2.跨软件的策略

OpenBIM 提倡不同软件之间通过开放的数据格式，和与之适配的工作方式，来实现建筑设计全流程数据协作。

2.1 建筑设计和结构分析

在Achicad 中，建筑设计数据和结构分析数据可能是各自独立定义的两套数据集。同时，结构分析模型不是一个凭空创建的模型，而是在建筑模型创建好后，作为其物理模型的简化表达。

Archicad 中的模型构件都有一个参数记录承重还是非承重。Archicad 可以基于建筑物理模型的承重部分生成结构分析模型(关于这一相互转换过程中，软件无关的具体实现策略，有相关研究[4]），结构分析模型和物理模型实时关联。比如，当建筑的物理模型发生变化时，对应的结构分析模型将会自动更新。反之，当结构分析模型变化时，理论上，建筑的物理模型也可以跟随。另外，也有关于非承重建筑构件传递到结构分析模型的研究（软件无关）[5]。

建筑设计模型和结构分析模型之间的关联关系主要通过结构分析格式(即SAF,这种格式适合储存和共享结构分析数据)实现。

如图1 所示的例子，是一根梁构件和其结构分析模型的对比。

图1 梁和其结构分析模型（图片来源：Grahpsoft官网）

如图2 所示的例子，是柱构件、墙构件、板构件和其结构分析模型的对比。

图2 柱、墙、板和其结构分析模型（图片来源：Grahpsoft官网）

2.2 建筑设计和结构详细设计

在AchiCAD 中，可能不存在结构详细设计的数据信息，可通过IFC 格式导入其他软件进行详细的结构设计。（根据第一章，在IFC 数据中，Shared element data schemas 规定了导出跨专业共享构件信息的方式，Domain specific data schemas 层级规定了导出结构分析专用数据的方式。）

AchiCAD 的历史非常悠久，其所属公司Graphisoft 很早就在buildingSMART 中活动，长期支持IFC 标准研究。因此AchiCAD 对IFC 标准的支持应该是比较深入的。

在建筑设计模型和结构详细设计模型之间的数据传递中，会涉及IFC 标准中3D 元素和非几何数据。具体方法可能是将构件数据直接一一对应，以墙构件为例，从ArchiCAD 导入结构详细设计软件时，将其直接转化为对应结构软件中的墙定义即可。

如图3 所示的例子。是墙（可从IFC 中导入）在详细设计软件Tekla 中的样子，

图3 Tekla中的墙（图片来源：Trimble官网）

如图4 所示的例子。是墙（可从IFC 中导入）在详细设计软件Tekla 中深化（钢筋设计）以后的样子。

图4 Tekla中墙的深化设计（图片来源：Trimble官网）

2.3 小结

由此可见，ArchiCAD 中的建筑物理模型可利用SAF 转为ArchiCAD 的结构分析模型，然后通过SAF 或者IFC 直接对应其他软件的结构分析模型；ArchiCAD 的建筑物理模型通过IFC 直接对应结构详细设计软件的详细模型。（几何数据直接对应转换。）

3.整合的策略

Revit 将建筑设计和结构设计放到同一个软件中，走出一条以整合策略为导向的道路。有实际项目验证如何使用Revit 与其他软件结合，在项目早期进行项目级各专业设计数据的计算、检验[6][7]；以及在Revit 中异形结构构件形状的创建[8][9]。

3.1 建筑模型和结构模型

在Revit 中，建筑设计和结构设计虽然分属不同的菜单栏，但毕竟属于同一个软件，它们基于相同的构件数据定义。

关于墙的创建，无论在建筑设计菜单，亦或是结构设计菜单下，均可以选择创建non-bearing wall（Wall:Architectural）或者structural wall（Wall：Structural）。

关于柱的创建，无论在建筑设计菜单，亦或是结构设计菜单下，均可以选择创建Column：Architectural（建筑柱）或者Structural Column（结构柱）。建筑柱可理解为包裹在结构柱周围并起装饰作用的几何体。

关于梁的创建，仅可以在结构设计菜单下创建Beam。建筑菜单下没有梁。

关于板的创建，在建筑设计菜单，可以创建roof、ceiling、建筑板（Floor:Architectural）、结构板（Floor:Structural），在结构设计菜单仅可创建结构板（Floor:Structural）。

Revit 的目标是要建筑设计师和结构工程师用同一个软件、基于同一个项目进行日常工作，将建筑设计软件和结构设计软件合二为一。带来的负担是，对于建筑师来说，建模型时就要按照承重或者分承重来布置构件，当然后续结构工程师会调整。由于既不是纯粹建筑设计软件，也不是纯粹结构设计软件，缺点可能是：无论建筑设计师，还是结构设计师，经常会觉得不顺手。

在Revit 中，建筑设计模型和结构设计模型合并处理，本文将其统称为“建筑（结构）详细模型”。

如图5 所示，是Revit 中建立的“建筑（结构）详细模型”。

图5 Revit中的“建筑（结构）详细模型”（图片来源：Autodesk官网）

3.2 结构分析

在Revit 中，结构分析模型依然是独立于“建筑（结构）详细模型”之外的一套单独定义。因此，虽然存在于同一个软件下，仍需一种在“建筑（结构）详细模型”和结构分析模型之间的转换规则。

在Revit 中，结构分析模型理解为“建筑（结构）详细模型”的一种为满足计算所需而对应的力学简化。

3.3 小结

Revit 的定位是信息资源丰富而全面的软件。用户可以从一开始就定义大量详细的建筑和结构设计细节，建筑设计师和结构工程师在同一个软件下，操作不同的数据。

4.装配式建筑

无论是跨软件的策略，还是整合的策略，其目标和理想是一致的。即发明某种计算机技术的实现方式，将建筑设计过程和结构设计过程互通互联，融合工作，使之不再相互割裂，消除设计信息孤岛。专业融合一定有利于提高生产力。

装配式建筑的生产特点决定了其必须进行协同设计。在装配式建筑的设计、建造全过程的BIM 应用中，可以更直接的体会建筑设计和结构设计如何通过BIM 技术实现专业配合。

4.1 跨软件策略

对于装配式混凝土结构，一般会区分建筑设计软件、力学分析软件、详细设计软件。ArchiCAD 的建筑专业物理模型可通过IFC 格式，以几何对应方式导入预制构件详细设计软件（Planbar）。之后，在预制构件详细设计软件中，设计师对模型进行拆分和深入设计工作。预制构件的详细设计软件也可能是一个综合软件，以结构专业为主，同时包含其他相关专业的功能。

如图6 所示，是在Planbar 中对导入的ArchiCAD 建筑模型进行装配式详细设计的界面。

图6 Planbar中进行装配式设计（图片来源：Allplan官网）

对于钢木结构，可以全程在TEKLA 或者CADWORK中进行，包括模型创建、细节深入设计等。但在进行深入设计之前，应先导入力学分析软件进行计算验证。

4.2 整合的策略

Revit 的整合策略中，直接内含了建筑设计、结构分析、详细设计三方面的模型，并通过规划好的数据分类来实现共享。

关于Revit 内置的装配式混凝土结构拆分功能，应该是不局限于结构专业菜单，但是装配式拆分对象规定必须面向结构墙（structural walls）、结构板（structural walls）。预制构件拆分结果以parts 的形式存在。

如图7 所示，是Revit 整体模型中，使用Revit 内置功能进行预制构件详细设计的情况。

图7 Revit内置功能进行预制构件详细设计（图片来源：Autodesk官网）

即便如此，目前为止在国内的设计实践中，结构计算一般都需要借助外部软件；装配式拆分一般借助国内基于Revit 开发的工具集合。

4.3 盈建科内置装配式软件

盈建科内置的装配式软件和结构计算主流程完全融合在一起。实现装配式拆分、结构整体计算、装配式详细设计操作一体化。似乎可以类比为Planbar（Tekla）+Etabs 的组合（当然，国外软件目前在大量细节方面仍然领先较多）。

因此，ArchiCAD、天正等建筑设计软件建立的模型，按照物理模型一一对应的原则转换到盈建科结构软件之后，后续设计阶段的操作一般均可在不更换软件的情况下完成。

如图8 所示，是盈建科内置装配式软件中既可用于结构分析，亦可用于预制构件详细设计的统一模型。

图8 盈建科内置装配式软件整体模型（图片来源：YJK内置装配式软件）

另外，盈建科内置的装配式软件已经逐渐迁移到了自主BIM 平台。实际上，BIM 平台下的装配式软件，装配式拆分的对象并没有区分建筑模型还是结构模型。但通常情况下，一般可与Revit 类似地，针对BIM 模型中的结构墙、结构板进行拆分。这应该也是预制构件拆分的本质目标。

5.总结与展望

目前，为达成建筑设计和结构设计专业协同的目标，共同的思路本质是：操作区分专业，数据实现统一。也就是说，在计算机交互操作层面和存储数据层面，按照各自特点分别处理，最终实现两个专业的融合。具体实现方式上，可分为跨软件的策略和整合的策略。前者强调建筑设计数据的几何特性为中心，可对建筑设计数据的物理几何信息转化为结构分析关系，或者将这些物理几何信息按照几何一对一的原则转化为结构详细设计软件中的模型；后者让建筑设计师和结构设计师在同一个软件下操作各自的数据，其中部分操作数据是专业之间共享的数据，核心思想是软件框架统一[10]。

以这样的BIM 方案为基础，技术应用正在空前高涨，例如，有很多项目在全产业链的协同设计、施工过程中，尝试引入可视化VR 等其他技术[11][12]。

具体的实践过程中，还应关注其他非技术的问题。比如，在各专业之间逐渐实现更加紧密的配合之后，随之而来的是设计师的创新型设计和想法的版权更易被侵犯[13]。再如，合作者之间应该采取有效的合作行为，支持一体化的合作模式，才能更好的实现协同目标[14]。

实际操作中，可能会遇到各种障碍，还需要在工作中发现问题、解决问题，迭代实现技术进步和完善。