BIM模型建完了,深水区怎么游?

你好,这里是BIMBOX。
今年为了让更多的朋友把他们的经历和思考讲给大家听,我们建立了BOX作者群,群成员和投稿的作者一起努力打磨出一篇好内容。实验一段时间下来,我们觉得效果还不错,因为大家在群里是基于一篇文章深入讨论,聊的东西就是有边界的,而不是天马行空想啥说啥,所以更能凝练一些精华出来。
今天给你捧出来的这篇分享,来自于我们的一位老朋友,上海水石建筑规划设计股份有限公司BIM中心负责人、上海BIM推广中心专家库成员,他的名字叫金戈,网名叫铁马,是不是很霸气?

金戈在BIM行业摸爬滚打了十几年,带过团队、做过咨询、做过平台研发、参编过上海BIM数据标准,在梅赛德斯奔驰中心项目、广州地铁总公司BIM咨询项目、亚特兰蒂斯水上乐园项目、北外滩改造等项目都留下了足迹,我们和他在线上和线下也都有过交流,经常讨论的一个问题就是:BIM走了这么多年,下一步数据和信息该往哪里去?
这次,金戈就专门把他这些年的探索写成一篇文章,在作者群里改了三稿才最终分享出来,以下是他的分享。
2008年,我在上海世博会一个项目提供三维设计服务时,第一次听到别人把三维模型说成了「BIM」。在这之前,我己经从事机电的三维设计多年了,一直不知道如何向别人介绍自己的工作。
2010年时,我第一次参加一个BIM活动,听到大家在讨论模型。我当时就提问:我已经能创建一个很好的模型了,后面需要做什么呢?难道做个模型就是BIM吗?当时,在场没有人能答复我。以后好多年,这个问题一直困扰着我。从此,我一直在探索一个问题:BIM的终极是什么?该如何实现它?
2014年,我进入上海一家国企,系统地接触了各种BIM资料,算是入了BIM的门,尤其是其中的欧美书籍和文献,让我受益匪浅。其中以下资料,我个人觉得非常有价值:
《BIM手册》,宽泛定义了BIM的概念,以及未来发展。其中对未来发展的预判,放到现在几乎全部都应验了。例如:业主在合同条款中要求BIM;制定标准的工作在全面进行等。
《业主方的BIM》,制定了一个评分标准来说明企业引入BIM技术的深度,从技术、流程等6个角度,用定量打分的方式来分析。
《FM经理的BIM》,别被书名误导,这本书不是讲如何利用BIM来做运维,它通过很多案例来说明一个项目从施工延续到运维需要哪些事。
《BIM实施指南》,具体阐述了一个项目完整实施BIM的各种要素,虽然很多地方不适合中国国情,不过提供的思路很值得学习。
《BIM协作系统研究》,详细介绍了BIM协同平台应该具备的功能,以及美国市场上协同平台的功能打分,对国内平台开发很有价值。
《COBie应用指南》,这本书的价值在于让我这样的IT小白能明白COBie是什么,它其实不是什么高深的东西。
《ISO19650》,这本标准介绍了一种系统性实施BIM的路径,有些东西和《BIM实施指南》想法是一致的,例如需求导向。每个项目业主确定需求了,然后根据需求展开BIM应用。但是,国内很多项目是没有需求的,就是政策要求用BIM。
以上资料,我基本都翻了10遍以上,逐渐对BIM也有了越来越深的认识。建筑工程的前辈希望能学习工业领域的三维设计方式,通过计算机技术,实现建筑工程的虚拟建设,从而实现整个项目建设的可控,减少各种浪费。这个初心是非常美好的,还出现了下面这张流传很广的图。

但是,在翻遍了国内外各种案例后,我发现这是个美好的梦。或者说,BIM还停留在理论阶段。在实际案例中,我还没见到一个项目能实现图中所展示的:项目各方围绕着BIM实现信息共享,从而提高项目质量等等。
应该说,很多项目实现了BIM的一部分,主要是几何信息的优化,提高了设计图纸的质量。在《BIM实施指南》中,详细介绍了BIM常规的25个应用点,也很值得大家学习。
于是,如何实现BIM模型,特别是非几何信息的共享,成为了我想要研究明白的题目。我走过的研究道路是下面这样的。

 

第一步

创建数据标准 

首先,什么是非几何信息?非几何信息应该包括哪些内容?在几乎所有国家的定义里,BIM都应该包含几何信息和非几何信息。我们还是比较容易的应用了几何信息,也带来了一些价值。那么非几何信息呢?我很少看到有项目应用。

