|
朱峻平 國立中央大學 土木工程學系資訊應用組博士候選人 林泓邦 國立中央大學 土木工程學系資訊應用組碩士生 周建成 國立中央大學 土木工程學系資訊應用組副教授 謝尚賢 國立臺灣大學 土木學系電腦輔助工程組教授兼工程資訊模擬與管理研究中心主任 有利資料存取 擴展BIM必走之路 今日隨著建築資訊塑模（Building Information Modeling，BIM）技術日益成熟，以及在營建業應用的蓬勃發展，可預期BIM將成為建築物生命週期各階段之資訊儲存與管理中心。在建築物規劃、設計與施工階段，國內外文獻均呈現許多BIM應用成功的實例，如BIM在協同設計、4D碰撞檢查，與可施工性分析（Constructability Analysis）等。究其原因，乃BIM商用軟體能提供完善的建築元件編修能力，如參數化設計、建築元件庫等，使得資料可改一次、用很多次，達到資料一致性的理想境界，進而顯示資訊整合後的優勢。 然而，從資料存取的角度來看，BIM終將累積出完整的建築物設計施工階段各式資料，但現今BIM商用軟體是否足以擔任建築物整合式資料來源的重責大任，使得後續越來越多的軟體應用程式皆可順利存取BIM資料呢？例如，目前資料庫技術可輕易達到大量資料的快速查詢功能（透過索引機制）、資料欄位的動態增減與資料字典管理（透過SQL DDL機制），與巨量等級以上資料管理（透過BLOB機制）等，均少見於目前商用BIM軟體中。但此需求隨著營建、物業管理，甚至防救災管理領域更多軟體應用程式的出現，擴展BIM是一條必走之路。 本文提出一套結合空間資料庫的BIM擴展作法與應用案例，著眼於利用原本資料庫技術擅長的欄位擴充、檔案處理、簡單空間關係之大量資料快速查詢能力，使得更多軟體應用程式可重用BIM資料與功能。在此除了說明擴展與轉換BIM資料的作法，也探討應用案例，並展望未來。 資料存取至資料庫 轉換作法 BIM技術與資料庫技術具有不同的設計理念：BIM強調視覺化建築物3D幾何，同時提供豐富的屬性資訊；資料庫則多半無視覺化能力，但均可處理2D或3D幾何資料，可多人同時存取大量資料且良好地維持資料一致性。從文獻[1]可知，若要讓更多軟體應用程式可順利存取BIM資料，有兩種作法：(1)將BIM資料匯出至開放的檔案格式，如IFC或COBie；(2)透過BIM軟體應用程式提供的 API（Application Programming Interface）存取BIM模型內各式屬性資訊。一般而言，第一種作法雖然開放，但模型轉換技術無法避免語意上（semantic）的資訊遺失。例如，在同水平位置但不同樓層的房間具有垂直空間關係，還有房間、走廊與樓梯的聯通性等。第二種作法雖然看似封閉，但透過API存取軟體內部資料原本就是目前軟體的技術主流，如微軟Office亦開放.NET或VBA介面讓外部應用程式可操控Office內部行為與資料，做進階應用。然而，此作法也伴隨著兩類問題，其一為BIM軟體廠商對於開放API的態度，有時因保護BIM運作順暢故不開放某類型API以求穩定，因此使用前必須評估與審查這些API的適用性。 使用API存取BIM資料的第二問題在於執行效能。例如，圖一左側為一個簡單的範例建築物，乃以Revit 2014製作，內含50個建築元件。若以Revit API寫Plugin軟體應用程式，計算任意2至50個建築元件的體積，其執行所需時間如圖二藍線所示。同時，若將上述50個元件建立在空間資料庫領域著名的開放軟體PostgreSQL 9.3與PostGIS 2.0內，其儲存後結果如圖一右側，並撰寫空間資料查詢SQL程式計算體積，其執行所需時間如圖二的橘線所示。本文雖以Revit作為測試對象，但使用其他BIM軟體如Tekla、ArchiCAD等均可得類似的結果。簡言之，從圖二可看出隨著建築元件數量的增加，BIM軟體執行空間查詢時間將快速成長，與空間資料庫執行時間的差異亦漸增。  圖一 左側：範例用簡單Revit模型；右側：模型轉換至空間資料庫後的表格 測試對象，但使用其他BIM軟體如Tekla、ArchiCAD等均可得類似的結果。簡言之，從圖二可看出隨著建築元件數量的增加，BIM軟體執行空間查詢時間將快速成長，與空間資料庫執行時間的差異亦漸增。 進一步分析其原因可知，BIM提供非常完善的建築元件資料編輯能力，且建築元件時常具有複雜的資料結構，但若只以基本資料存取動作之查詢指令來看，當然無法與專為多人快速存取設計的資料庫技術相比。此外，在建築物生命週期的後期應用階段，BIM模型特別是幾何類資料之異動頻率就不高，但資料之查詢與加值運算的需求卻頻繁很多，若能將常用的BIM資料轉換至空間資料庫，並建立連結與索引的機制，相信整體BIM資訊應用系統的執行速度可大幅提升。 除執行效能層面的考量，轉型BIM至空間資料庫亦具有「管理」上的優勢。如同資料庫技術的發展歷史，一般企業運作的基底資料可依資料本體的特性分類至各「關聯表格」（或稱之為Conceptual Model），但也因企業具有各式各樣的服務或流程，常將資料動態分類組成特定領域的特定應用方式（稱之為View Model），此種既集中又分散的彈性作法，背後依靠的數學為集合理論，造就資料庫技術為當今主流派。回到BIM的領域，BIM內各式建築元件只依設計或施工階段的分類方式，原本便較難彈性運用在後期各領域，但若能擴展到資料庫，且維持空間運算特性，便可動態組合出使用者欲處理的建築元件群組，應是較適當的作法。  圖二 查詢任意2-50個建築元件之體積指令在Revit與PostgreSQL所需執行時間(秒) 此外，從軟體應用程式的需求面考量，BIM轉換至空間資料庫的建築元件幾何形狀應可再行簡化，例如某走廊上的滅火器，在BIM內的3D呈現可以相當逼真，但在防救災應用上，也許使用者只想知道「方圓三公尺內的滅火器」，或「離某物件五公尺內的其他建築元件」等查詢結果。是故，筆者乃發展最小方盒（Bounding Box）包裝技術，使得符合指定條件的所有建築元件，均可自動產生其最小方盒並儲存在空間資料庫中。簡言之，最小方盒即是某建築元件之x/y/z軸的最大與最小值組成，空間資料庫內則儲存：元件編號（Element ID）、元件類型（Element Type）、最小方盒幾何（Bounding Box Geometry）、元件階層（Element Level），更多的屬性也可視需要而自由地新增。圖三顯示一群範例建築元件（左圖）之最小方盒包裝化的結果（右圖）。因建築元件幾何形狀可能非與x/y/z座標軸平行（如屋頂斜窗），最小方盒化時須使方盒體積最小，故可能不一定在xy平面上。 轉換BIM建築元件重要屬性至空間資料庫後，接下來便可依循OGC（Open Geospatial Consortium）組織替空間資料庫定義的Spatial SQL功能，執行空間聯集、 差集，與交集運算[2]。例如，假設某消防設備服務有效範圍為三十公尺，利用空間資料庫可非常容易找出建築物內此消防設備無法有效服務的區域。部份商用資料庫甚至提供更進階的空間推理功能，遠超過現今BIM軟體能提供的空間運算能力。  圖三 任意建築元件之最小方盒包裝化後結果 擴增BIM應用 建立多對多關係 在執行一些BIM應用計畫的過程當中，筆者發現BIM模型常扮演資料中控端的角色，亦即許多軟體程式的輸入資料，必須由BIM模型中的某群建築元件屬性轉出；許多軟體程式的輸出資料，事實上是針對某群建築元件有意義，同時部份輸出資料可能為另一軟體程式的輸入資料，資訊流相當複雜但卻很有條理。既然各式軟體程式的輸入或輸出資料均與BIM建築元件群組有關係，如何透過Revit API尋找這些群組便成為首要工作。接下來則建立「建築元件」與「外加檔案」的多對多關係，讓各式軟體程式的輸入或輸出以檔案形式呈現：
此種元件與檔案的多對多關係，可透過一關係表格清楚記錄在空間資料庫中。如圖四所示，符合特定條件的群組，內含數個建築元件（上圖）。每個建築元件可能關聯到數個檔案（下圖(1)），同時，某個檔案也可能關聯到數個建築元件（下圖(2)）。   圖四 上圖：查詢符合特定條件之元件；下圖：元件與外加檔案為多對多關係 上述軟體運作環境，皆假設BIM建築元件幾何屬性資料的部份已無異動，方能在初次使用時轉換至空間資料庫內，使得BIM模型內實際幾何資料與空間資料庫最小方盒資料一致。透過對最小方盒的條件查詢，多樣化的動態分類以至於關連到外加檔案機制，便可使BIM扮演資料中控端的角色，與其他軟體應用程式進行良好互動。 兩者互相支援 加乘效應 BIM軟體具有優異的視覺化能力，也具有完善的3D空間資料處理能力，確實已能協助建築物之規劃、設計與施工階段眾多資訊應用服務。然而，如同現今雲端資料庫與傳統資料庫各有所長的現象，BIM資訊模型與空間資料庫的設計理念不同，若能截長補短，使得BIM專注在視覺化與3D資料編輯(新增/修改/刪除)工作上，而空間資料庫則聚焦在資料查詢上，相信此混合式作法，尤其對生命週期後期階段的軟體應用程式將有很大助益。 現今部份空間資料庫產品仍未完全實作OGC SQL的全部定義，因此BIM軟體處理空間運算中，部份函數的執行效能有時甚至比空間資料庫還快，這其中的分水嶺需學術界或實務界來找到適當的平衡點，以設計資訊分流機制，使得較複雜的空間運算由BIM軟體完成，較簡單但大量的服務則由空間資料庫完成。此外，建築物在營運維護階段仍有可能進行BIM資料的修改，如何適當地反饋至空間資料庫也是另一個值得深入研究的議題。 參考文獻
(本篇刊載於營建知訊385期第56-63頁)
0 評論
發表回覆。 |
文章類別
發佈時間
九月 2019
|
RSS 訂閱
