[營建知訊轉載] 再談COBie（下）郭榮欽 (2017.8)

郭榮欽  國立臺灣大學 土木工程學系工程資訊模擬與管理研究中心執行長
               國立臺灣大學 土木工程學系兼任副教授
               國立臺灣科技大學 建築系兼任副教授

萃取BIM塑模軟體  四種工具
由於COBie的竣工交付檔案目前以電子試算表為主，若塑模軟體能在自身環境下直接萃取COBie所需之電子試算表檔案，應該更為方便。Revit軟體本來就有「明細表(Schedule)」的功能，此明細表架構等同於試算表，Autodesk 在Revit 2014年版，為因應業界需求，以「明細表」為基礎開發出COBie Extension的增益集(Add-In)工具，支援直接匯出COBie之電子試算表檔案，並提供較細緻之元件參數映對的介面功能。旋即在2015年，推出「BIM Interoperability Tools」套裝工具，旨在擴大全面性解決BIM在資訊交付操作性的需求。主要有下列四種工具：

1. COBie Extension –— 屬Revit 的Add-In(增益集)外掛工具

• 可在 Revit 的專案檔案內建立及映對COBie參數、修改COBie參數值、以及將COBie資訊匯出成電子試算表檔案。並可儲存上述映對操作程序，供未來其他類似工程專案引用，大幅減輕重複性操作。

2. Classification Manager –—  屬Revit 的Add-In(增益集)外掛工具

• 對 Revit 模型元件進行分類編碼的映對作業(包括美規的Uniformat、Masterformat、Omniclass及英規的Uniclass)。
• 可導入本土常用分類編碼(基本上任何對模型元件有分類需求及對應關係的編碼皆可適用)。例如：工程階段的PCCES綱要編碼，以及營運階段資產管理所需要之「財物標準分類」DGBAS編碼。
• 包括「空間」與「設備」，都能透過此分類編碼的映對作業，將吾人後續想處理的作業，包括工程期間的4D、5D應用，或營運使用期間的資產管理，做有效的分類歸納。

3. Model Checker Configurator –—屬獨立在Windows環境下的執行工具

• 建立模型檢測所需之檢測條件組態檔，可針對下列四種要求設定檢測條件：(1)要求之模型元件是否存在？(2)指定之元件參數是否存在？(3)元件參數是否填值？(4)元件參數值是否在要求範圍內。
• 此工具可擴大應用到特殊需求之模型檢測規則集設計。可儲存上述條件定義操作程序，供未來其他類似工程專案引用，大幅減輕重複性操作。
• 可嘗試建置本土常用分類編碼系統的檢測條件組態檔。

4. Model Checker –— 屬Revit 的Add-In(增益集)外掛工具

• 依載入之模型檢測組態檔進行模型元件的檢測。
• BIM模型匯出COBie 電子試算表檔案之前，可以針對特殊需求之模型檢測組態檔(即規則集Ruleset)進行模型檢測，並產出檢測報告，作為修正補強BIM模型的元組件資訊。

COBie僅規定資訊交換的格式，沒有規定交換的內容，業主及設施營運管理者所關心的是資訊內容及其可能的分類，若萃取出的COBie資訊內容不符預期所需，也是枉然。而萃取到電子試算表後的檔案資料相當龐雜，要檢測是否符合也是相當不易，萬一檢查出不符要求，又需退回模型建置階段修正補強，因此開發輔助工具以協助在萃取COBie資訊之前，就預先進行檢測與分類，有其必要性。本文經研究，提出此四項工具應用之流程建議，（如圖一所示）。

圖一 建議BIM Interoperability Tools之應用流程

由於四件工具操作動作甚多，介紹起來甚佔篇幅，擬只針對本文主題之COBie Extension功能作扼要性介紹，藉以凸顯其與ExportIFC之不同。前面已提及Revit原已具有「明細表(Schedule)」的功能，它是以轉出品類相關屬性資訊到電子試算表檔案為前提開發的功能，本身可細微到對族群類型與實作元件的屬性設定，以此為基底開發COBie格式需求，似乎較易達標，COBie Extension含(1)Setup (2)Modify (3)Export三組功能，（如圖二所示），其中操作功能甚多，簡單言之，所有功能都在考慮如何將Revit模型元組件所帶有的非幾何資料盡量能完全映對到COBie資料綱要所需，滿足業主或設施營運管理者的要求。這些映對作業所面對的資料可能有三種情況：

圖二COBie Extension含Setup、Modify、Export三組功能

1. COBie需要的元件屬性，Revit系統現成即有：

