地鐵運營施工沖突檢測技術的研究與應用綜述

摘要 在地鐵運營施工管理中，避免施工沖突很重要。近年來，智能化的沖突檢測方法在各大城市的軌道系統中逐漸得到廣泛研究和應用。該文探討了地鐵施工管理系統中沖突檢測的關鍵環節，首先介紹了沖突檢測的基本概念，接著研究了兩種不同的沖突檢測算法及其具體邏輯，最后分析了各大城市地鐵施工沖突檢測方案的相同點和差異性，為地鐵運營施工管理提供參考。

關鍵詞：地鐵運營施工；沖突檢測；檢測方案

中圖分類號 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.