基于BIM技術的土石方調運程序化探究

閆若鈺， 王宗敏

(鄭州大學 水利科學與工程學院，河南 鄭州 450001)

隨著經濟和施工技術的發展，諸如水利、道路、橋梁等大型基礎設施工程項目的建設規模及施工難度也不斷提高，這就要求在項目的設計規劃階段做出有效決策來優化施工組織設計方案。土石方填挖方量的精確計算，及土石方調運，填挖平衡是施工組織設計中的重要環節，也是影響工程造價與工期的關鍵因素之一[1～3]。工程建設行業目前存在的對土石方工程“重計量而輕設計”的傳統觀念已經無法滿足不斷提高的設計建造標準和成本控制需求。傳統的土石方計量方法(如斷面法、方格法、等高線法、散點法等)操作相對復雜，計算精度不高，無法快速出量，且不方便設計前期多方案比選[4,5]。這些因素都導致了傳統的土方決策方法不能滿足目前工程項目設計規劃周期短、變動快、變更多的特點，以至于很多工程項目在設計前期甚少進行土方調配這項工作，而沒有進行精確的計量和合理的規劃最終會影響整個項目的工期和成本[6～8]。本文將BIM(Building Information Modeling)技術與數學模型求解方法相結合，探索土石方計量與土石方調運的程序化實現，以期找到設計規劃階段土石方計量及調配高效、便捷、精確的解決方案。

1 基于BIM技術的土石方量計算方法

1.1 原始地形數據的獲取與模型建立

原始地形數據的獲取方法有很多，可以向有關部門申請大比例現狀地形圖的使用權；也可以通過現場測繪的方式制作地形圖；隨著遙感測繪技術的發展，無人機傾斜攝影技術也被應用到工程測量中；并以其便捷、高效、精確的特點被廣泛認可[9,10]。無論哪種方式得到的地形原始數據都要經過一定的校核處理滿足誤差限制，然后轉換成Revit可以識別的格式后才能使用。Revit 能識別的帶有高程信息的結構化數據文件主要有：DWG/DGN/DXF格式的三維等高線數據；CSV/TXT格式的高程點數據。選擇Revit “體量和場地”選項卡中 “場地建模”面板上的“地形表面”選項，將處理好的原始地形數據導入，Revit 將自動識別幾何和高程信息，從而創建三維場地模型。

1.2 場地平整與場地劃分

創建好的原始地形表面代表開挖平整前的工程場地，基坑開挖和場地平整可以選擇Revit “體量和場地”選項卡中 “修改場地”面板上的“平整區域”選項。該功能會基于原始地形模型創建新的地形表面，工作人員可按照設計圖紙和施工組織設計規定的開挖平整方案在新生成的地形表面上調整高程，來進行基坑開挖和場地平整：一種方式是添加新的高程點；另一種方式是框選原有高程點調整其高程，高程調整后的地形表面就是模擬開挖平整后的工程場地。Revit會根據兩個地形表面的高程信息自動進行差值計算得出剪切值、填充值、凈剪切/填充值，即對應土石方的挖方、填方、填挖方凈值。

大型復雜的土木工程建設項目施工場地一般有多個分區，設計土石方平衡方案首先需要進行各個施工分區的具體土石方填挖量的統計，Revit 自帶的 “地形明細表”功能可以高效、便捷地將土石方填挖數據統計并顯示出來，且統計是實時的，這意味著后續再進行地形表面高程調整時發生的土石方量變化也會實時改變明細表中的值。但是，在生成地形明細表之前，首先需要按施工組織設計將施工分區在場地模型中劃分出來，以便獨立統計各個施工分區的填挖方量，這個功能需要選擇Revit“體量和場地”選項卡中 “修改場地”面板上的“拆分表面”選項，劃分完成后可根據凈填挖值為劃分出的地塊標記名稱，以便統計。

1.3 土石方填挖量提取

將拆分好的施工分區分別標記好名稱后，就可以選擇Revit “視圖”選項卡中 “創建”面板上的“明細表”下拉選項列里的“明細表/數量”選項創建關鍵字明細表，在彈出的“新建明細表”對話框里將“類別”設置為“地形”，“階段”設置為地形創建的階段，并在隨后彈出的“明細表屬性”對話框里將“可用的字段”列表里的“名稱”“截面”“填充”“凈剪切/填充”添加到右側“明細表”字段框里，點擊確定即可生成地形明細表，其中的字段分別對應劃分好的施工分區名稱、挖方值、填方值、填挖方凈值。

2 基于運籌學的土石方調運數學建模

