(1)buildingSMART组织
buildingSMART组织的前身是国际数据互用联盟(IAI-International Alliance of Interoperability),成立于1994年。自成立以来,buildingSMART联合多家建筑、工程、产品、软件等领域的全世界知名企业和单位,在北美、欧洲、亚洲的许多国家及澳大利亚均已设立分部。2013年9月,中国建筑标准设计研究院正式成立buildingSMART中国分部。其中,buildingSMART北美分部即buildingSMART联盟,是美国第一部BIM标准(NBIMS)的主要制定者。buildingSMART国际组织对全球BIM技术研发的主要贡献包括:
①IFC标准。自从BIM技术在建筑行业的优势开始受到广泛认同以来,许多软件厂商开始相继研发基于BIM技术的设计软件和协作平台。不同文件格式之间的沟通转换需要统一的数据接口。IFC标准为这种数据接口的开发提供技术依据和准则,为设计文件在众多不同软件和平台之间传输和读取提供便利。
②OpenBIM。这是基于开放的标准和透明的工作流程的一种工作模式,旨在促进设计环节各专业各部门间的协同合作。
③此外,buildingSMART还积极举行各种国际交流活动,以拉近商业软件公司与工程实践用户之间的距离,提高BIM技术研发创新的效率。
(2)IFC的含义、层次
①含义。
IFC是Industry Foundation Classes(工业基础类)的缩写,IFC标准是开放的建筑产品数据表达与交换的国际标准,支持建筑物全生命周期的数据交换与共享。在横向上支持各应用系统之间的数据交换,在纵向上解决建筑物全生命周期的数据管理。1997年IAI推出了IFC1.0版,此后IFC经过20年的完善和发展,截至2016年7月已推出IFC4 Add2标准。
IFC数据模型提供了建筑全生命周期中对象和过程等的一系列定义。它不仅仅定义了建筑构件的几何信息,也定义了建筑构件的非几何属性,以及构件之间的联系。IFC目的是能够描述建筑物整个生命周期中所涉及的数据结构,从初始设计、详图设计、施工图设计、施工、运维管理阶段,以及建筑达到使用寿命之后的拆除阶段所需要的所有相关的数据格式。
②IFC层次。
IFC Schema(IFC大纲)是IFC标准的主要内容,提供了建筑工程实施过程所处理的各种信息描述和定义的规范,这里的信息既可以描述一个真实的物体,如建筑物的构件,也可以表示一个抽象的概念,如空间、组织、关系和过程等。IFC Schema(由下至上)整体由资源层、核心层、共享层和领域层4个层次构建如图4-2所示。
a.资源层(Resource layer):包含了一些独立于具体建筑的通用信息的实体(entities),如材料、计量单位、尺寸、时间、价格等信息。这些实体可与其上层(核心层、共享层和领域层)的实体连接,用于定义上层实体的特性。
b.核心层(Core Layer):提炼定义了一些适用于整个建筑行业的抽象概念,actor、group、process、product、control、relationship,等等。比如说,一个建筑项目的空间、场地、建筑物、建筑构件等都被定义为Product实体的子实体,而建筑项目的作业任务、工期、工序等则被定义为Process和Control的子实体。
c.共享层(Interoperability layer):分类定义了一些适用于建筑项目各领域(如建筑设计、施工管理、设备管理等)的通用概念,以实现不同领域间的信息交换。例如,在Shared Building Elements schema中定义了梁、柱、门、墙等构成一个建筑结构的主要构件,而在Shared Services Element schema中定义了采暖、通风、空调、机电、管道、防火等领域的通用概念。
d.领域层(Domain Layer):分别定义了一个建筑项目不同领域(如建筑、结构、暖通、设备管理等)特有的概念和信息实体。例如,施工管理领域中的工人、施工设备、承包商等,结构工程领域中的桩、基础、支座等,暖通工程领域中的锅炉、冷却器等。
图4-2 IFC层次
IFC对建筑业将带来深刻的影响,可以打破软件数据不兼容的难题。当需要多个不同软件来完成任务时,由于每种软件都有自身的图形内核、数据格式,这给数据的交换和共享带来障碍。IFC作为数据交付的中介和中转站完成数据的无障碍的流通和链接,从而实现最大程度的数据的共享,避免重复劳动,建设设计成本。IFC顺畅的数据流通,会打破软件之间的障碍,对现有的软件市场产生冲击,打破某些常规软件的垄断地位。各大BIM软件商如Autodesk、Bentley、Graphisoft、Tekla等均宣布了各自旗下软件产品对IFC标准的支持,但实现真正基于IFC标准的数据共享和交换还有很长一段路要走。(www.xing528.com)
③IFC的不足。
IFC标准含义丰富,覆盖面广,但由于缺乏准确的定义导致各软件厂商的支持不同,数据转换成了一个很大的问题。除了建立行业委员会设置标准,用户提出需求使软件厂商遵从市场规则,满足软件数据交互要求以外,更应该从完善IFC标准自身来解决上述问题。
解决的思路就是分阶段按特定流程和交换目的来确定IFC的表达,即IDM(Information Delivery Manual,信息交付手册)标准和MVD(Model View Definition,模型视图定义)标准。如图4-3所示,左图表示IFC数据模型涵盖了建筑全生命周期的所有业务需求,而右图表示取特定项目阶段基于特定业务需求来进行IFC表达,即利用标准化的方法定义多个IDM/MVD,分别解决特定问题,既避免了IFC表达的不确定性,又为软件厂商实施IFC标准提供思路。
图4-3 IFC标准与IDM/MVD标准
(3)IDM标准
由上面的描述我们知道,IFC可以(更准确地说IFC的目标是)满足工程建设行业所有项目、所有项目参与方、所有软件产品的信息交换,是整个工程建设行业进行所有设施设计、施工、运营所需要的信息总成,而真正的信息交换是针对某个具体项目中的某一个或几个工作流程、某一个或几个项目参与方、某一个或几个应用软件之间来进行的,即不需要也不可能每一个信息交换都把整个IFC所有的内容都搬出来。那么每一个这样的信息交换究竟需要哪些IFC里面的内容呢?这就是IDM要完成的事情。
举个例子,IFC相当于一个能满足整个医药行业什么药都有的药铺,IDM就是针对某个病人或者某种疾病去药铺里面取药的方子。工程建设行业各个领域的专家通过对所有不同类型的工程项目、参与方、项目阶段需要完成的工作及其需要的信息的分析研究和集体努力,开发出了能包治百病的IFC(IFC本身也是不断发展变化的);从事某一个具体项目、某个具体工作的参与方使用IDM定义他的工作所需要的信息交换内容,然后利用IFC标准格式实施。
一个完整的IDM主要由五部分组成:流程图、交换需求、功能部件、商业规则和有效性测试。流程图与交换需求是IDM的核心。对于指定工作业务,流程图定义了人员角色和信息交换节点。交换需求描述了流程图中的各个具体交换信息细节,为BIM用户之间进行信息交互做出详尽的文字叙述。
IDM标准是否能真正应用到BIM软件,将最终由MVD能否成功实施来控制。MVD是建筑产品模型格式(通常为IFC)的子集,它提供一套完整的信息概念描述,用于AEC工作流中的特殊信息交换。也就是说,针对特定BIM软件之间的特定目的的信息交换,利用IFC标准表达IDM标准,再辅以程序支持,最终实现有效且有用的BIM软件数据传递。
(4)MVD标准
由于AEC领域已经成熟,人们开始意识到协同交互性已经从两个BIM应用程序之间的数据交换转移到支持工作流程所定义的应用案例。协同交互性的好处不仅可以自动交换(尽管在另一个应用程序中复制数据肯定是多余的活动),其还能完善工作流程,消除步骤、改进工艺。因此,协同交互性更好的名称适合叫作“管理精益工作流程”。
IFC可以满足设计师、承包商、建筑产品供应商、制造商、政府部门以及其他单位的不同需求,虽丰富却也冗余。几何、属性和关系的种类很多,可以确定特定的交流或任务所需要的信息。因此IFC是高度冗余的。任务和工作流信息需求被认为是成功交换的关键。“IFC输出”和“IFC输入”的用户界面按键是完全不够的。所需要的是基于IFC架构子集的任务相关的交换例如“建筑师的初步结构分析输出”或者“幕墙制作者详细输出给结构经理以实现建造级别的协调”。这种交换称为模型视图,源自数据库视图的概念。这一个特殊层是确定支持的交然后指定交换所需信息的IFC模型视图。
模型视图是在IFC架构之上的又一个规范等级。美国国家建筑科学研究所(NIBS)和美国智能建筑机构已实现这一规范附加层。美国建筑信息建模标准第1版第一部分于2007年12月发布,它给出了一个开发模型视图的步骤,具体可以参照相关资料查询。MVD旨在从用户的需求和软件厂商的实施中寻找有效的平衡点,通过提供精确、可重复利用的视图定义,实现IDM标准中所要求的交换需求,最终的目的是将IDM中的交换需求转化成计算机可以识别的IFC模型文件,在不同BIM软件中得以验证实施。
(5)IFC、IDM和MVD三者关系
图4-4展示了创建能成功应用于AEC/FM项目的基于IFC的协同解决方案所要经历的各个阶段。从下往上看,底层的IFC Model Specification(IFC模型说明书)指IFC标准格式及其文档,IFC Model View Definitions(IFC模型视图定义)定义了IFC Model Specification如何在不同软件间进行数据交换,IFC Implementations(IFC实施)指软件输入输出IFC文件的能力,Exchange Requirements(交换需求)定义了特定商业流程中的信息交换内容,最上层的ProcessMap(流程图)描述了终端用户工作流程及其目标、所处项目阶段。
图4-4 IFC/IDM/MVD三者关系图[4]
免责声明:以上内容源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。