地铁运营施工冲突检测技术的研究与应用综述

摘要 在地铁运营施工管理中，避免施工冲突很重要。近年来，智能化的冲突检测方法在各大城市的轨道系统中逐渐得到广泛研究和应用。该文探讨了地铁施工管理系统中冲突检测的关键环节，首先介绍了冲突检测的基本概念，接着研究了两种不同的冲突检测算法及其具体逻辑，最后分析了各大城市地铁施工冲突检测方案的相同点和差异性，为地铁运营施工管理提供参考。

关键词：地铁运营施工；冲突检测；检测方案

中图分类号 U231 文献标识码 A 文章编号 2096-8949（2024）18-0171-04

0 引言

随着城市轨道交通系统的发展和规模的扩张，线路基础设施的维护工作日益频繁。其中作业冲突问题会影响施工效率和安全性，因此在地铁运营施工管理中，确保施工环境和人员的安全以及避免施工资源的冲突是至关重要的。传统的施工管理模式难以保障施工作业计划方案的及时性、有效性和正确性，因此形成统一的安全管控体系成为挑战[1]。

近年来，随着计算机技术的发展，智能化的冲突检测方法在各大城市的轨道系统中逐渐得到广泛研究和应用，其在效率、准确率、施工安全性等方面和人工检测相比具有压倒性优势，从而成为地铁施工管理的新趋势。

1 地铁运营施工冲突定义及重要性

1.1 施工冲突的定义

（1）当作业时间存在重叠时，若动车施工封锁区域与非动车作业区域发生重叠，视为冲突。

（2）当作业时间存在重叠时，如果动车施工保护区域与非机动车作业区域相交，也构成了冲突。

（3）当作业时间存在重叠时，两个动车作业封锁区域重叠或防护区域重叠即为冲突。

由冲突定义可知，施工作业冲突的核心在于不同施工活动之间的时间与空间的交叉。当动车施工的封锁区域、防护区域与非动车作业的区域或其他动车作业的区域发生重叠时，就会出现施工冲突。

1.2 冲突检测重要性

施工作业冲突检测指的是使用相关技术手段对时间空间存在交叉的施工任务进行监控和检测其可能发生的冲突的过程，旨在及时发现和解决施工冲突，确保施工任务协调进行。

其重要性主要体现在以下几个方面：（1）施工冲突检测可以及时发现潜在冲突点，从而在规划施工计划时避免作业交叉或资源竞争的情况，合理安排施工作业顺序和区域；（2）冲突检测技术可最大限度确保施工按照要求进行，避免误操作和遗漏，从而保障施工质量，有效减少后续维修的成本和工作量；（3）频繁的作业交叉和资源共享会增加事故风险，冲突检测能够及时发现冲突并采取相应的安全措施，确保施工过程中没有安全漏洞；（4）冲突检测有助于优化资源利用，通过及时发现冲突点来合理分配、调度和利用所需的人力资源、设备和材料。

综上，冲突检测在运营施工管理过程中具有重要意义，其技术的好坏直接决定了其能否准确发现冲突，并且对整个施工安全管理起决定性因素。

2 冲突检测算法

2.1 基于冲突检测规则库的冲突检测算法

在制定施工计划时，资源冲突的检测过程变得异常复杂，需综合考虑多种因素，包括施工时间、作业区域、安全防护区域及电力供应等可能产生冲突的领域。基于冲突检测规则库的冲突检测算法利用规范的施工所需的资源之间的冲突关系，建立起一个包含多维资源冲突检测规则的数据库，该数据库明确定义了人、车、电这三个关键因素之间的冲突逻辑关系[2]。

基于冲突检测规则库的冲突检测算法通过引用一个全面的冲突解决规则库来指导计划资源的冲突校正，如图1所示，其核心思想包括：首先从设备维护系统中整合提交的施工计划，然后应用冲突检测规则库进行冲突分析，以识别计划中的各种资源冲突，随后对识别出的冲突分类并计算具体资源，最后进行确认并优化施工计划。