《COBie应用指南》里有这么几句话:
 
COBie标准的目的是随着工程进展,当项目团队在创建数据时就以BIM为载体获取它们,并在项目全周期内进行安全共享和更新。从承包商角度看,COBie就是将当前的纸质材料转换成便于操作的在线数据。

在参考了COBie的相关资料后,我和我的团队,自己编制了一份数据标准。其实所谓的COBie标准,就是一个独立的、设施设备从设计到运维数据的结合。里面包括命名、编码、空间、价格、系统等等。

我们第一次编制的时候,把参数简单的分为两类:技术参数和非技术参数
技术参数主要包括各种数值型参数,例如长度、宽度、高度、风量、水量等。
非技术参数主要包括各种文本型参数,例如设计人员、施工人员、维保人员、工艺工法、控制开关、联系电话等。
但是把这些参数随意混杂到一起录入到模型中,发现太乱了。

后来,我们做了改进,把所有数据分为8个大类,重新导入模型后,发现一下子清爽很多,就一直沿用到现在。这八个大类分别是:

➤ 身份参数    ➤ 尺寸参数

➤ 设计参数    ➤ 关联参数

➤ 商务参数    ➤ 产品参数

➤ 施工参数    ➤ 运维参数

第二步

数模分离管理 

有了一份可以用的数据架构后,怎么和模型结合呢?
关于对数据的主流管理方式,我了解的就两个,一个是老外提出的IFC标准,包括上海交大、清华大学等高校在研究。另外一个是黄强老师提出的P-BIM,一种基于数据库的管理方式。我观察这两种方式目前都是在理论阶段,市场应用还不够成熟。
我们首先测试了一下IFC和Revit的联动,把一个集合了多种构件的REVIT模型导出为IFC,再重新导入REVIT,发现各种数据丢失严重。在下面的图里,原来360个构件只剩下286个。

另外,一半模型的几何数据可以编辑,一半模型无法编辑。几乎所有模型的非几何数据都有部分丢失,甚至全部丢失。
后来,我们把另外几个BIM建模软件生成的模型导出IFC,再导入REVIT。也出现类似的情况,几何数据基本存在,但是无法编辑,非几何数据大量丢失。
我们没有很多IT人员,也不想花时间去研究到底是什么原因导致了数据丢失。从应用的角度,我们认为IFC这条路暂时走不通。
那么,我们该如何实现数据管理呢?带着这个问题,我们开始研究各种资料。正巧,在《FM经理的BIM》这本书里,有类似的文字提醒了我:

BIM的数据资料可以通过传统数据库的方式来管理。

既然IFC不行,我和团队成员们开始尝试数据和模型分开管理,我们暂且称之为数模分离。而最简单的数据库就是EXCEL。
在讨论这篇分享的时候,@小耳朵猫酱说了这么一句话:

数模分离的本质就是,改变依赖模型带数据的模式,把编码作为挂接图形的风筝线,独立存储和处理数据,并且可以通过工具,在轻量化Web/客户端组装。

我认为她的说法是对数模分离又专业又通俗的解释。
确定了数模分离这个逻辑后,接下来就是大量试错工作了。我们团队开始大量测试各种BIM软件,国内不行就找国外的。
2015年,我们找到了解决方法,可以实现把EXCEL表单中的数据批量导入模型。数模分离第一步,也就是线下表单和模型分开管理的路径算是通了。但是,这还不够,我们的目标是实现基于Web端的轻量化管理。

 

第三步

构件编码 

第三个问题接踵而来,那就是怎样方便区分不同的构件类别。
2016年,我找到一份国标分类编码的意见稿,里面提到了各种ISO和OmniClass的编码逻辑和元素表单,觉得可以利用一下。
学习下来,14号表和30号表比较接近。当时就先无脑直接抄了14号表。可是用下来,才发现问题没那么简单。
首先,14号表是按照设计逻辑划分的,分成了建筑、结构、暖通、给排水和电气。而我们的数据是全过程的,到了施工阶段,要按照分部分项、以及WBS来划分;而到了运维阶段,是按照资产管理的角度来划分,14号表就更不适用了。
另外,一些设备的划分会混乱。例如泵,同样一个产品既可以用在空调水泵,也可以用在给排水泵,会重复出现,这可是编码的大忌。
在多次试错后,我们放弃了14号表和30号表,按照我们自己的逻辑来进行编排,设备参数的管理能保持一致的,就归为一类,编排的方式参考了国标的8位数字来写。
但是,光是有分类编码只能确定某一个构件的种类,无法定义它的唯一性。所以我们在分类编码基础上,又编制了构件编码。比如下面这张图,就是我们构件编码的一个案例:

