BIM模型建完了，深水区怎么游？

作者：金戈，上海水石建筑规划设计股份有限公司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，只需要在表单里批量修改，再刷新，模型也就会跟着修改好了。