此外，当一个经历过冲突检测并优化的计划出现新的状态，例如作业时间或者相互关系的变化，这些变化可能引发新的冲突。因此，需要不断重复进行计划的修正和冲突检测，直至所有冲突都被消除[3]。

为提高检测精确度，该算法还需要更多的施工计划辅助信息，在进行冲突检测之前，应采取以下步骤：首先，为施工计划的作业属性分配优先级，通常情况下应优先考虑紧急任务；其次，为施工作业数据添加唯一性标识，以自动评估其对其他施工活动的潜在影响。冲突检测规则库里包含作业时间、作业先后顺序、作业区域范围、行车路线、用电区域等规则逻辑[4]，依据此逻辑的具体实现方法由创建冲突检测引擎实例、初始化数据、调用引擎实例、输出冲突检测结果、优化并重复检测五个部分实现。

基于冲突检测规则库的检测方法具有普适性、灵活性和可追溯性等特点，为施工管理提供易实施和操行的平台、可定制和扩展的空间以及可追溯的冲突发生时间、位置等信息。黄浪浪[5]在冲突检测上采用在施工计划上报各个环节中增加冲突检测提示，建立冲突检测规则库来识别冲突。窦亮等人[6]通过对不同施工计划增加优先级属性、完善属性、明确作业区域等信息，建立冲突检测规则库，从而进行全面可靠的冲突检测。施锦峰[7]认为施工冲突应进行多维度检测，通过设立冲突规则库在作业时间、作业区域、供电分区、道岔操作等方面进行施工计划资源冲突检测。

2.2 基于数学建模的施工冲突检测算法

基于数学建模的施工冲突检测算法是将施工计划信息转化为数学符号，利用函数模型与定义进行比较，确定是否冲突的方法[8]。方法步骤如下：

（1）定义冲突检测基本元素：把地铁各线站点、作业类型、作业区段进行编码标识，如表1所示。按作业类型设定优先级，其中，A1、A2、A3类施工的优先级分别设置为1、2、3优先级数值越小表示优先级越高。

（2）对施工计划进行数学建模：利用施工计划的作业类型、作业开始时间、作业结束时间、作业区段得到该施工计划的数学模型，具体数学模型构建如下，其中数据ZYLX——作业类型，数组Kn——作业开始时间，数组Jn——作业结束时间，数组ZYQDn——作业区段。

施工计划1的数学模型为：

ZYLX=A （1）

式中：ZYLX——作业类型，类型编码A的含义如表3所示。

K1=2：00 （2）

式中：K——施工计划1的开始时间。

J1=4：00 （3）

式中：J——施工计划1的结束时间。

ZYQD1=[（2，4），A] （4）

式中：ZYQD——施工计划1的作业区段，（2，4）——涉及站点编码为2，3，4，A——作业区段为下行线。

施工计划2的作业开始时间和结束时间分别为1：00和1：40，作业区段为上行线，涉及站点编码为6、7、8、9作业类型为A类。其施工数学模型：ZYLX=A ZYLX=A，K=1：00，J=1：40，ZYQD=[（6，8），B]。

施工计划3的作业开始时间和结束时间分别为3：00和5：00，作业区段为上下行线，涉及站点编码为1、2、3、4作业类型为A类。其施工数学模型：K=3：00，J=5：00，ZYQD=[（1，4），AB]。

施工计划4的作业开始时间和结束时间分别为2：00和3：00，作业区段为上下行线，涉及站点编码为3、4、5、6作业类型为A类。其施工数学模型：K=2：00，J=3：00，ZYQD=[（3，6），B]。

