同一供應商之軟體相互操作性

供應商的英文是 vendor，而軟體供應商通常指的就是開發軟體的公司，假若 在工程專案的全生命週期中，無論 BIM 設計工具或非 BIM 設計工具(如：模型瀏 覽軟體)皆採用同一家供應商的軟體，乍聽之下似乎相互操作性的問題會比較少，

且供應商也有義務去解決自家產品的相互操作性，否則怎說服消費者花大把鈔票 去購買如此昂貴的軟體？誠然，本人曾在臺灣某個知名的半導體公司擔任實習生，

該公司從早期廠房設計的多維度模擬軟體到近幾年先在辦公大樓導入 BIM 技術，

皆貫徹採用同一家軟體供應商之理念，在廠房設計的部分多年來可謂相當成功，

但此般成功卻也造成 BIM 技術導入於廠房設計的考慮因素，故其先於辦公大樓的 營運維護階段先嘗試以 BIM 模型來輔助管理。

事實上，BIM 技術可應用於全生命週期，不同階段、不同領域、不同需求皆 有其最適合的軟體選擇，因此 Hamil (2012)也提到一個建築物不可能完全都選擇同 一家軟體供應商之軟體來進行設計和建造。BIM 技術與應用講究跨領域整合和多 方協同作業，即便每一個專案參與者在每一個時間點皆使用同一家軟體供應商之 軟體，或許還有以下因素需考量：

(1) 同一家公司的產品若是併購或收購而來，其相互操作性如何？

24

商用軟體的檔案格式或多或少是商業機密，又因底層資料模型(data model)不 可能完全一樣，故不同軟體供應商的軟體要用相同方法來解析其檔案格式難度頗 高，除非具有市場區隔或功能性不同的軟體供應商才有可能存在完全的相互操作 性。然而，出於商業競合的考量，或許也會有兩家公司願意合作設法使其旗下軟 體之相互操作性提高(如：Tekla Structures 對於 Autodesk Revit 的支援，可謂事一強 以攻眾弱的連橫政策)，但多家公司以聯盟的方式來共同協商整個 BIM 軟體產業鏈 的相互操作性，似乎可能性又低了些，故在同一個工程專案中採用不同供應商之 軟體還是有其不小的相互操作性風險。

另一個臺灣知名的半導體公司可作為借鏡，該公司因為專業領域不同的考量，

即採用不同的 BIM 設計工具，如：管路模型採用 Bentley 之 OpenPlant、建築模型 採用 Autodesk Revit Architecture、機電模型採用 Autodesk Revit MEP、結構模型採 用 Tekla Structures、設備機台模型採用 Autodesk Inventor，因本人曾間接接觸該公 司在整合這些模型時所遇到之問題，故採用太多不同家公司產品的結果可能是整

25

2n 種轉換機制，IFC 格式便是基於這種前提的產物，且因 BIM 公開標準在全生命 週期的應用確有其必要性(如：模型整合和備份之需求)，其已儼然成為 BIM 公開 標準格式的代名詞。

然而，BIM 設計工具皆有其原生(native)的檔案格式，目前在主流市場中亦尚 無基於 IFC 格式的 BIM 設計工具，且 IFC 格式對於各種 BIM 設計和非設計工具之 不是萬靈丹，各有各的限制，例如：Abanda et al. (2013)提出三個上述公開標準的 限制：第一，語言規格本身的限制，因公開標準需兼顧大眾需求，故不可能基於 特定領域的(domain-specific)語意學(semantics)來量身打造，這使得某些特殊需求將 無法描述，例如：IFC 在物件外型上對於複雜曲面的支援度較低、gbXML 所產生 的 HVAC 資訊於其他軟體之相容性較低，且 gbXML 和 IFC 在幾何資訊及其相互 關係的描述也不盡相同、COBie 對於某些模型元件無法正確地轉譯；第二，描述 3D (three-dimensional)幾何資訊的描述方式和交換格式太多了，3D 資訊科技發展良 久，在不同的產業有不同的 3D 檔案格式，幾何資訊是視覺化溝通的基礎，若要將 不同格式進行轉檔便有資料遺失(data loss)或發生錯誤的可能性，但重新建模又很 沒有效率；第三，工程專案的利害關係人(stakeholder)來自不同背景和領域，所以 對於相同資訊的語意表達方式便會不同，但實際上可能是在描述同一個事物。

上述第二和第三個限制或可以這樣理解：IFC 在幾何資訊的資料綱要可被各自 表述，即同一套法則可依自我需求來解釋，只要可以解釋得通且外觀相符便可接 受，例如：Cheng and Wu (2013)開發 BIM Object Adapter 以期在異質的 BIM 系統

26

之間交換和共享參數化的 BIM 物件，在該研究的文獻回顧中提到許多以 IFC 格式 進行資訊交換時所發生資料遺失的情形，即便這些異質的 BIM 系統皆宣稱相容於 IFC 這樣的公開標準。上述現象的根本原因在於：即使是同一個 IFC 檔案，當其被 修改時乃依附於所使用之 BIM 設計工具，而不同的 BIM 設計工具有其專屬、特定 之規格，尤其是模型元件之非幾何屬性在語意(semantic)上之定義或解讀不同，於 是在 IFC 檔案匯出/匯入的過程中造成資料遺失(Monteiro and Martins, 2012)。

