运维阶段BIM模型的关键要素
众所周知,在BIM的理念里,建筑全生命周期中,BIM数据是一个被循环利用和增量附加的过程,从设计——施工——运维是逐步深化的过程,但每个阶段的BIM数据因为其应用场景的不同,都有其关键的要素和特征。因为运维阶段更加关注于空间、系统拓扑以及运维数据的关联,相较于设计和施工阶段,运维阶段的数据要更加侧重于BIM数据提取,以及模型视图的应用。在运维阶段,BIM数据中的关键要素主要有以下几个:
设施对象:运维管理中,“设施”是管理的基础元素之一,设施可能是一个设备,系统、结构物或者其它任何可能被用于管理的对象,这个对象与BIM模型的模型对象是紧密关联,但又不是一一对应的,其之间的关系应该是一个组合和分解和关系,一个设施对象,可能由BIM模型中几个模型对象组合而成,也可能是BIM模型中一个模型的一部分,比如说,一个电梯系统,在运维管理中,可能是按照一个设施对象来管理,但在模型中却是多个模型对象组成。所以,运维阶段,直接用现有BIM平台软件创建的BIM模型,在没有经过二次加工和运维平台二次组织的前提下,是比较难以直接应用的。
空间对象:空间管理也是运维管理中的一个重要内容,但在目前的BIM软件中,并没有原生的“空间”对象概念,所以,这也是运维阶段,需要对模型和数据结构进行优化的一个重要环节。
属性数据:数据是BIM的核心所在,对于模型中的属性数据的提取、组织和再利用,是运维平台中数据处理的第一步,也是关键的一环。属性数据是BIM模型中的原生数据,方便的查看、检索属性数据,才可以将BIM的价值在运维阶段充分发挥。
实时运维数据:这个是数据是一般由BA系统提供,是建筑物实时产生的运维管理数据,比如能耗、温湿度、空气数据、外部环境等等。
视图:在没有BIM这个概念之前,运维管理也一直在进行,之所以BIM在运维阶段有广泛的应用价值,其可视化的特征是关键因素之一。因为BIM可以是三维化的,所以使得在运维可以变得更加直观和准确,而不仅仅是依靠文字描述。没有BIM,一样可以进行运维管理,但通过BIM模型这样一个更加直观、形象的交互环境,可以使得运维更加容易且高效。
元数据:运维阶段,只有属性数据、实时运维数据、视图数据还是远远不够的,需要有大量的外部数据做支撑,比如设备的厂家资料、维修记录、二维图纸等等,如何以结构化的方式来组织这些外部的非结构化的元数据,也是运维管理系统需要认真的关注的另外一个核心功能。
系统结构:设施、空间这些基础对象,需要进行合理组织,使其更加方便高效的应用于运维,同时,因为运维系统中需要对接大量的外部数据,所以其编码体系及标准显得尤为重要,没有唯一的编码,就没法再众多系统中进行数据关联,所以系统结构是运维平台数据组织的核心。BIM平台软件对于模型对象的组织,是按照其软件设计来,而不是专门针对于某个应用领域来,所以将模型数据直接导出,应用于运维管理是不可取的,也是行不通的,所以必须要进行再组织和再优化。
综上几点,BIM数据应用于运维的过程,就是一个将BIM数据再组织和利用的过程,以BIM数据为基础,经过重新的优化、数据提取、转换,依托一个BIM数据交互平台,以图形化的方式将不同数据源的数据集成、分类,结合运维管理的需要进行合理、高效的展现。
BIM数据重组及运维数据构建
在这个环节中,考虑到在目前建筑市场中Revit的主导地位,所以BIM平台这块就选择以Revit为例进行描述。基于以往的经验,我们将数据重组和构建的过程划分为三个环节,分别是:BIM模型二次、基础BIM运维模型创建、运维BIM模型创建。
BIM模型二次
通常,我们用于运维阶段的BIM模型有两个途径获得,从设计、施工阶段直接转换,直接基于BIM平台按照运维需要创建。但无论是以上哪一种,我们都需要对BIM模型进行改造,才可以满足后续应用的需要,所以我们将这个环节称为“BIM模型二次”,究其原因,运维系统的构建,一方面是基于运维的业务需求,一方面也要考虑我们在系统中采用的BIM模型交互平台的功能,毕竟在现阶段,为运维系统来开发一套展现BIM数据的图形平台是不太现实的,所以需要结合以上两点对BIM模型进行改造和优化。在目前市面上,与Revit结合的比较紧密的用于运维阶段的BIM数据交互平台大致有这么几种,免费的,AutodeskDesignReview,收费的,AutodeskNavisworks,随着目前Html5逐渐成为主流,现在也出现了第三方的基于WebGL的零客户端纯浏览器跨平台方案,但也有一些诸如基于IFC,或者基于GIS平台的,但因为存在数据转换、效率等问题,短期内还难以有广泛应用。考虑大家的熟悉程度和流行度,此处我们暂以Navisworks为运维阶段的BIM数据交互和展现平台来表述。这个阶段的主要工作如下图所示:
模型优化:这部分主要是面向运维的需要进行模型的重组,为后续转换和应用建立基础,比如下图所示,模型中的对象的组织、空间划分、系统拓扑关系的建立要严格按照运维阶段应用的需要,同时为了方便后期的使用,需要添加对应的空间标识及其它Tag数据,方便后续与外部系统的数据对接。
视图创建:为了更好的进行设备定位和空间表达,视图是关键所在,举例而言,如果我们需要在15万平米的建筑中定位一个空调箱,如果我们是以整个模型的视图来辅助定位,那肯定是非常灾难的事情,一方面,在这么大的尺度下显示这么一个小的构件是非常糟糕的体验;另一方面,因为大量构件的遮挡关系,在执行自动Zoom操作的时候,很难有好的视角,所以这个时候三维的优势被大大削弱。为了解决这个问题,应该实现创建大量合理的视图,使得不同的对象都能有比较合理的视图进行展现和表达,如下图所示,针对不同系统、不同区域,预先在Revit中建立视图,具体建立的视图的区域和数量,要预先考虑运维的需求。所以目前的传统做法,先由建模人员建立好模型,直接导出后用于运维,这个是很不合理的,这种做法对于一个很小面积的建筑物是可行的,对于一个任何大体量的建筑物,这种做法就只能是用于演示了,是没有实际操作性的。
属性优化:这个概念相对比较容易理解,我们需要为了运维的需要,添加一些运维可能需要用的属性数据,虽然在运维平台中需要对属性数据进行二次加工和录入,但基础模型中的属性数据也可以作为后续的数据来源之一。
系统分类:在模型建立阶段,就需要考虑系统的划分,否则后续模型一旦导出,再进行模型的分解和重组,难度就会成倍增加。为了后续更加高效,在基础模型中需要对系统进行分类,通过Revit的共享参数、视图进行标识和展现,这样模型在轻量化转换后,依然可以高效组织。
这个阶段的成果就是得到一个符合运维需要的经过优化的BIM模型,这个模型经过转换就可以得到一个轻量化的基础BIM运维模型。
基础BIM运维模型创建
基础BIM运维模型的建立,如果对应到Navisworks的化,就是一个自动转换的过程,将Revit模型通过插件,或者由Navisworks直接打开,从而转化为一个轻量化的Navisworks模型,我们称这个过程为自动转换,但这个过程是不可控的转换过程,因为转换的过程对用户而言是一个黑盒过程,是外部无法干预和调整的,使用自动转换的平台,好处是开发工作量少,稳定且经过验证,但缺点是可控性小,需要前期对模型处理的比较精细,比如共享参数、视图的处理要完善合理,因为一旦转换之后,再想增加图元、参数,那就需要重新导出,过程繁琐,无法实现局部或者增量转换;此外,尤其是有大量链接模型的Revit项目,因为对象ID可能发生重复,如果我们在运维平台中已经经过二次处理,那么这种反复导出,可能导致数据错乱。如果采用可控转换,可以避免以上的问题,但可控转换的开发量比较大且复杂,但从未来的方向看,随着运维平台的成熟,可控转换时一个必然的途径。转换后的基础模型元素如下图所示:
几何数据:从Revit中的数据转换之后,我们更加关注的是体现在轻量化模型中的大量的几何数据体,虽然乍一看起来似乎不合理,按照BIM的理念,我们应该关注的“BIM构件对象”,但正如“关键要素”这一节中描述,运维的对象和BIM中的对象是不能一一对应的,需要进一步经过加工和组织,所以几何数据体反而为我们的后续组织加工提供了便利。
视点:Revit模型中的视图会被转化为视点,这个目前基本可以实现一一转换,但这儿会有一个很大的缺憾,就是二维视图是无法直接转换的,如果要实现二维的查看,且和三维关联,那么这儿需要一些再处理,比如通过DWF来桥接处理。
基础属性:目前从Revit到Navisworks,对象属性基本可以完整转换,但由于Navisworks的选择树种的模型组织可能会有一些不合理的地方,所以,对于属性的组织和调整,需要结合转换和手工编辑来进行。
模型结构:众所周知,如果采用自动转换,Revit到Navisworks后,Navisworks选择树的结构还是有些“惨不忍睹”,尤其如喷淋、风口、楼梯这些对象,分类往往是不正确的,所以此处需要利用Navisworks的搜索功能,结合选择集来重新组织模型结构,这也是上述提及要规划好模型的共享参数的原因所在,否则,模型结构树的建立和优化是一件极度让人崩溃的事情。
完成了基础模型的构建之后,就可以进行运维BIM模型的建立了,这个过程就是运维平台所应该具备的功能,是需要进行定制和开发的内容。
运维BIM模型创建
此处着重于表述符合运维需要的BIM模型的建立过程,至于运维过程中的数据映射、表单、流程、权限等等基础业务框架不在这儿讨论。运维BIM模型创建的过程是一个模型和数据重组的过程,一个灵活的系统一定低耦合的系统,我们的传统做法中,从设计到施工再到运维,用一套建模思路,一个模型,这在当前的技术条件下,是很难实现的,但目前的市场状况还恰恰就是这样,由设计单位或者施工单位建立了一个模型,然后移交给业主来用于运维,这里面,先不讨论设计或者施工是否懂运维的业务和流程,单就模型的组织和关注点而言,和运维需求之间的差距就是非常巨大的,所以,此处就需要一个运维阶段的模型处理平台,能对这些模型进行再组织,降低不同阶段之间的耦合度,充分利用既有模型。
如上图所以,运维BIM模型中,通过下图我们可以看出一些需要重点关注的对象。
系统结构树:这个系统结构树一定不是来自于BIM模型,而是按照不同项目、不同业务需求由运维人员来创建的;同时,系统结构树的建立,也是一个编码形成的过程,是对建筑设施进行编码和组织的过程,是数据创建的核心环节。如下图所示,这个功能是运维平台的基础功能,在系统结构建立的过程中,可以给每个系统指定合理的二维、三维视图和需要具备的基础参数,设定好合理的视图对象后,这个系统中的对象的显示和定位就使用此视图。
运维对象:如上所述,运维对象是需要对模型进行重组和指定,如下图所示,运维对象的建立其实是通过选择基础BIM模型中的对象来重建的,这个运维对象是在运维系统的数据库中来管理的,而不是BIM模型中的对象,同时在建立运维对象时,需要给其指定参数模板来设定其必须的运维参数,此外,我们还需要为对象指定视角,使得我们在定位对象时,能清晰合理展示,对于一些特殊对象,还需要建立其拓扑对象,比如一个风机会影响的区域和风口,需要通过拓扑来标识。
参数、属性:这儿的参数和BIM模型的属性数据不是一个等同关系,运维中的参数是BIM属性数据的一个超集,其不仅仅包含属性数据,还包含后续不断丰富的为满足运维需要的属性,同时也包含实时的运维参数。运维阶段的参数属性数据的维护也应该由运维平台来完成,如下图所示,我们需要为不同类别的运维对象建立参数模板,对于BIM模型中既有的模型数据,可以直接提取,对于没有的数据,需要通过录入或者从业务数据中提取,尤为关键的,是要通过编码将属性字段和实时运维数据字段对接,实现数据的关联,进而能实现双向的互动。
暂无评论内容