Engineering SHEET: /blog/对于openbim有ifc就够了吗/ REV: 2023-03-22

对于OPENBIM，有IFC就够了吗？

上叶侬发布于 2023-03-22 12 min read

对于OPENBIM，有IFC就够了吗？

公众号：非解构 · 作者：上叶侬（用户提供链接，标记为上叶侬）

如何通过BIM串联起传统的建筑设计流程，提升整个设计流程的质量和设计的效率？这个课题一直是很多设计师和工程师在探讨和研究的问题。当下有两个主流的解决方案：一个是由Revit为代表的希望能够在整个设计流程中做到面面俱到，能够让自己的工具渗透到设计的方方面面的方式的技术路线。由于Revit本身的笨重，这个方案一直被广大的设计师和工程师做诟病。虽然探索该技术路线的团队前赴后继，但是鲜有成功的案例。

另外一个是以Archicad为代表的通过OPENBIM的方式，整合当下各个专业各流程现有的工具和工作模式的技术路线。这个技术路线一直被很多建筑师称道，有很多建筑师确实从Archicad中尝到了甜头，而Archicad一直倡导OPENBIM的技术路线。作为龙头专业，很多建筑师也寄希望于OPENBIM的方式，改进当下的生产模式。

在OPENBIM生产方式架构的设想中，建筑，结构，暖通等各专业和设计，施工，运维等建筑生命周期各阶段需要用到的数据，都可以通过IFC进行交互。很多人对IFC报以崇高的期待，觉得这是解决绝大部分BIM软件之间格式交互问题的救星，甚至是打通传统设计软件和BIM设计软件的关键桥梁。

那么，什么是IFC？

IFC是Industry Foundation Classes的简写，它的的历史可以追溯到1994年。IFC是互操作性行业联盟（Automotive Alliance for Interoperability）的产物，该联盟是由Autodesk建立的。该联盟于1997年成为国际互操作性联盟，现在被称为buildingSMART，这是一个非营利性组织，自称为openBIM的国际总部。

IFC是不受平台限制的开放文件格式规范，不受单个供应商或一组供应商的控制。它是一个基于对象的文件格式，数据模型的开发buildingSMART（原国际通用性联盟，IAI），以促进互操作性在建筑，工程和施工（AEC）行业，并且是一种常用的合作形式建设信息基于建模（BIM）的项目。IFC历经1.0、1.5、1.51，然后是2x，2x2、2x3 和4版本。IFC模型规范已公开并可用。它已通过ISO注册，是正式的国际标准 ISO 16739-1:2018。

IFC提供了关于IFC数据结构的完整的文档： https://standards.buildingsmart.org/IFC/RELEASE/IFC4/FINAL/HTML/

IFC包含了大约800多个实体，358个属性集和121中数据类型。这样一个庞大的数据体系，囊括了建筑生命周期中的方方面面。面对这样一个面面俱到的体系，小编的第一感觉真的就是它能帮助我解决很多问题。小编先前也尝试解析了一些IFC模型，获取其中的数据。在这个过程中，小编也确实产生了一些疑问：

表达能力强=数据可用？

小编在进行一些IFC相关功能开发的过程当中，确实感受到了IFC的强大。按小编的理解，建筑本身是由许许多多的几何单元构成的，不管是建筑构件还是建筑空间，都可以通过几何的方式进行表达。而建筑信息模型，本质上是以几何信息为基础，附带一些额外定义的建筑信息。以柱子为例，可以通过一个立方体进行表达，再附上混凝土标号等信息，就构成了这个柱子在BIM模型中的定义。IFC中，以IfcColumn作为表达柱子的数据格式。我们可以通过IfcColumn中的IsDefinedBy属性，获取构件的任意属性。我们也可以通过IfcColumn中的Representation和ObjectPlacement属性，获取构件的几何形状和坐标信息。

来看几何信息，随着了解的不断深入，小编确确实实地在感慨，IFC的几何信息的表达能力真的是强大，可以用“包罗万象”来形容。

IFC的Representation属性由IfcRepresentationItem来表达。其中，又以IfcGeometricRepresentationItem和IfcTopologicalRepresentationItem这两个数据类型来表达几何体。

还是以一根方柱为例，我们可以有多种不同的方式来对他进行表达，以下简单地举两个例子：（1）通过IfcExtrudedAreaSolid构造拉伸体。通过IfcProfileDef定义柱子的横截面，通过IfcDirection和IfcPositiveLengthMeasure定义柱子拉伸的方向和长度。

（2）通过IfcFacetedBrep构造柱子的Brep。所谓Brep是Boundary representation的简称，通过角点（Vertex），边界（Edge），面（Face）和实体Brep，共同描述一个几何对象。对于一个六面体的柱子而言，我们需要定8个角点，12个边界，6个面。这是一个通过拓扑关系表达的几何体。同样的，我们也可以通过IfcTopologicalRepresentationItem下的IfcClosedShell来表达这一关系。