2.1 運輸問題的數學模型

運輸問題在運籌學中屬于系數矩陣有特殊結構的一類線性規劃問題，具體描述為：

該問題的數學模型為：

(1)

2.2 土方調運數學建模

在土方調運方案的求解中，可利用上述運籌學模型進行分析[12～14]，具體如下：

(2)

(3)

3 Dynamo節點二次開發與數據處理

3.1 IronPython與C# 動態鏈接庫(.dll文件)調用

IronPython是一種在 .NET下實現的 Python 語言。由于IronPython與.NET語言(如C#)良好的互操作性，既可以在.NET程序中嵌入Python腳本，又可以在IronPython環境中訪問.NET程序的動態鏈接庫和類庫里的類，有效地復用代碼，提高效率。Dynamo軟件中的“Python Script”節點(圖1)可以運行嵌入的IronPython腳本，利用這個節點編寫IronPython 代碼，使用IronPython 調用自定義C#類庫(.dll文件)里的類(class)及類的方法(method)可以很好地解決Dynamo原生節點無法完成的求解計算。

圖1 Python Script節點

3.2 C#求解類庫的代碼實現

由于IronPython 不支持CPython 的擴展程序包，導致在Dynamo中無法使用Python腳本調用Numpy和SciPy 求解前述運籌學數學模型，求解該線性規劃問題就需要使用C#代碼編寫自定義類庫(.dll文件)來實現。

微軟的Microsoft Solver Foundation類庫是一個數學庫，可以很好地對線性規劃問題進行求解，在進行求解類庫代碼實現時，需要添加對Microsoft Solver Foundation.dll文件的引用(圖2)，添加引用后就可以調用Microsoft Solver Foundation類庫中的類及類的方法。求解類庫(transportproblem.dll)中主要封裝了三個自定義類：solvedmodel，transportmodel，ToArray，程序框圖如圖3所示。

圖2 添加引用

圖3 程序框圖

3.3 Dynamo求解節點的代碼實現

前述求解類庫中的transportmodel類與solvedmodel類封裝的方法是用來創建模型和求解模型的，求解時直接根據約束條件不同選擇solvedmodel中封裝的不同靜態方法，其本質是solvedmodel類的方法調用了transportmodel類里封裝的方法。ToArray類中的方法是用來解決IronPython 代碼中List數據類型與C#代碼中 Array數據類型不匹配問題，由于solvedmodel中封裝的方法需要Array 類型的輸入參數，但在Python 腳本中無法創建Array類型對象，所以需調用ToArray類中封裝的方法將List類型對象轉換成Array類型對象后再用作輸入參數求解模型。

IronPython調用自定義C#類庫(.dll文件)里的類(class)及類的方法(method)需添加如下代碼：

clr.AddReference('transportproblem')

from transportproblem import*

其中第一個“transportproblem”是求解類庫名，該句作用是將添加求解類庫(transportproblem.dll)作為引用，第二個“transportproblem”是名稱空間(namespace)名，該句作用是引用transportproblem名稱空間，transportmodel，solvedmodel，ToArray三個類都定義在transportproblem名稱空間內，只有添加對它的引用才可以調用其中類的方法。

Python Script節點有輸入端口(IN[0])和輸出端口(OUT)，其中輸入端口可按需要增加，輸出端口只有一個不可更改，本例中調用solvedmodel類的方法需要5個Array類型的參數，故將輸入端口調整為5個(圖4)。節點內部具體代碼如圖5所示。

圖4 輸入端口調整

圖5 運輸問題求解節點內部代碼

3.4 輸入參數的數據處理

Revit中的圖元有很多參數信息，但Revit本身并不具備專業的數據分析計算功能，如求解線性規劃問題，而土方平衡問題需要用線性規劃模型求解，這就要求在Revit圖元中的信息能被提取出來，并能導入到Dynamo中進行分析求解。由于solvedmodel類的方法需要5個Array類型的輸入參數：output(挖方量)、input(填方量)、productions(挖方區)、sales(填方區)、frienghttable(距離矩陣)，故需要將這些信息提取出來作為自定義求解節點的輸入參數。

利用“Categories”節點與“All Elements of Category”節點將劃分的地形圖元提取出來，再利用“Element.GetParameterValueByName”節點將各個填挖方區的名稱及凈填挖值提取出來。但此時的填挖信息是混合在一起的，不滿足輸入參數格式，而Dynamo原生節點無法使填挖信息按要求篩選分離，故使用“Python Script”節點編寫代碼過濾填挖信息，節點代碼、運算結果分別如圖6，7所示。

圖6 數據過濾節點內部代碼

圖7 數據過濾節點運算結果

為便于提取各個分區的位置信息，可在各個地形分區的中心點放置高程點，并按照填挖區名稱給高程點添加參數信息(本例中選擇“底部值后綴”)使之便于統計區分。

隨后即可使用“Categories”節點與“All Elements of Category”節點將標記好的高程點圖元提取出來，再使用“Element.GetLocation”節點與“Element.GetParameterValueByName”節點獲取高程點位置坐標和填挖區名稱，并利用“List.FilterByBoolMask”節點將填挖區坐標篩選分離出來，最后用“Geometry.DistanceTo”節點(使用叉積運算模式)求得距離矩陣。

值得注意的是，“Geometry.DistanceTo”節點運算出的距離以mm為單位，且此時提取的數據由于沒有經過精度處理，小數點后數位太多，代碼運算時容易發生精度溢出從而導致求解程序崩潰，故需在參數輸入求解節點之前進行單位轉換和精度處理，即使用“Convert Between Units”節點和“Math.Round”節點進行單位換算并舍去多余小數位。

3.5 可求解的完整Dynamo節點

通過輸入參數的處理和自定義節點的開發，可以程序化求解土石方調運問題的Dynamo節點完整連接，如圖8所示。

圖8 完整節點連接

4 算例分析

4.1 建模與求解

以某項目土石方工程為例，原始地形、填挖區域標記、土石方凈填挖量分別見圖9～11，由前述信息可知，本例中有：4塊凈挖方區，分別標記為W1，W2，W3，W4；3塊凈填方區，分別標記為T1，T2，T3。為直觀清晰表達土石方調運數據，各個分區填挖量凈值及相對運距詳見表1。由表中右下角數據可知，總挖方量為81284 m3，總填方量為71595 m3，總挖方>總填方，屬于產大于銷的運輸問題，應按照產大于銷的約束情況建立線性規劃模型。

表1 土石方調運數據

圖9 地形表面創建

圖10 地形表面劃分

圖11 地形明細表

由于求解類庫中定義的solvedmodel類封裝了三個方法PeuqalS，PlargerS，SlargerP；分別對應產銷平衡問題求解、產大于銷問題求解、產小于銷問題求解，所以在總挖方>總填方(產>銷)的情況下，需在Dynamo的“Python Script”節點中調用PlargerS方法求解本例的數學模型，當處理好的輸入參數連接到求解節點后即可進行模型求解，節點運算結果見圖12，整理后結果見表2。

表2 土石方調運求解結果

圖12 節點運算結果

4.2 結果分析

由表1，2中數據可以看出，與挖方區W1距離最近的填方區是T1，W1需要就近向T1調運29764 m3土石方，因W1可調用土石方已用完，所以挖方區W1不再向填方區T2，T3調運土石方；與挖方區W3距離最近的填方區是T3，W3可調用土石方只有3063 m3不滿足T3需求方量20045 m3，所以W3全部土石方運往T3后還需向距離T3第二近的挖方區W4借土16982 m3；與填方區T2距離最近的挖方區是W4，W4向T3運土后余量為7188 m3全部運往T2，此時T2還有需求量未滿足，故向距離T2第二近的挖方區W2借土3100 m3，至此 T2，T3的需求方量都已滿足，W1，W3，W4可調運土石方已用完，因此挖方區W2需要往填方區T1調運11498 m3土石方來滿足填方區T1總需求方量41262 m3。 為直觀表示調運方案，詳情如圖13所示。

圖13 土石方調運方案圖示

5 結 論

(1)隨著BIM技術的發展與成熟，用程序化方法進行土方平衡決策已經成為可能，本文通過技術論證和編程實踐證明了其可行性、便捷性和準確性，取得了不錯的應用效果，對類似工程項目具有一定的參考價值。

(2)BIM技術應用于工程實踐，已經越來越偏重于信息(Information)的獲取、管理、分析、計算，而不止局限于建筑模型的(Building Model)應用，所以編程思維將極大地提高信息的利用效率，Revit與Dynamo的有機結合還有很多值得思考探索的空間與價值。

(3)本文只考慮了運距對調配方案的影響，而沒有考慮到如運輸路線、施工順序等對該數學模型價值系數的影響，這些都有待進一步深入研究。本文初步實現了利用IronPython 腳本調用C#動態連接庫求解運籌學模型，說明其他工程類計算也可以尋求程序化解決方案，以期創造更高效、便捷的求解方式。