基于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#动态连接库求解运筹学模型，说明其他工程类计算也可以寻求程序化解决方案，以期创造更高效、便捷的求解方式。