在图里,前面10位是分类编码,是参考国标自己编写的;后面的规格编码是根据设备种类编写的,位置码主要包括楼栋号和楼层,最后是流水号。案例的这个编码代表了:型号01的离心风机,布置在1号楼的屋顶层的第一台。基本上可以实现每台设备的唯一性,类似身份证号码。
因此,我们从技术角度,实现了非几何信息的批量处理,也和模型实现了对接。下一步就是如何能真正应用起来,把工作从线下搬到线上。
 

第四步

公共数据环境CDE 

早在2015年时,《BIM协作系统研究》已经提到了这样的话:

现有的协作依赖于电子邮件和文档,而为了模型协作,需要一个复杂的公共数据环境(CDE)。CDE方便对模型数据执行协作操作,涉及用户管理和支持用户需求的功能。

而在最新的《ISO19650》中,对CDE有了更加清晰的介绍:

CDE 解决方案同时包含管理信息载体属性和元数据数据库的功能,也具备向团队成员发布通知的功能,且能维护信息处理的审核轨迹。

 

第四个问题就到了如何创建CDE,解决非几何信息的共享问题。
2019年,BuildingSMART大会在北京召开。我加了这次大会,结识了不少业内同行,也学习了不少最新的BIM知识和来自欧美的新技术。其中一款在线产品,让我联想到了CDE。
接下来的情况,又是老套路,不停的试错。终于可以实现我心目中的CDE了。
在这个Web产品里,可以实现分类编码一键上传,然后每个构件都可以分配到相应的编码下面,挂接属于它自己的一套数据标准。我们为每个构件编写了详细的数据标准,用户可以在平台里直接调用设置好的构件。同时,所有项目参与方可以基于Web端,在线输入每个构件需要的信息,也可以分享他人的信息。

至此,我们实现了从数据分类到数据标准,到数据共享的过程。
 

第五步

标准共享 

一开始,我们是纯从技术角度来探索几何模型和非几何数据的分开管理。但是到这一步的结果,为困扰我的两个问题提供了新的解决思路。这两个问题分别是:
BIM的本质是资源共享,可是很多公司都在分别建族,然后出现大量的重复劳动。
业主在要求项目交付模型的时候,无法明确交付模型携带的信息到底是什么。
第一个问题,其实有不少人在做。网上可以搜索到很多类似的族库共享网站,有些还在更新,有些已经逐渐隐退。我认为这些族库软件都比较相似,而且缺少对非几何数据的管理能力。
第二个问题,目前我们没有找到任何其他公开的产品能实现。
我们的计划是,把所有能找的各个类别的族,都加载我们的数据标准,然后放到在线平台,免费共享给大家。
基于以上共享的数据标准,各位BIMer就可以实现给业主交付携带数据的竣工模型了。
当然,企业也可以在这环境下定制属于自己的编码和标准构件库。如此一来,可以保证企业所有项目的三维模型中,几何构件和非几何数据都保持一致。
 

第六步

数据可视化 

我们在自己的两个项目上测试了这条技术路径,可以实现多种数据的快速整合。在有了数据之后,接下来就是给业主献宝了。业主不可能在REVIT看数据啊,所以轻量化平台又进入我们的研究范围。
这个平台需要具备最基本的两个功能:一个是对几何模型的轻量化展示,另一个就是对非几何数据的展示。在对市场上主流轻量化平台做了测试后,我们做出来了选择。如图所示,当我们点选某一个字段,例如「厂商」,我们就能查看到某个厂商所有产品以及它们所在的位置。

 

第七步

数据分析

接下来是最高级的一步,就是数据分析。我们千辛万苦去收集建筑构件的数据,就是希望通过数据分析来优化我们的设计施工运维的各项工作。
万里长征才刚开始。
在这个领域,几乎没有任何资料可以参考,只能靠我们自己摸索。其实单纯的数据分析还是有软件可以实现的,我们已经做了尝试。但是,我们希望是一个基于模型的数据分析。在我们看各类数据分析图的时候,能同步联动我们的模型;当我们分析出来某个设备的问题时,能在模型上同步高亮显示。