（3）利用逻辑算法对冲突进行检测：选取优先级最高的施工计划，将其施工参数作为样本定值，依次与其余优先级低的施工计划比较，判断有无冲突。1）在施工时间的判定中，如果某一施工计划的开始时间晚于参考样本的结束时间，或者其结束时间早于样本的开始时间，则认为两者没有时间上的重叠。如果两次施工作业的时间没有交集，可以直接判断为不存在施工冲突，否则需要进行进一步的分析和判断；2）在施工区域的比较上，首先需要定义几个函数，f（X）——在数组X里取末尾值。如：f（ZYQD1）=f（[（2，4），A]）=A，其中A=1，B=−1，BA=BC=AC=BAC=2。|X|——数组X的绝对值，|−1|=1。fmax（X）——在数组X里取最大值。如：fmax（ZYQD1）=fmax（[（（2，4），A]）=4。f（X）——在数组X里取最小值。如：f（ZYQD1）=f（[（2，4），A]）=2。接着将两施工计划的末尾值进行比较，即利用f（X）函数获取施工数学模型的末尾值，当f≠f样且|f|=|f样|时，直接判断为无施工冲突，否则进入下一步判断。若上述条件不满足，则对该施工计划进行最大、最小值比较，若fmin>f或f>f，则同样判断为无施工冲突，否则判断为有施工冲突。

（4）将申报的施工计划按照上述步骤进行对比，判断是否存在施工冲突。

由步骤（2）所得施工计划集合的信息可得，计划1施工优先级最高，因此将计划1的施工参数作为此次施工冲突检测的样本定值。在施工时间冲突上，J2<K样，故计划2与计划1无施工冲突；其他计划均与计划1有时间交集，进入下一步判断。在施工区域冲突上，f4≠f样且|f|=|f|，故计划4与计划1无施工冲突，而计划3不符合条件，进入下一判断；又f3>f且f3>f，故计划3与计划1有施工冲突，完CKTpxg6vIg2BG9Jbv2NN2g==成所有冲突施工汇总，得到施工2、4与施工1无冲突，施工3与施工1有冲突。

在施工管理中，尽管基于数学建模的冲突检测方面并没有被广泛提及，但其通过数学建模的方式，可以将资源冲突检测问题转化为一个优化问题或约束满足问题，利用数学方法对冲突进行分析和解决。具有几点优势：1）数学建模能够将复杂的冲突检测问题简化为数学模型，利用数学技术进行求解，提高了冲突检测的准确性和效率。2）数学建模能够考虑多个维度的冲突关系，并且灵活地调整权重和约束条件，适应不同要求。3）数学建模方法能进行冲突的优先级排序，帮助施工管理人员制定合理的方案。

2.3 防护区域计算

常见的防护方式有固定防护和动态防护，固定防护作为城市轨道交通行业内普遍采用的方式，具有简单便捷，同时满足安全防护需求的优点。但由于其固定性，易造成防护区域重复占用、接触轨供电带来人身安全隐患等弊端。

采用动态防护策略作为一种创新的保护方法，根据邻近计划的具体特点进行评估和动态计算防护区域，并能根据计划的增加、修改或取消等情况进行相应调整，确保安全性，增加灵活性，提高了轨行区的使用效率，动态防护区域冲突检测分三步，以下是具体步骤：

第一步是建立防护区域规则库，对于不同类型的作业和不同特性的施工计划，建立一个规则库。根据这个规则库，设定了A1类计划的防护区域和供电安排规则，如表2和表3所示。

第二步是自动生成防护区域，生成方法内容描述如下：

（1）在计划发布和取消阶段，筛选出即将发布和取消的A1类计划，生成一个结果集R1。

（2）识别出与现有计划在施工时间和所属线路上重叠的所有即将发布和取消的A1、A2类计划，将这些计划按施工时间分成n个时间段，并确定每个时间段内与现有计划施工区域最接近的左右两侧计划作为P。

（3）计算现有计划施工区域与其左右两边最近计划之间的距离，并将该区域划定为防护区。

（4）重复上一步完成结果集中所有计划的防护区域查找后，集中所有找到的防护区域，合并同一时间段内重叠部分，并将每个计划的每个时间段的防护区域数据存储到数据库中。