对于建筑专业而言，如果只是简单的希望获取构件的形状，上述表达方式可能已经能够满足相应的需求，但是对于其他专业而言，这些表达方式似乎并不足以满足要求。比如要生成结构的有限元模型时，一般通过一根线和一个截面来表达这个柱子。如果是IfcExtrudedAreaSolid这种表达，我们如何通过IfcProfileDef获取构件的截面呢？我们又如何通过IfcDirection和IfcPositiveLengthMeasure获取柱子的轴线呢？而对于IfcFacetedBrep构造的柱子来说，这似乎变得就更加困难了。IFC模型到结构设计模型的转化，中间需要通过一系列的几何运算。从这个逻辑来看，IFC只是做到了显示层面的大而全，但是并没有完全地考虑每个专业对数据的个性化需求。我需要某根柱子的时候，它确实能够给我提供这根柱子的相关信息，但是它并不能直接提供我想要的信息。

再来看IsDefinedBy定义的构件额外的属性。IFC中通过定义若干IfcPropertySet来表示要贴在构件上的额外属性。IfcPropertySet中又定义了若干IfcProperty。IfcProperty的数据结构可见下图。我们可以通过布尔值，列表，字符等等的数据结构形式来表达构件的属性。

来看某个构件的IFC属性：

确实，IfcProperty给了我们相当大的自由度来描述建筑构件，可以说，从数据多样性的角度上来说，这种设计真的是无懈可击。但是，这又带来一个问题，当我解析相应的IFC模型时，我需要按照明确的IFC模型相关数据的说明，对它进行解析。当某些数据不是那么一目了然，我们无法明确地知道它的含义时，或者数据的定义和我们之前的理解有错位时，是否能正确解析相应的数据，获取我想要的信息就成了一个问题。

数据全=平台间的无缝对接？

IFC标准确实能够非常全面地表达一个结构，很多朋友都都认为，它的这种强大的能力能够解决跨专业，跨流程之间的BIM数据交互问题。小编在这里不得不打上一个问号。

举个很简单的例子，我们把Archicad中的数据导出到IFC，然后再把它导入的Revit，然后再把Revit中的数据导出，再反向导入的Archicad中。此时，我们能保证最终Archicad中的模型和最开始导出的那个Archicad模型是一个模型吗？大概率下是很难保证的。

因为IFC数据在传递交互的过程中，存在一个平台间表达方式或者表达的标准不一致的问题。我在表达一个柱子的时候通过什么样的集合体表达？我在表达柱子的属性的时候通过什么样的属性和字段表达？只要有一点的兼容性的问题存在，我们就无法完全保证数据的准确性，或者可靠性。

其实这里就牵涉到了数据的加工方和数据的使用方之间对接交互的问题。确实，我们的IFC数据的表达能力很强，它能够满足我们方方面面的需求。此时，数据的使用方就要和数据的加工方达成某种协议，明确对数据的需求和对数据的表达方式的需求。只有双方在共同的默契下协同工作，才能保证IFC交互过程中数据的可靠性。

在BIM在产业链推进的过程中，大家一直在强调数据标准对各方协同的重要性，大家也确实看到了IFC强大的能力，能够满足大家对BIM数据的方方面面的需求。小编理解，IFC某种程度上处在一种成也萧何，败也萧何的状态。确实，表达能力强能够让尽可能多的人聚集在这个标准下。但是，表达能力强也代表了具体，但又不是那么具体的状态。基于IFC,看起来完全相同的数据，可能有无数种表达方式。我们需要拿到正确的钥匙，才能正确地使用相应的数据。相当于说，IFC是一个宽泛的数据结构，具体使用的人，还要基于这个数据结构，制定一套自己的交互标准。

当下，大部分软件厂商可能都处在一种各自为战的状态，充分体现了数据的自由度，但是很少考虑数据间的兼容性。

写在最后

在小编看来，其实IFC标准和我们之前用CAD画图本质上是一个概念，每个设计院都有自己的一套图层系统，都有一套自己基于CAD的协同方式。而基于IFC下的工作模式，并不能改变这种状态，只是把主语从每个设计院变成了每个软件厂商。而软件厂商之间的鸿沟更是难以弥合，因为每个软件厂商都有自己的专业领域，都有自己对数据的理解和需求。确实每个厂商都能基于IFC表达自己的数据，但是每个厂商都能让上下游正确且没有什么障碍地使用自己的数据吗？最后回到本文的标题：对于OPENBIM,有IFC就够了吗？

加入QQ群（3群），我们一起来探索 YJK-GAMA的无限可能！