以上是我们团队在非几何数据管理这条路上的探索,结合我们的实践,我再抛砖引玉补充几个应用场景,给大家做一下参考。
比如,在项目结束时,交付一个含数据的竣工模型用于运维系统。
目前,我们和一家国有地产公司合作一个运维项目,后续还有八个类似项目都要上运维平台。第一个项目做得很痛苦,因为当时各类设备的数据都没有收集,后续通过总包和各个供应商去收集的时候,前前后后拖拉了好几个月。如果把这些工作分配到各个供应商手里,其实每家的工作量就不大了。但是,这就得要求业主在项目前期就要规划好这个数据标准。
比如,生成集中采购清单。
因为每个设备构件都有空间和类型的属性,业主在采购时,可以快速根据区域来形成明确的各类设备清单,也能看到每个设备所在的位置。
再比如,可以通过数据实现模型批量修改。
不管是在Excel表还是Web端,都可以对所有数据进行快速批量修改,其中也包括几何数据。例如:两个个房间的门,原来都是2米1宽,现在其中一个要改成1米8,只需要在表单里批量修改,再刷新,模型也就会跟着修改好了。

最后,我想说说写这篇分享的原因,还有我个人一路走来的感受。
在英国的BIM LEVEL 2中,对BIM的定义说的很清楚,就是需要同时共享几何模型和非几何数据。但是,我们目前能看到的所有BIM案例都是对几何模型的应用,针对非几何数据的应用几乎没有案例。
既然大家都说数据是未来,那我们就想试试看,能否摸到建筑数据的门槛,看看里面藏了什么宝。
IFC可能会成为终极大BOSS,但是肯定不是现在。对于我们做工程的人来说,我们需要解决问题,而不是停下来等,所以我们会不停尝试。也许,有一天IFC可以成熟应用,那我们还是会回到IFC这条路上来。当然,也许我们会在数模分离这条路上一直走下去。
现在大部分圈内人都认可BIM的本质是建筑信息化。但是,很多人过于追求各种高大上的IT技术,而忽视了一件事。建筑信息化是先有建筑再有信息化。建筑是本,信息化是术。所以,用什么工具方法都不重要,重要的是解决建筑的问题和业主的需求。
以上仅仅是一家之言,如果你也在摸索类似的方法,欢迎相互探讨。

BIMBOX观点

在BIM圈里,谈数据应用是一个很烫手的话题,谈远了不接地气,谈近了困难重重。首先在数据传递这一个环节,人们都没有达成统一的想法。尤其是IFC这个领域,更是很多群里聊起来就会争论的东西。

有人觉得IFC是一条死路,应该早点抛弃另寻他路;也有人觉得IFC本身没问题,有问题的是软件;更有人觉得IFC和软件都没问题,有问题的是人的水平。这里面不单单是技术之争,也有商业之争,甚至是信念之争。

BOX对这件事的主观态度今天不展开谈,我们单说对金戈这篇分享的看法。

在这篇文章的初稿发布到作者群时,大家对IFC的未来也有一番争论,但最终打动每个人的,还是金戈的一句话:「我们并没有很多IT人才,IFC出现了问题,这是我面临的实际情况,我暂时解决不了,但我不能等,得继续往前走。」

最后大家的统一意见都是:无论每个人对IFC是什么观点,都支持金戈把自己最真实的探索经历讲给大家。

缺少IT人才,是国内很多企业的实际问题,但我们不能说,企业缺少IT能力,就别搞BIM了。行业里有负责讲故事的人,也有专门琢磨大问题的人,既有面对传统问题的人,也有追求创新的人。每种人发表观点,其实都是站在自己看待行业和世界的角度,追求一条可行的实施路径,抓自己面前的那只老鼠。

而我们最支持的是这样一种人:他们有行动的勇气,也有分享的善意,把事情做出来,再把自己蹚过的坑写到文字里讲述给别人,这比简单持有一个不容辩驳的理想要困难得多,也可敬得多。

金戈在和我们谈到这件事的也说到,他更希望能通过这次分享听到不同的声音,甚至是反对的声音,大家一起探讨,怎么能在需求的角度把数据的价值真的挖出来,而不是让BIM一直站在翻模的战壕里空举理想的大旗。欢迎你把你的思考写下来,和我们一起聊聊。

有态度,有深度,BIMBOX,咱们下次见!


本期内容原作者:金戈
本期内容探讨人:@老孙 @小耳朵猫酱 @程旭 @VCTCN93 @熊仔 @开开
本期内容赞赏金额50%归作者金戈所有,剩余一半作者群抢红包,感谢大家支持

本篇文章来源于微信公众号: BIM清流BIMBOX

相关推荐

暂无评论

微信扫一扫

微信扫一扫

微信扫一扫,分享到朋友圈

BIM模型建完了,深水区怎么游?