众所周知，在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数据交互平台大致有这么几种，免费的，Autodesk Design Review，收费的，Autodesk Navisworks，随着目前Html 5逐渐成为主流，现在也出现了第三方的基于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模型中既有的模型数据，可以直接提取，对于没有的数据，需要通过录入或者从业务数据中提取，尤为关键的，是要通过编码将属性字段和实时运维数据字段对接，实现数据的关联，进而能实现双向的互动。
