BIM 應用中建筑與結構專業之間數據的共享與轉換

申瑋

(北京盈建科軟件股份有限公司)

十八世紀中葉以前，民用建筑的建造負責人并沒有區分建筑設計師和結構工程師。后來，隨著建筑設計和結構設計的理論、方法的持續發展和復雜化，建筑設計和結構設計逐漸分離，并由不同知識背景的專家負責。不過，道路、橋梁領域由于其自身特點，沒有出現這種現象。

如今，由于計算機技術已經取得了極大的突破和發展，隨之而來的，似乎有一種趨向，即計算機技術和BIM 正在驅動建筑設計和結構設計在虛擬世界重新融合。這實際上是從另一個角度表現出科學技術作為生產力的重要作用，以及科學技術為打破行業壁壘、實現高效生產做出的貢獻。

但是，計算機僅僅是助手，而不是主宰。計算機要想達成預定目標，需要人的參與。本文將努力梳理出這個領域的實現路徑，希望能為相關技術發展提供一些參考。

1.建筑信息傳遞標準

長期以來，建筑領域的CAD 技術主要可分為基于圖素的策略和基于模型的策略[1]。基于圖素的策略以AutoCAD為代表，通過點、線、面另加自定義實體，在設計院取得全面成功。但如今，以基于模型的策略實現的軟件正在廣泛進入人們的視野，并且使用范圍大量增加。

本質上，這并不是二維設計和三維設計的區別，因此，無論是二維設計，還是三維設計，在基于模型的思想指導下，都有可能在專業協同中發揮重要作用。實際上，加強專業協同對建筑全生命周期各個階段相關參與者的創新活動都有積極影響[2]。通過基于模型的策略實現專業協同時，尤其強調參與方整體系統性的應用和工作創新[3]。

本文重點關注設計階段的配合問題。首先學習和研究國際上的建筑領域信息傳遞標準，作為分析的開始。

1.1 Domain specific data schemas

以IFC4_ADD2_TC1 Schemas為例，其中在Domain specific data schemas（領域特定）層級下，可看到IfcArchitectureDomain（建筑設計）、IfcStructuralAnalysisDomain（結構分析）、IfcStructuralElementsDomain（結構設計部件）這三個子類別。

在IfcArchitectureDomain 子類別下，包括IfcDoorStyle（門）、IfcWindowStyle（窗）等。

在IfcStructuralElementsDomain 子類別下，包括 IfcFooting（基礎）、IfcReinforcingBar（鋼筋）等。

在IfcStructuralAnalysisDomain子類別下，包括IfcStructuralMember（單元）、IfcStructuralLoadCase（荷載）、IfcStructuralConnection（連接）等。

可見，在Domain specific data schemas（領域特定）層級下的數據，是嚴格區分建筑設計專業和結構設計專業各自特定的內容，不存在相互重疊。

1.2 Shared element data schemas

以IFC4_ADD2_TC1 Schemas為例，其中在Shared element data schemas（共享定義）層級下，可看到IfcSharedComponentElements（組件）、IfcSharedBldgElements（構件）。在IfcSharedComponentElements 子類別下，包括IfcBuildingElementPart（部件，如三明治墻的各層子墻）、IfcElementComponent（附屬件，如埋件、連接件等）。

在IfcSharedBldgElements 子類別下，包括IfcBeam（梁）、IfcColumn（柱）、IfcSlab（板）、IfcStair（樓梯）、IfcWall（墻）、IfcCovering（可表示如天花板、地板、踢腳線等）、IfcCurtainWall（幕墻）、IfcMember（支撐、弦桿、梁單元等結構單元）、IfcRoof 等。

以IfcWall（墻）為例，進一步看其屬性信息，可分為MOVABLE（如折疊墻）、PARAPET（如陽臺邊緣防護欄）、PARTITIONING（如石膏板墻）、PLUMBINGWALL（如封閉衛生室中的管道的一個墩或外殼）、SHEAR（如擋土墻）、SOLIDWALL（承重墻，包括現澆混凝土墻和預制混凝土墻）、STANDARD（常規墻，墻厚不延路徑變化）、POLYGONAL（多邊形垂直拉伸墻，墻厚延路徑變化，已棄用）、ELEMENTEDWALL（一種用螺柱框架的螺柱墻）、USERDEFINED（用戶定義）等。

可見，在Shared element data schemas（共享定義）層級下的數據，沒有按專業區分，一般是各專業共同使用的數據。

1.3 小結

按照IFC Schemas 的思想，意在Shared element data schemas（共享定義）層級，實現建筑設計和結構設計的構件定義融合。

2.跨軟件的策略

OpenBIM 提倡不同軟件之間通過開放的數據格式，和與之適配的工作方式，來實現建筑設計全流程數據協作。

2.1 建筑設計和結構分析

在Achicad 中，建筑設計數據和結構分析數據可能是各自獨立定義的兩套數據集。同時，結構分析模型不是一個憑空創建的模型，而是在建筑模型創建好后，作為其物理模型的簡化表達。

