郭榮欽 國立臺灣大學 土木工程學系工程資訊模擬與管理研究中心執行長 國立臺灣大學 土木工程學系兼任副教授 國立臺灣科技大學 建築系兼任副教授 萃取BIM塑模軟體 四種工具 由於COBie的竣工交付檔案目前以電子試算表為主,若塑模軟體能在自身環境下直接萃取COBie所需之電子試算表檔案,應該更為方便。Revit軟體本來就有「明細表(Schedule)」的功能,此明細表架構等同於試算表,Autodesk 在Revit 2014年版,為因應業界需求,以「明細表」為基礎開發出COBie Extension的增益集(Add-In)工具,支援直接匯出COBie之電子試算表檔案,並提供較細緻之元件參數映對的介面功能。旋即在2015年,推出「BIM Interoperability Tools」套裝工具,旨在擴大全面性解決BIM在資訊交付操作性的需求。主要有下列四種工具: 1. COBie Extension –— 屬Revit 的Add-In(增益集)外掛工具
3. Model Checker Configurator –—屬獨立在Windows環境下的執行工具
圖一 建議BIM Interoperability Tools之應用流程 由於四件工具操作動作甚多,介紹起來甚佔篇幅,擬只針對本文主題之COBie Extension功能作扼要性介紹,藉以凸顯其與ExportIFC之不同。前面已提及Revit原已具有「明細表(Schedule)」的功能,它是以轉出品類相關屬性資訊到電子試算表檔案為前提開發的功能,本身可細微到對族群類型與實作元件的屬性設定,以此為基底開發COBie格式需求,似乎較易達標,COBie Extension含(1)Setup (2)Modify (3)Export三組功能,(如圖二所示),其中操作功能甚多,簡單言之,所有功能都在考慮如何將Revit模型元組件所帶有的非幾何資料盡量能完全映對到COBie資料綱要所需,滿足業主或設施營運管理者的要求。這些映對作業所面對的資料可能有三種情況: 圖二COBie Extension含Setup、Modify、Export三組功能
經由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檔案。
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格式檔案的兩種方式皆可選用
3.Autodesk的「BIM Interoperability Tools」含模型檢測與分類編碼功能,具更多元應用之潛力。
0 評論
發表回覆。 |
文章類別
發佈時間
三月 2023
|