你好，这里是BIMBOX。
今天是一位老朋友的分享，上海水石建筑规划设计股份有限公司 BIM 中心负责人，大名金戈，网名铁马。
圈子里聊起BIM和运维，我们总是第一时间想到他，作为从业20年的老法师，和一名坚定的「数据BIM」布道者，他不仅专注技术与思想的研究，也给大家带来过不少关于BIM数据应用、BIM运维的干货分享，还自己开发了一款基于BIM的免费数据管理软件emData。
最近，金戈又写了一篇长文，专门给BOX的小伙伴们分享，他这些年为各种业主提供的服务之中，用BIM做运维的7个痛点，也非常实在地讲述了哪些痛点有解决方案，哪些痛点还是当前行业的发展掣肘。
搞清楚这些问题，我们才可能把这件事做得更好。内容量很大，读完一定有收获。
下面是经过BOX修改的、金戈的分享。
坊间有两个术语：「OpenBIM」和「CloseBIM」。
所谓「OpenBIM」，指利用IFC格式进行数据交互的BIM应用。
所谓「CloseBIM」，指利用某个单独的商业软件（比如Revit）进行数据交互的BIM应用。
这两者有一个通病，就是需要把数据直接加载到模型中，然后利用这个富含数据的模型文件进行应用。而这会存在三个潜在的风险。
当前的技术在处理三维模型时，依然存在很多问题，比如流畅度、美观度等。加载数据后，只会加重计算机的处理负担。并且应用程序需要穿透模型文件之后，才能应用数据，这更会增加难度。
就算是欧特克公司自己的其他软件产品，在读取Revit保存的文件时，都会出现数据丢失的问题，更不要说其他软件。
当以某个软件格式存储数据的时候，一旦出软件停用或公司停止服务，就会出现无法读取的重大问题。如果文件遗失或损坏，那就是连带着数据一起遗失。
美国公司「SMRT ARCHITECTS AND ENGINEERS」纽约办公室的主任John Tobin，在一篇文章中提出这个概念：没有模型的BIM数据。大概的意思是数据的交互应该基于数据库，而不是基于模型。
美国的Finith E Jernigan写的《大BIM4：连接世界的生态》，可能是唯一一本不谈模型的BIM著作。这本书提倡的概念，是将围绕着模型文件的应用，称为「小bim」，而基于系统的应用，称为「大BIM」。
另外，ISO19650这份标准中提到的通用数据环境（CDE），主要就是解决BIM数据的传输和共享。
在国内，很多人经常提到「数模分离」，我也多次在文章中讲过，意思也是数据和模型分开存储并应用。
以上种种，我们姑且统称为「noBIM」，本质上就是依托数据库对建筑数据进行清洗、存储和管理，从而实现建筑数据的共享。
在应用层面依然有模型的存在，但是骨子里其实是数据驱动，而非模型。
最极端的情况是，数据本身存储在数据库中，甚至连模型也是基于数据库进行存储，可以根据用户的需求，转化为任意三维格式，而不是以某种固定格式存储。
我认为，noBIM是对BIM的高阶应用，也是未来的一个趋势。是从以模型文件应用，向构件转变，进而从构件向数据应用的转变。
那么，OpenBIM，CloseBIM和noBIM和运维有什么关系呢？我们把这个话题暂且放下，先聊聊我的运维服务工作思考。
从2015年经手第一个BIM运维项目开始，我一直在思考：BIM和运维是什么关系？
慢慢的，网上开始有一些BIM运维案例，但是除了模型的可视化之外，我没有看出来BIM运维平台有什么特别的价值。
尤其是当我尝试在点击各个功能时，把模型遮住，发现对功能并没有什么影响。换句话说，即使没有模型，这些运维功能也是可以跑通的。
那BIM存在的意义是什么呢？或者换一个角度来说，BIM存在的意义不是解决业务功能，是解决别的什么问题？
在探索过程中，两句话点醒了我：「数据是企业未来重要的资产」，还有「数据即服务」。
所谓BIM运维，并不是说用BIM来做运维的业务，而是提供一种基于数据的服务。
传统的运维解决的是业务流程方面的服务，例如维修维保、安防管理、设备管理等，而BIM运维是传统建筑运维的升级版，增加了数据管理的功能。
基于模型的三维可视化，只是数据管理的一个子项功能，但是这个子项有点喧宾夺主了。
接下来还有一个问题需要解决，传统的建筑运维在升级的时候，为什么一定需要BIM技术呢？有没有可能是别的技术？
很抱歉，暂时没有，BIM是唯一的选择。具体原因老孙已经在这篇文章里探讨过了：
理清楚了什么是BIM运维，接下来就是要解决怎么实现的问题。
下面和你聊聊我在近10年BIM运维服务过程中，遇到的7个真实痛点。
目前从事BIM运维的，大部分都不是运维这个行业的人，对运维需求都不了解。
一个很有意思的情况就是，在BIM运维这件事上，甲方、乙方、第三方，都说不清需求是什么——负责人说不清需要什么，懂需求的人说不上话、或者不会总结需求。
这也是大量BIM运维项目失败的主要原因：为了上系统而上系统，不是为了解决某个需求而上。
我们做BIM运维，就是借助建筑数字化的技术，在不降低传统运维的质量下，达到降本增效。传统的运维主要包括以下工作方向：
下面这张图是运维大神Archibus梳理的业务功能。
既然要降本增效，就需要从成本的角度来分析。就成本来说基本上可以整合成这几个维度：人力成本、能耗成本、设备成本、维护成本、其他成本。
很多客户找我们，第一句话就说，我们要上一个运维系统。其实没有一个运维系统能包打天下的，因为根据不同业态的特性，成本的占比各不相同，需要解决的问题也不同，需要一事一议。
例如住宅项目，设备比较少、人员比较多，人力成本占比较大。那么这种业态的运维，就需要考虑如何有效的减少人力成本。而工业项目，设备能耗是大头，就需要考虑如何有效的节能。
我曾经在一家施工总包单位工作过近5年。当时行业内兴起各种项目管理平台，或者叫BIM协同平台。
大部分人理想中的平台，都是包含了工程建设的各个要素，既要有八大员，又要有人机料环法，还要有进度质量安全等等。
可我看到，有些公司好不容易赚到一点钱，都投进去开发平台，活活累死一大批。我们当年是测评了市场上各类软件工具，然后根据项目需求来组合。从来没有一个包打天下的大平台。
其实BIM运维平台也一样。一提起它，业内人士脑海中浮现出来的通常是个很炫酷的、基于三维模型的软件平台。
从某种程度来说，现在大部分BIM运维项目还是处于探索阶段。
而基于我们对BIM运维平台的理解和实践，BIM运维平台=CDE软件+IOT软件+物管软件+数据软件。
BIM运维平台不是一个软件，应该是实现多个功能的一组软件集合。
我在前面提到了「BIM运维=业务模块+数据模块。」基于这个逻辑，可以把它拆分成下面的架构：
业务模块负责物业管理、资产管理、空间管理、安全管理等，数据模块则包含解决工程数据的CDE、解决动态数据的物联模块，以及解决数据清洗、存储、管理和共享的数据平台。
关于业务模块和物联模块，大家基本都共识，在我的理解中，CDE模块主要解决的是BIM数据在线和共享的问题，比如我们自主开发的emData就可以是一款CDE软件。
相比CDE，数据平台则要解决多种数据的在线和共享问题。现在有很多这样的产品，有数据仓库，有数据中台，不管叫什么，功能都差不多。
知道了BIM运维需要做哪些事，接下来就是评估自身能力，能做哪些？不能做哪些？
基于前面多软件组合的共识，我认为实施BIM运维需要以下知识和经验：
➤ 针对CDE软件，需要BIM知识、引擎知识、IT开发知识；
➤ 针对物联模块，需要弱电智能化知识、IT开发知识；
➤ 针对业务模块，需要物业管理经验、IT开发知识；
➤ 针对数据平台，需要数据管理知识、数据库技术等。
可想而知，具备以上所有知识的团队凤毛麟角，所以大部分项目都需要跨团队协作。
根据我们的调研，市场上主要有这么几类公司在做BIM运维。
比如设计院和施工单位独立出来的数字公司，或者第三方BIM顾问，包括我们水石设计在内，也都属于这个方阵。
这个方阵的优势在于懂建筑行业、懂BIM、懂模型创建；不足在于物业知识较弱，数据对接和管理较弱，IT基础比较薄弱，团队稳定性也比较差。
主要是GIS起家、三维引擎起家的软件科技公司，还有一些专门做展示大屏的公司。这类公司的特点是有一定的IT开发能力，能迅速交付一个平台，让业主眼前一亮。但是缺少物管知识，以及对BIM数据管理能力，产品功能较弱。
主要是以前专门从事智能化服务的公司，比如楼宇自控、能源服务、实验室和机房等服务，做业务升级。这类公司IT知识相对丰富、智能化业务逻辑清晰、稳定性高。但是物业业务逻辑较差，BIM和三维引擎的应用比较差。
主要是传统五大行和一些物业公司的业务升级。这类公司的物管经验是最丰富的，也会引入三维引擎。但是缺少IT知识，特别是缺乏对BIM数据的应用，对BIM的理解还停留在展示阶段。
这部分主要是一些大厂，从工业、金融、互联网等圈子跨界到运维中来。这类公司的特点是资金雄厚，可以快速整合各类资源。不足是对建筑行业不够了解，物管能力和经验缺乏。通常是资金驱动或IT驱动，而不是需求驱动，导致产品很难落地。
所以你看，在复杂的运维服务面前，每一方都有自己的缺陷，合作才是当下比较可执行的方向。
所有认真做过BIM运维项目的同行都会认同：一个BIM运维项目，平台开发占一半，实施占一半，甚至更多。一个团队的实施能力几乎可以决定了一个BIM运维项目的成败。
对我们团队来说也一样，我们最缺的是IT和数据库方面的知识，也不回避这些短板，每个项目都在合作中不停去学习和进步。
现在国内做轻量化引擎的公司很多，主要是类似U3D的线下技术，或WEBGL这样的线上技术。
我发现在运维阶段，很多公司还是采用线下的游戏引擎来展示，其实并不是一个很好的选择。
游戏引擎的好处显而易见，很多开发公司用起来相对熟悉，而且展示效果也更好看。但是最大的问题就是，当BIM模型传递给它时，相当于把丰富的数据格式化了，只剩下一个壳子了。
这导致很多业主对引擎的理解都停留在可视化，这是行业的可悲。
真正的引擎，应该能完整继承BIM模型中的各类数据，并准确地展示出来。
另一方面，在线技术的引擎也有问题，就是模型承载量相对有限，容易出现崩溃。
所以，综合起来的现状就是：游戏引擎漂亮、稳定，成本高，缺乏数据联动；在线引擎数据量有限，稳定性略差，成本低，可以进行有效的数据联动。
目前要破解这一对矛盾，从技术角度来说，我见到了两个发展方向。
➤ 第一是开发超级引擎，可以流畅的跑各类超大模型。我见过这样的引擎，不过暂时没有公开推广。
➤ 第二是开发基于LOD的引擎，对模型的展示分多个精细度。在视线中的模型高精度展示，离视线远的模型用低精细度展示，以此来降低数据量，达到流畅展示。
这方面的发展很快，也总有新的方案出现，比如 Unity Reflect 、Omniverse、国内很多低代码引擎等等，大家都可以多去关注。
对于我们这种非IT人员，也没有开发超级引擎的能力，解决问题的思路是从逻辑出发，而不是从IT技术出发。倾向于使用LOD的方案，降低数据量，保证局部模型的精细和数据完整度。初步的方案是：LOD100用二维地图代替，LOD200用白模代替，LOD300用实景模型代替，LOD400用BIM模型。
很遗憾，国内很少有团队具备BIM运维模型的创建能力。
当然也可以说，运维模型的要求太高了，导致投入产出的不对等，所以也没有太多的团队愿意做这件事。
我找了很多业内的大佬请教，得到的普遍反馈是，运维模型这件事很鸡肋，价值是有的，但是付出的代价有点太大。
简单说几个运维模型和常规建设模型的区别，你感受一下：
➤ 一般设计模型专注如何出图，施工模型专注如何指导施工，而运维模型专注后续运维使用。比如运维模型非常注重拓扑关系，而大部分建模工作不会花时间做真实的连接，反正设计施工也用不着，运维阶段光是弥补这一点就需要大量的时间。
➤ 建设阶段的模型主要关注设备和管线安装，而运维阶段除了设备管理需要，更多的是对弱电系统的应用。比如各种弱电设备、摄像头、插座、道闸、电柜等，这些都不是重点建模，甚至很多是不建模的。
➤ 建设阶段的模型主要面向设备和土建施工，会忽视对空间模型的创建。在运维阶段，空间则是作为重要的资产需要被管理。
这几条是运维模型特别需要关注的几个点，退一步说，撇开这几点，很多竣工模型也是差强人意。
现在有多地方政府要求交付竣工模型，但是这些模型确实质量堪忧，能带来复利价值的凤毛麟角。
➤ 构件缺失，各种阀门、管件、软接等等基本没有。
➤ 系统错乱，比如雨水排水、生活排水、生产排水、空调水等等。
➤ 设备错放，比如水管上需要接管道泵，可能就随意放了离心泵。
➤ 不合理的对接，比如20管径的空调水管，接了水泵直接变径到50。
这些稀奇古怪的错误，真的非常让人很崩溃。曾经有一个BIM大赛，我检查了将近50个参赛模型水泵房的设备情况，只有寥寥几个项目做了正确的连接，模型质量之差，让我瞠目结舌。
这可能也是BIM经常被人诟病的原因吧，我非常希望今后随着行业的发展、甲方需求的明确，这种情况能有所改善。
现在BIM模型的主要用途在于出图和指导施工，这个过程中，标识的重要性往往被大量的忽视，比如构件标识、系统标识、空间标识等等。
我们经常在看到这样的分享：运维中出现漏水，利用BIM模型，可以快速排查是哪个阀门出现了问题，从而提高管理效率。
那么，如何实现呢？要知道，到了运维阶段，管理人员面对海量的房间和构件，已经不可能通过轴网、坐标等数据来实现定位了。
如果只是把模型扔到某个引擎或BIM运维平台，对不起，无法实现，或者说需要大量的人工挂接。
而只有在模型中做了足够的标识工作，才能让模型发挥出它的作用，标识对于模型，就像瞄准镜对于狙击枪一样重要。
这些标识在Revit模型中是天然存在的，但是不足以表达清楚关联关系，需要建模人员做一定的优化。
在我们实际接触的项目中，这项工作需要后期大量的人力去弥补。比如我们会要求在所有构件加上设计编号字段，设备构件里添加所属房间号，部分构件添加轴网坐标等。
《BIM Handbook》这本书里有很生动的解释：编码，是解决不同系统对同一构件的称呼问题。
国标虽然已经发布了分类编码标准，也是引用自国外的OmniClass标准，但是不具备很好的落地性。
BIMBOX曾经发过一系列编码的科普文章，我也在里面贡献了一些内容，你可以去了解一下，编码的名词解释和重要性这里就不重复了，在这重点说一下编码的逻辑，简单来说要有以下五个特征：
➤ 能唯一性的表述一类设施设备；
➤ 具备无限的扩容性；
➤ 方便识别的精简性；
➤ 和数据字典关联的灵活性；
比如，身份证号基本上代表了编码的极致，前六位代表所在地，中间8位是出生日期，后面4位是流水号，只留下最精简的信息，有很好的唯一性、扩容性和精简性。
身份证号有两个显著的特点，一是随着孩子出生就生成了；二是只保留最基本的识别信息，没有人物特征信息。这两点特别重要。
再看第二个案例，这是一个实际项目的设备编码，有27位，包括了位置、系统和设备信息。
很多公司喜欢把编码弄的无比完整，恨不得包含所有信息。这其实是对编码和数据的误解，编码信息并不是越丰富越好。
编码是给计算机用的，不是给人用，是为了保证构件的唯一身份可以在不同系统中进行数据交互。你进一步想知道更丰富的信息，通过数据检索就能查询到。
有一个难点在于，和人类的身份证号一样，最好的编码应该是在设备诞生的时候，就能生成，工程中对应的就是初步设计阶段，并且在整个项目中一直跟随这个设备，才能实现所谓的数据复用。
比如一台风机，编码中包含设备的类型，如果开始是一个离心风机，后来变更为轴流风机，那这个编码也要跟着变，这个工作量就太大了。妥协的方法是在竣工阶段去编码，那就失去了建设过程中的应用价值了。
经过这么多年的实战，我们认为一个好的编码标准，大概是：设备编码=限定编码+分类编码+流水号。
其中，限定编码一般区分最基本的项目、单体或楼层，分类编码区分到类别就够了。
目前，我们的分类编码标准在emData网页端已经公开，大家既可以直接免费使用，也可以在我们的基础上做修改后再使用。其次，我们在emData上，单独开发了一个可以灵活配置编码规则的模块，不同公司、不同项目，可以根据自己的需要进行配置，再一键加载到模型构件上。
模型缺少数据，这是运维行业看待BIM的一种共识，这里既包括模型非几何数据的大量缺失，也包括数据标准的缺失。
后者在行业里又被称做「数据字典」，这方面可以参考COBie，它是美国最重要的两个数据标准之一。目前国内已经有一些行业数据交付要求，特别是数字化比较深入的基础设施行业和制造业，建筑业可以参考。
我们今天要聊的数据，主要是BIM应用过程中，模型产生并需要关联的数据，一般我们称之为静态数据。里面包含了很多内容，就我们目前的认知，可以从Revit提炼使用的数据，包含下面这些：
包括房间或公共空间的面积、名称、归属等，以模型自带为主。
比如构件ID，可以是模型自带的，但一般都是用户根据项目需要自己赋予编码。
包括设计、施工和运维相关的数据，比如设计参数、施工人员、产品厂家等，一般都是用户赋予。
包括设备的风、水系等统关系和空间关系等，以模型自带为主，也可以根据需要进行调整。
对于Revit的学习，我一直对团队的要求是，一定要掰开揉碎研究细节功能，每一个功能都点击过，使用过，知道使用后的效果。
对于数据使用，首先要知道有哪些数据，哪些有用、哪些没用、哪些需要挖掘。带着这些问题，我从家具模型、结构模型、管道模型、设备模型等等角度，利用我们的数据管理软件emData把所有的Revit属性提炼出来研究。
下面的图是家具族的属性，其中蓝色标注的ID、楼层、房间、类别是有价值的运维属性。
再比如一个管道的属性，其中蓝色标注的ID、楼层、直径、长度、系统类型是有价值的运维属性。
类似的，还有结构模型的体积、厚度、面积，设备属性的系统名称、系统分类等等。
这些数据基本上体现了构件的基本特性：我是谁，我的身份，我的重量，我的身高，我在哪里，我属于哪个系统等。有了这些数据，就可以做很多事情。包括工程量统计、包括设备维修的拓扑关系等等。
此外，还有大量的工程数据，是需要我们在项目实施过程进行收集的，结合地铁、国网以及国标，将所有的工程数据分成了图上的9大类：
需要做竣工模型或运维模型的项目，都可以直接到emData平台上，给相关的构件批量的加载这些字段。另外我们还在平台里内嵌了上海浦东交付标准、深圳工务署交付标准和深圳地铁交付标准等。
以上就是我总结的8点BIM运维之痛，和截止到目前我的方案与思考。聊完这些，我们可以回到一开始谈到的「noBIM」了。
经常有人问我，怎样在模型上加载他们需要的数据，也包括数据的排序、类别等各种技术问题。
数据可以放在数据库里，或者最不济的，可以放在EXCEL表里。因为最终，所有数据都会在软件系统中被使用，最终还是要进数据库的，那么之前做的各种基于模型加载的东西，都会是无用功。
如果是依据「noBIM」的理念，从项目的开始，就需要一套软件系统全程陪同，模型在设计软件完成更新，而数据在云端更新。最后数据库对接数据库，完成数据交付到运维平台。
基于「noBIM」理念，我们服务了很多业主客户，搭建企业级的BIM运维平台，来实现企业数字资产管理和数字化转型。
而我的建议一般是：BIM建模软件一般分为专业和通用两种。专业软件能更好的解决某一个方向的问题，但是数据传递性较差，例如ArchiCAD。通用的软件则是专业功能一般，但是数据传递性更好，例如Revit。
为了保证竣工交付，我一般会建议用通用性更好的软件。但是，现在来看，这似乎是一个不完备的建议，至少得看项目情况。
原因在于，我们经历过这么多的BIM项目，发现凡是没有企业规划的BIM模型，运维阶段都没办法使用，为了修正这些模型而投入的资源，足够重新建一个了。
所以，如果甲乙双方对数据该怎么用这件事压根没想清楚、也没约定清楚，与其用通用软件做一个交付了也没有价值的模型，还不如直接用专业软件，好好的把建设过程的价值发挥到最大。
➤ 第二，只有那些业主自持、且有一定体量的项目，做数字化交付有意义。
前面我们说了这么多，搭建一个合格的BIM运维平台，要花费大量的资源，而能支撑这些资源的回报，必须有后续大量的数据应用。一般销售型的项目这方面不会有太大发挥，而体量比较小的单一项目，就算自持，也没有足够的数据样板。
在很多年前，我就一直坚信BIM的未来一定是「数据为王」。BIM运维的成功一定离不开两个支撑：一是技术，二是数据。
技术可以赋予BIM运维各种可能，而数据却是这些可能成真的底座。技术在建筑信息化这个领域其实已经有了长足的发展，而数据始终不够被重视。
无论怎么说，这些作为我的本行，都不是在给大家泼冷水，只有我们把问题提出来、直面它们，才可能有行动和探索的方向，我相信未来有了足够真实有效的数据，BIM运维一定能开出绚烂之花。
本篇文章来源于微信公众号: BIM清流BIMBOX
暂无评论
要发表评论，您必须先 登录