Archicad 中的模型構件都有一個參數記錄承重還是非承重。Archicad 可以基于建筑物理模型的承重部分生成結構分析模型(關于這一相互轉換過程中，軟件無關的具體實現策略，有相關研究[4]），結構分析模型和物理模型實時關聯。比如，當建筑的物理模型發生變化時，對應的結構分析模型將會自動更新。反之，當結構分析模型變化時，理論上，建筑的物理模型也可以跟隨。另外，也有關于非承重建筑構件傳遞到結構分析模型的研究（軟件無關）[5]。

建筑設計模型和結構分析模型之間的關聯關系主要通過結構分析格式(即SAF,這種格式適合儲存和共享結構分析數據)實現。

如圖1 所示的例子，是一根梁構件和其結構分析模型的對比。

圖1 梁和其結構分析模型（圖片來源：Grahpsoft官網）

如圖2 所示的例子，是柱構件、墻構件、板構件和其結構分析模型的對比。

圖2 柱、墻、板和其結構分析模型（圖片來源：Grahpsoft官網）

2.2 建筑設計和結構詳細設計

在AchiCAD 中，可能不存在結構詳細設計的數據信息，可通過IFC 格式導入其他軟件進行詳細的結構設計。（根據第一章，在IFC 數據中，Shared element data schemas 規定了導出跨專業共享構件信息的方式，Domain specific data schemas 層級規定了導出結構分析專用數據的方式。）

AchiCAD 的歷史非常悠久，其所屬公司Graphisoft 很早就在buildingSMART 中活動，長期支持IFC 標準研究。因此AchiCAD 對IFC 標準的支持應該是比較深入的。

在建筑設計模型和結構詳細設計模型之間的數據傳遞中，會涉及IFC 標準中3D 元素和非幾何數據。具體方法可能是將構件數據直接一一對應，以墻構件為例，從ArchiCAD 導入結構詳細設計軟件時，將其直接轉化為對應結構軟件中的墻定義即可。

如圖3 所示的例子。是墻（可從IFC 中導入）在詳細設計軟件Tekla 中的樣子，

圖3 Tekla中的墻（圖片來源：Trimble官網）

如圖4 所示的例子。是墻（可從IFC 中導入）在詳細設計軟件Tekla 中深化（鋼筋設計）以后的樣子。

圖4 Tekla中墻的深化設計（圖片來源：Trimble官網）

2.3 小結

由此可見，ArchiCAD 中的建筑物理模型可利用SAF 轉為ArchiCAD 的結構分析模型，然后通過SAF 或者IFC 直接對應其他軟件的結構分析模型；ArchiCAD 的建筑物理模型通過IFC 直接對應結構詳細設計軟件的詳細模型。（幾何數據直接對應轉換。）

3.整合的策略

Revit 將建筑設計和結構設計放到同一個軟件中，走出一條以整合策略為導向的道路。有實際項目驗證如何使用Revit 與其他軟件結合，在項目早期進行項目級各專業設計數據的計算、檢驗[6][7]；以及在Revit 中異形結構構件形狀的創建[8][9]。

3.1 建筑模型和結構模型

在Revit 中，建筑設計和結構設計雖然分屬不同的菜單欄，但畢竟屬于同一個軟件，它們基于相同的構件數據定義。

關于墻的創建，無論在建筑設計菜單，亦或是結構設計菜單下，均可以選擇創建non-bearing wall（Wall:Architectural）或者structural wall（Wall：Structural）。

關于柱的創建，無論在建筑設計菜單，亦或是結構設計菜單下，均可以選擇創建Column：Architectural（建筑柱）或者Structural Column（結構柱）。建筑柱可理解為包裹在結構柱周圍并起裝飾作用的幾何體。

關于梁的創建，僅可以在結構設計菜單下創建Beam。建筑菜單下沒有梁。

關于板的創建，在建筑設計菜單，可以創建roof、ceiling、建筑板（Floor:Architectural）、結構板（Floor:Structural），在結構設計菜單僅可創建結構板（Floor:Structural）。

Revit 的目標是要建筑設計師和結構工程師用同一個軟件、基于同一個項目進行日常工作，將建筑設計軟件和結構設計軟件合二為一。帶來的負擔是，對于建筑師來說，建模型時就要按照承重或者分承重來布置構件，當然后續結構工程師會調整。由于既不是純粹建筑設計軟件，也不是純粹結構設計軟件，缺點可能是：無論建筑設計師，還是結構設計師，經常會覺得不順手。

在Revit 中，建筑設計模型和結構設計模型合并處理，本文將其統稱為“建筑（結構）詳細模型”。

如圖5 所示，是Revit 中建立的“建筑（結構）詳細模型”。

圖5 Revit中的“建筑（結構）詳細模型”（圖片來源：Autodesk官網）

3.2 結構分析

在Revit 中，結構分析模型依然是獨立于“建筑（結構）詳細模型”之外的一套單獨定義。因此，雖然存在于同一個軟件下，仍需一種在“建筑（結構）詳細模型”和結構分析模型之間的轉換規則。

在Revit 中，結構分析模型理解為“建筑（結構）詳細模型”的一種為滿足計算所需而對應的力學簡化。

3.3 小結

Revit 的定位是信息資源豐富而全面的軟件。用戶可以從一開始就定義大量詳細的建筑和結構設計細節，建筑設計師和結構工程師在同一個軟件下，操作不同的數據。

4.裝配式建筑

無論是跨軟件的策略，還是整合的策略，其目標和理想是一致的。即發明某種計算機技術的實現方式，將建筑設計過程和結構設計過程互通互聯，融合工作，使之不再相互割裂，消除設計信息孤島。專業融合一定有利于提高生產力。

裝配式建筑的生產特點決定了其必須進行協同設計。在裝配式建筑的設計、建造全過程的BIM 應用中，可以更直接的體會建筑設計和結構設計如何通過BIM 技術實現專業配合。

4.1 跨軟件策略

對于裝配式混凝土結構，一般會區分建筑設計軟件、力學分析軟件、詳細設計軟件。ArchiCAD 的建筑專業物理模型可通過IFC 格式，以幾何對應方式導入預制構件詳細設計軟件（Planbar）。之后，在預制構件詳細設計軟件中，設計師對模型進行拆分和深入設計工作。預制構件的詳細設計軟件也可能是一個綜合軟件，以結構專業為主，同時包含其他相關專業的功能。

如圖6 所示，是在Planbar 中對導入的ArchiCAD 建筑模型進行裝配式詳細設計的界面。

圖6 Planbar中進行裝配式設計（圖片來源：Allplan官網）

對于鋼木結構，可以全程在TEKLA 或者CADWORK中進行，包括模型創建、細節深入設計等。但在進行深入設計之前，應先導入力學分析軟件進行計算驗證。

4.2 整合的策略

Revit 的整合策略中，直接內含了建筑設計、結構分析、詳細設計三方面的模型，并通過規劃好的數據分類來實現共享。

關于Revit 內置的裝配式混凝土結構拆分功能，應該是不局限于結構專業菜單，但是裝配式拆分對象規定必須面向結構墻（structural walls）、結構板（structural walls）。預制構件拆分結果以parts 的形式存在。

如圖7 所示，是Revit 整體模型中，使用Revit 內置功能進行預制構件詳細設計的情況。

圖7 Revit內置功能進行預制構件詳細設計（圖片來源：Autodesk官網）

即便如此，目前為止在國內的設計實踐中，結構計算一般都需要借助外部軟件；裝配式拆分一般借助國內基于Revit 開發的工具集合。

4.3 盈建科內置裝配式軟件

盈建科內置的裝配式軟件和結構計算主流程完全融合在一起。實現裝配式拆分、結構整體計算、裝配式詳細設計操作一體化。似乎可以類比為Planbar（Tekla）+Etabs 的組合（當然，國外軟件目前在大量細節方面仍然領先較多）。

因此，ArchiCAD、天正等建筑設計軟件建立的模型，按照物理模型一一對應的原則轉換到盈建科結構軟件之后，后續設計階段的操作一般均可在不更換軟件的情況下完成。

如圖8 所示，是盈建科內置裝配式軟件中既可用于結構分析，亦可用于預制構件詳細設計的統一模型。

圖8 盈建科內置裝配式軟件整體模型（圖片來源：YJK內置裝配式軟件）

另外，盈建科內置的裝配式軟件已經逐漸遷移到了自主BIM 平臺。實際上，BIM 平臺下的裝配式軟件，裝配式拆分的對象并沒有區分建筑模型還是結構模型。但通常情況下，一般可與Revit 類似地，針對BIM 模型中的結構墻、結構板進行拆分。這應該也是預制構件拆分的本質目標。

5.總結與展望

目前，為達成建筑設計和結構設計專業協同的目標，共同的思路本質是：操作區分專業，數據實現統一。也就是說，在計算機交互操作層面和存儲數據層面，按照各自特點分別處理，最終實現兩個專業的融合。具體實現方式上，可分為跨軟件的策略和整合的策略。前者強調建筑設計數據的幾何特性為中心，可對建筑設計數據的物理幾何信息轉化為結構分析關系，或者將這些物理幾何信息按照幾何一對一的原則轉化為結構詳細設計軟件中的模型；后者讓建筑設計師和結構設計師在同一個軟件下操作各自的數據，其中部分操作數據是專業之間共享的數據，核心思想是軟件框架統一[10]。

以這樣的BIM 方案為基礎，技術應用正在空前高漲，例如，有很多項目在全產業鏈的協同設計、施工過程中，嘗試引入可視化VR 等其他技術[11][12]。

具體的實踐過程中，還應關注其他非技術的問題。比如，在各專業之間逐漸實現更加緊密的配合之后，隨之而來的是設計師的創新型設計和想法的版權更易被侵犯[13]。再如，合作者之間應該采取有效的合作行為，支持一體化的合作模式，才能更好的實現協同目標[14]。

實際操作中，可能會遇到各種障礙，還需要在工作中發現問題、解決問題，迭代實現技術進步和完善。