第三步是执行自动化的防护区域冲突检测，具体步骤如下：（1）对于新增的A1类计划，需将其施工区域分别向两侧延伸，覆盖一个站台轨行区和一个相邻的区间轨行区的长度。首先检查扩展区域内是否已有其他施工计划，若存在，则认定为计划冲突，不允许提交该计划。（2）对于新增的A2类计划，也同样将施工区域向两侧扩展相同长度。

在这种情况下，若扩展区域内存在A1类计划，则认定为有计划冲突，但仍允许提交计划。

3 地铁运营施工冲突检测技术案例

3.1 各大城市地铁冲突检测技术

天津地铁在冲突检测环节，通过编写结构化查询语言，构建施工管理基础数据库。计划申报过程中，系统基于申报的施工计划建立作业冲突检查视图，最后对存在冲突的计划进行合理调整。

青岛地铁在施工计划申报管理方面提出施工资源冲突检测功能，系统对各类别施工计划间进行多个维度冲突检测。同时新增多线共用车辆段内跨线施工作业、站外动火作业前许可检测、有限空间作业前许可检测等多种冲突检测模型[9]。

西安地铁提出建立冲突检测规则库，明确“人、车、电”三个要素相互冲突的逻辑关系，并利用基于数学建模的冲突检测方法自定义冲突检测规则。

金华地铁以智能图版为基础建立轨道交通施工冲突检测模型，其重点提到冲突检测的设计应找到检测机制严谨性和灵活性的平衡点，以及线上自动处理和线下人工处理的紧密衔接[10]。

3.2 相同性及差异性

对于冲突检测技术的具体方案，各大城市地铁给出了各自的答案。西安地铁提出基于数学建模的冲突检测方法，结合冲突检测规则库，更好地服务于该地铁施工管理系统，为施工资源冲突管理提供双重保障。金华地铁提出全自动检测方法不能完全代替人工解决资源冲突，固化的业务规则反而易导致不灵活的情况，因此该地铁在冲突检测的设置上应寻找严谨性和灵活性的平衡点，在固有的冲突检测模型基础上增添施工负责人对冲突进行判定的环节。天津地铁给出建立作业冲突检查视图的可视化方案，将施工计划的作业时间、作业区域、作业条件等信息以图形方式直观展示出来，为冲突检查提供直接依据。

4 结论

该文深入探讨了地铁施工管理系统中冲突检测的关键环节，阐述了冲突检测的类型和其在地铁施工管理中的重要性。通过运用数学模型和冲突规则库，地铁施工冲突检测的高效性和准确度得到了显著提升。在后续的研究中，应进一步探讨冲突检测方法的智能化、自动化和数据整合等方面，以推动地铁建设向更加智能化、高效和可持续发展的方向迈进。

参考文献

[1]娄栋乾.城市轨道交通线网运营施工调度管理系统的建设与实践[J].城市轨道交通研究，2018（S2）：55-57+72.

[2]崔建明.地铁运营企业施工管理系统设计与实现[J].中国信息化，2019（1）：66-68.

[3]刘纪俭，沈小兵.基于地铁运营施工管理系统的资源冲突管理系统实现路径[J].城市轨道交通研究，2014（7）：85-88.

[4]赵俊华，张铭，宣秀彬.城市轨道交通智能施工调度管理系统研究与实现[J].铁路计算机应用，2019（8）：62-67.

[5]黄浪浪.地铁运营施工调度管理系统的应用与研发[J].现代商贸工业，2017（30）：98-99.

[6]窦亮，赵留杰.郑州地铁施工管理系统研究[J].铁道通信信号，2013（5）：49-51.

[7]施锦峰.城市轨道交通智能施工调度管理系统建设与应用[J].现代信息科技，2022（13）：167-171.

[8]刘鑫.浅谈施工冲突检测的逻辑算法[J].科技资讯，2016（23）：24-25.

[9]赵宏宇，陈立乾，凌钰程，等.青岛地铁运营施工调度管理系统升级探索与实践[J].价值工程，2023（1）：19-21.

[10]杨文锐，田丰，叶舒渊，等．基于智能图版的金义东施工冲突检测模型的研究与实现[J]．电子技术与软件工程，2023（6）：139-142.