BIM在運維階段的數據構建原理

運維階段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數據交互平臺大致有這么幾種，免費的，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模型中既有的模型數據，可以直接提取，對于沒有的數據，需要通過錄入或者從業務數據中提取，尤為關鍵的，是要通過編碼將屬性字段和實時運維數據字段對接，實現數據的關聯，進而能實現雙向的互動。