可直接進行映對動作，映對後，在Revit環境或許未能直接看到其映對「值」，但會順利匯出。

1. 額外需要的元件屬性，Revit系統現成沒有：

則在Revit環境中，需進行擴充屬性為「類型」或「實作元件」的屬性，並從長計議作妥適規劃額外擴充的元組件屬性，否則將來會造成混亂局面。

1. COBie需要的元件屬性，可間接從Revit既有屬性加工而得：

有些屬性可能由其他既有屬性設參數公式間接取得。相同的，也有可能某幾個有需要的屬性資料透過COBie某一屬性欄位合併帶出。
經由COBie Extension的Export功能匯出COBie 電子試算表，（如圖三所示），圖中僅為COBie標準所規定19張工作表之一 – Component，它正好對應Revit塑模工具中的Instance(實作元件，或稱例證、實體)。COBie指引手冊雖提及，必要時可在工作表規定欄位的右端擴充新欄位，唯目前所知各實作軟體預設之電子試算表樣板檔與匯出功能，尚未支援此項彈性規定。

圖三　COBie. Component 工作表

BIM非幾何資訊應用 發展整合資料庫
​
BIM的非幾何資訊在建築物實體完成後，其應用的機會將愈來愈高，而非幾何資訊也會隨時間愈累積愈多，COBie開發的主要目的在大幅改善工程竣工移交給設施營運單位所需資訊的效率與成本，雖說COBie的SpeadsheetML格式資料，在某種情況下亦可能直接被引用(國外有案例)，但這些萃取自BIM的非幾何資訊，主要還是要提供給竣工後長期營運維護之CMMS、CAFM、IWMS、BCS、ERPS等系統，支援該建物的「空間」與「設備」建置基本資料用。而這些系統幾乎都是以RDB(Relational DataBase，關聯式資料庫)為資料處理的基底平台，另外，BIM技術發展至今十多年來，業界已有一基本認知，就是隨著工程專案的特質與規模，以及各階段模型使用立場不同，在整個工程階段，BIM模型不太可能僅維持一個，若模型不只存在一個，則匯出之COBie檔案也須考慮不只一個(ID識別碼對映回模型元件時會變複雜)。如果工程專案在竣工移交時，所有工程階段的生產履歷都需移交，合約規定之每個交付里程碑(milestone)都可能會有數個模型，並對映數個匯出的COBie 電子試算表檔案，這可能又衍生與傳統類似的另一資料管理的新議題。
 
另外一個重要的理由是BIM技術在冗長的使用營運期，隨著時空運轉，使用需求改變、天災、以及因應未來科技繼續進化的需求等，建築物會增建、修建、改建，空間會調整，設備會增添、報廢、挪移等，竣工移交的模型務必同步緊隨實體做異動，也就是所謂「虛實同步」，整體的BIM技術運用才可能永續經營，才具有前瞻意義。因此，前面工程階段移交的BIM履歷資訊，包括幾何模型與COBie非幾何資訊，應妥適歸檔管理，供必要之查詢使用。基於以上三個理由，COBie的電子試算表檔案應該考慮發展一個整合資料庫系統，做最佳資訊管理的規劃，讓這些資訊能達「進可攻、退可守」的永續經營對策。圖四為BIM非幾何資訊整合資料庫系統管理架構的初步構想。此圖僅假設COBie資訊來自Revit的COBie Extension，但應該也同樣適用從IFC檔案萃取的COBie 電子試算表檔案。

圖四BIM非幾何資訊整合資料庫系統管理架構的初步構想

另外，此管理架構有幾個重要的面向需考量：
1.多模型
工程階段會依合約要求指定BIM模型交付之里程碑(milestone)，每個里程碑會因下列三種情況而產出不止一個的模型與COBie檔案。

• 不同的階段會因為對模型使用的立場與需求不同而各自塑模。

• 各階段因專業特性差異太大，模型元組件與屬性訴求重點不一樣，可能從採用的塑模軟體就不同，自然產出各自模型與COBie檔案。
• 工程專案規模大到必須考慮切割模型，包括分層(Floor)、分區(Zone)或分棟等。