不同的 BIM 系統仍可能以不同的方式來描述同一個物件，即便其皆符合 IFC 標準，也就是說以同一個資料綱要來各自表述同一個物件，這種情形好比看同一 事物的觀點不同，所導致的陳述內容也會不同，由此可見，公開標準不一定是客 觀標準，好比梁構件的樓層解讀方式在建築業和土木業是不一樣的，前者所謂「二 樓的梁」和後者所稱「3F 梁」，其實是指同一個梁構件，這種情況又好似英式英 語和美式英語的分別，大部分時候一致性很高，但有時卻有完全相反之別，故整 個 AECO (Architecture, Engineering, Construction, and Operations)產業鏈不可能有相 同的語意描述方式，如同全世界的人不可能講同一種語言。

另一個 BIM 公開標準需要關注的是模型視圖(或稱子模型)的資訊共享和管理，

因此 buildingSMART 亦大力推廣 IDM (Information Delivery Manual)和 MVD (Model View Definition)。事實上，早在 2006 年即有學者提出 useful minimum 的概 念(Hietanen and Lehtinen, 2006)，該研究認為應找出基於 IFC 標準的資料交換最小 範圍(minimum scope)，並且這些資料必須是有用的、有需求的，如此才能確保相 互操作性的可預測性和品質，而非一口氣將解決龐大資料交換之需求寄託於 IFC 上，在該研究的結論也提到一個現象：領域專家(domain expert)通常會假設資料交 換的範圍(scope)即其所屬領域所創造出來或需要的資料，但理想的資料交換唯有 透過領域之間的協同作業才可達至。

27

綜合以上所述，以本研究的觀點出發，就資料交換的角度而言，真正有用的 或有需要的資訊才從 BIM 模型中擷取出來進行交換，並且資訊回饋至 BIM 模型也 應如此，IFC 的相互操作性並非放諸四海皆準，尤其各領域專家有其天生不可避免 的本位主義(在佛法中稱所知障)，若一味期待一套公開標準能完全符合且能充分解 釋各領域的專業知識，便有點過度理想化且很難不落入一言堂的圈套。

適逢美國綜合營造公會的 BIMForum 工作小組在 2013 年 8 月公布新的 Level of Development Specification (BIMForum, 2013)，其中特別解釋 Level of Detail 與 Level of Development 之差異：Level of Detail 指的是模型元件的細節程度(即包含 了多少細節)，因此是屬於模型元件的輸入資訊；而 Level of Development 指的是 模型元件中的幾何與屬性資料可被信賴之程度，因此是屬於可靠的模型元件輸出 資訊(謝尚賢, 2013)。本人認為這番解釋恰好可與上述 useful minimum 之概念相呼 應，故可將 LOD 之概念導入 useful minimum 之概念圖，並輔以經濟學之供需理論 來類比之，即 useful minimum 可視為 Level of Detail 之資訊輸入供給和 Level of Development 之資訊輸出需求所協調之供需平衡結果，本研究修改如圖 1 所示。

圖 1：以供需觀點來解釋 LOD 及 useful minimum (Hietanen and Lehtinen, 2006)

28

總結，本研究以三個面向來看待 IFC 所受的限制：市場因素、歷史借鏡和根 本原因。就市場因素而言，軟體供應商對於公開標準的態度有時會自我矛盾，增 加 IFC 的相互操作性有助於發展 BIM 相關產業，但卻又想將自家產品於全生命週 期中布局；就歷史借鏡而言，並沒有任何公開標準是能完全相容於所有的設計工 具，舉凡文書處理、影像編輯、多媒體剪輯等應用程式，似乎不同設計工具之間 的完全相互操作性並不存在；就根本原因而言，公開標準必須兼顧整個產業鏈中 所有參與者之需求，故必然是一種取交集和求共識的過程，一定會有少部分的相 容性需求被捨棄，例如：以現實主義來衡量，當利益有交集時可各取所需(如：共 同採用 IFC 格式)，而當利益有衝突時則各自為政(如：能源分析者選用 gbXML、

設備管理者選用 COBie)。

本研究認為「時效性要求低」和「需求一致性低」使得 AECO 產業的公開標 準難以訂定，根據 Kiviniemi (2006)的演講，推廣 IFC 的預算一直都缺乏，同時因 產業鏈尚未完全整合而過於分散，生命週期太長以至於沒有主導者(process owner)，

故沒有人願意當白老鼠。Kiviniemi 對於 IFC 的幾點建議本研究亦相當認同，並以 括弧( )之方式為其加上註腳：

(1) 先使用現在已經有的(資料綱要)，專注於實施和使用(IFC)的品質，(而非 一味追求柏拉圖式的理想)。

(2) 別認為 IFC 對於建模來說是不可或缺的，不需一次改變太多，先從 useful minimum 開始共享資料，(眼光要放遠，腳步要放慢)。

(3) IFC 並非終端使用者(end-user)的(而是生命週期)產品，強調錯綜複雜的技 術議題是錯誤的訊息，(故模型版次的管控亦很重要)。

(4) 技術面是簡單的，人的因素是更加困難的，(所以 IFC 的相互操作性並非 完全是技術問題，有時則是偽命題，因其屬於哲學問題)。

29 處理有利於多方協同作業、資料可備份和版本管控等，Kiviniemi (2006)亦提到以 檔案為基礎之資料交換並非可行的解決方案，因模型檔案過大時，小部分的修改 便沒有效率，且資料的結構和內容不同使得雙向資料交換難以進行，而資料的所 有 權 (ownership) 和 修 正 機 制 亦 無 法 管 控 ， 故 Kiviniemi 建 議 以 模 型 庫 (model

30

repository)或模型伺服器(model server)的方式來儲存 BIM 模型，如此一來就等同於 將以檔案為基礎的管理模式轉化為資料庫的管理模式，此時模型可部分交換，每

repository)或模型伺服器(model server)的方式來儲存 BIM 模型，如此一來就等同於 將以檔案為基礎的管理模式轉化為資料庫的管理模式，此時模型可部分交換，每