管理架構要考慮工程專案的任何可能，因此，應提供操作者自定義此工程專案多模型層狀架構的支援，並將此定義的架構儲存到資料庫，做為此工程專案生命週期BIM非幾何資訊管理架構的基底。它不但負有關連模型檔案及COBie檔案資料夾的繫接映對之責，也是整個專案移交檔案未來永續控管的重要網絡。
2.竣工模型
竣工模型是工程實體完工，設備也完成試俥、驗收、移交時，虛擬空間的BIM模型與實體完工現況一致的模型資訊，竣工模型也同樣須被檢測、驗收和移交。此模型不須包括施工階段時，專為施工所需之特別措施所建之模型元組件，例如施工鷹架、施工可行性分析用之4D模型，它們較適合被包含在施工階段的交付里程碑中，但應該不必含在竣工模型中。而竣工模型應考慮未來維護所需，而可能被包覆在結構體或天花板、高架地板中的元組件，以及已經被確定的空間命名、及已安裝的設備規格資料等。
竣工交付的模型及COBie檔案是此管理架構最重要的集散點，它負有工程階段所有模型與COBie資料庫繫接的源頭，除了在營運階段時，作為管理系統「空間」與「設備」基本資訊的來源及BIM資訊永續經營的起點外，還須在工程階段，支援各營運系統，隨時查詢履歷資訊。
3.COBie資料庫正規化
COBie的工作表如同資料庫的資料表(Table)，各工作表的欄位如同資料表的欄位，但是許多COBie之工作表的欄位甚至連一階正規化都不符合，例如前述有一Component工作表的Name欄位，有一筆「M_廁所 - 臉盆:760 mmx455 mm - 私人:566159」的設備元組件資料，就是由「族群名稱：類型名稱：實作元件ID」所組成，明顯違反一階正規化原則。諸如此類，包括二階，甚至三階的檢討都有其必要，須經檢討調整後，才適合未來營運管理各種系統的銜接使用。
 
 
4.建築物生命週期特長
建築物生命週期相當長，縱使物換星移而它猶存，加上一棟建築物所參與之利益相關者眾多，所以務必考慮「長期穩定儲存」及「多人同時維護」的必要性，雲端架構是靠網際網路技術集中控管資訊，並能支援即時多人操作的有利環境。BIM的宗旨在建築物生命週期的資訊充分共享，因此，將工程專案的幾何模型與BIM非幾何資訊集中架設在雲端平台，對未來更多更理想的資訊科技運用，例如IoT物聯網的布局，應為必要的選擇。

重視COBie資訊交換標準 擬定統一規範
​
由於COBie格式標準規定的訴求，在建築物生命週期的資訊共享上甚具意義，其作為示現的電子試算表檔案格式亦頗具親和力，因此，除了英美政府部門強制要求採用以外，國際間許多國家，如加拿大、澳洲、紐西蘭、新加坡等英系國家及歐亞多國皆已陸續跟進。我國工程專案採用BIM後，應該將工程竣工交付的資訊交換，盡早規定統一在標準規範下，並兼顧國際接軌，有其必要性，則COBie資訊交換標準應該值得重視，筆者在近年針對COBie議題的研究，有幾點簡單結論：
1.塑模軟體匯出COBie格式檔案的兩種方式皆可選用

• Revit 的COBie Extension功能考慮齊全，惟匯出效率仍有改善空間。

• 其它塑模軟體大多透過IFC轉出，同樣都有類似效率問題。

• 模型檔案過大時，匯出時間長，應考慮分批轉出或模型切割。

2.目前國際常見營運管理軟體是否符合國內需求待考驗，可考慮自行研發

• 由於現有國外FM軟體之資料庫與COBie間之映對作業，仍偏手工操作。未來應會持續精進。
• 許多國外FM軟體功能不一定都符合國內管理需求。國內營運管理系統應考慮自行研發。

 
 
3.Autodesk的「BIM Interoperability Tools」含模型檢測與分類編碼功能，具更多元應用之潛力。

• 四個工具都具有繼續進化的可能，目前(1).COBieExtension(2).Classification Manager(3).Model Checker三個工具是以Add-In(增益集)的方式外掛進Revit，未來亦可能發展成系統內建功能，如同Dynamo一般。

• COBie Extension的參數映對介面甚具親和力，未來其他塑模軟體有可能跟進。

COBie標準之研發團隊主持人– Bill East博士說過一句話：「目前營建業界普遍對COBie的了解情形——對技術操作有疑問的人，遠少於對COBie存在之意義誤解的人，這是比較令人憂心的。」假設我們也站在英美政府角度，面對龐大公共資產管理效能改善之難題，以業主的立場設身處地思考這件事，大家或許就會有一致的共識，但這只是提醒我們不得不為的必要性。一旦眾人進一步深入了解BIM非幾何資訊在虛擬空間的萃取、管理、運用的整個機制後，相信此時就能深刻體認實踐COBie標準，是多麼的重要！