類比城市消防的艦船滅火救援路徑優化方法探索

丁曉春，魏周君

(1.上海市消防局，上海 200050;2.中國船舶重工集團公司公司第七二六研究所，上海 201108)

0 引言

隨著現代艦船自動化程度的提高，設備配置數量劇增，且往往運轉時間長、功率大、負荷強。由于戰略要求，艦船時常需要作為獨立的航行體在遠洋長時間執行任務，這就決定了艦船在面對各種火災突發事故時必須立足于“自救”，依靠自身力量來應對危險。20世紀主要海軍國家共發生518起艦艇 (包括航母)事故，其中沉沒事故242起、受損事故276起，沉沒事故中由于火災和爆炸造成的約占37%，而在受損事故中由于火災和爆炸造成的占50%［1］。因此，為了減少艦船火災造成的損失，艦上人員必須要在第一時間展開消防行動，實施及時、有效、有序的應急處置措施。而保障這些行動實施的一個至關重要環節就是，如何引導艦上人員以最短的時間、最優的路徑直達火災區域實施滅火救援。

同樣，滅火救援路徑的有效規劃在城市消防中也是一個關鍵的問題。據統計［2］，2011年，上海火災形勢總體穩定，未發生重大以上火災事故。全年共發生火災5813起，累計造成43人死亡，46人受傷，直接財產損失11000.4萬元，同2010年相比有不同的變化。據統計，全市、中心城區以及市郊區域四項指數 (火災起數、死亡數、傷人數、火災損失)如表1所示。

表1 2011年上海市分區域火災四項指數表Tab.1 The 4 index of 2011's fire disaster in shanghai

由表1可知，上海市市郊區域無論在死亡人數、受傷人數還是在火災損失上均占較大比重。據上海消防接處警數據不完全分析，上海市郊區域消防站消防力量從消防站接警出發到到達現場時間一般在15 min，而中心城區消防站則僅需10 min。火災損失的波動性與火災的持續時間、燃燒物類別、過火面積等因素有關，但如果在火災發生后的短暫時間內，消防力量能有效地到場控制火勢，則火災損失會大大減少。如何能在火災案情發生的第一時間及時有效地部署警力，安排救援方案，及時到達現場是火災救險的關鍵。根據國家標準GB 50313－2000《消防通信指揮系統設計規范》要求，消防通信指揮系統必須建立消防地理信息系統，以實現滅火救援接處警過程中，利用地理信息系統方便地實現快速定位和查詢分析、出動方案編制、移動指揮和動態跟蹤以及現場信息服務和輔助決策等功能。

本文以上海市消防信息系統建設為案例，從滅火救援路徑優化的新要求出發，設計研究了一種采用功能模塊化、多層次綜合建庫以及算法設計的新系統，并進行了相應的實驗分析，可為大型艦船滅火救援路徑優化研究提供方法參考。

1 消防信息系統的新要求

1.1 海量多層次數據分析

交通網絡建設大大方便了人們的出行，對于消防來說，也大大提高了出任務的效率，更多地保證了人民的人身財產安全。但同時，隨著交通網絡的發展，也對消防出警提出了新的要求。首先，汽車保有量的急速增加加大了交通壓力，交通擁堵情況增多，這客觀地為消防出警增加了困難，所以，規劃一條快速、準確到達的道路對出警來說至關重要;其次，城市交通向立體層次發展后，對道路定位導航的準確性要求提高，如高架上車輛起火，若定位稍有偏差，規劃路線導航至地面，那么，即使抬頭就能看到火情，也要去尋找高架出入口才能上橋救火，將延誤戰機。這突破了以往平面道路網的構建模式，傳統的平面路徑分析已不能滿足需求，因此需要對傳統的地面消防路徑規劃進行改進，以滿足當前的多層次立體式交通網絡，從而達到定位準確，最優規劃的效果。

另外，道路數據的急速增加使得路徑規劃的數據量增大，多層次立體交通網絡的分析增加了算法的復雜度。在海量且復雜的數據基礎上，依然保持算法的高效性同樣也是需要解決的問題。

1.2 數據多源化的系統架構

互聯網技術的蓬勃發展帶來了計算機技術的二次飛躍。由于互聯網上共享的信息成爆炸式增長，使得用戶對計算機的操作從依靠單機客戶端逐漸轉變為依賴互聯網提供的各種服務。這也使得開發人員對系統的架構進行了適應性的改變。這種轉變對消防信息系統提出了新的要求:

1)信息多源化

消防信息系統龐大而復雜，涉及到方方面面的數據，如接警數據、消防業務數據、城市基礎地理數據、交通流量數據等。這些數據并不來自同一個管理部門，需要多個部門協調，共同提供。而各個部門又有自己的一套數據結構和調用方式，這都需要系統在接收到相關信息后進行協調整理，得到適應本系統的格式。

2)目標多源化

目標的多源化包含2個方面的需求。一方面，由于消防系統本身的要求，需要提供車輛選擇、中隊選擇、單車路徑等分析結果，這些功能雖然本質上都是對最優路徑進行分析查找，但由于其各自特點，所以在細節上需要區別對待，體現在程序上就是需要對功能結構進行設計，保證其基礎算法通用，并在此之上增加靈活性;另一方面，目前各部門系統之間的數據、功能經常需要共享合作，因此，在進行方法設計時同樣需要考慮到外部調用的通用性，以適應不同需求。

2 應對策略

為解決上述問題，在進行系統設計時，采用功能模塊化、多層次綜合建庫以及算法設計3個方面來具體應對，滿足消防信息系統的要求。

2.1 功能模塊化

針對數據來源多，功能應用目標多的特點，系統采用了將功能模塊化的方法 。這種方法類似于“搭積木”，將每個功能包裝成一個“積木塊”，而整個系統就是由一個一個的“積木塊”組合而成。這樣做的好處，一是每個模塊相對獨立，外部來源數據統一交由系統來調度，模塊只負責對輸入數據進行分析處理;同樣，輸出固定格式的輸出數據，也無需考慮數據輸出后的具體用途;二是一旦系統出現問題，很容易進行跟蹤和定位，迅速找出出現問題的模塊，進行調試維護。并且在調試過程中，由于模塊相互間的獨立性，其他模塊并不影響使用，而使維護成本降至最低。

網絡時代的系統特點是“瘦客戶端”，即將壓力轉移至服務器，而在客戶應用端僅需簡單的瀏覽器即可，一切均通過服務調用的方式從服務器端獲取。這樣做降低了對客戶端硬件的要求，并且隨著互聯網的發展，在可移動性上的優勢也日漸明顯。為了適應這種發展趨勢，并且針對未來可能存在的為其他系統調用的情況，系統將各模塊包裝成WebService的服務模式，客戶端通過調用服務的方式從服務器端獲得相應的功能分析結果。

2.2 多層次立體交通網絡數據庫建庫

1)空間拓撲

立體道路網絡對交通網絡數據庫的拓撲結構帶來了新要求。傳統平面交通網絡在僅考慮物理連通性時，只需要在道路交匯口處進行道路拓撲打斷，保持路段連通即可。若考慮到道路名稱等屬性信息，則還需要在道路屬性變更處 (如道路名稱改變處)進行拓撲打斷，保證每條路段的屬性信息唯一。但立體交通網絡打破了這種簡單拓撲關系，如圖1所示。

圖1 多層次立體交通網絡Fig.1 Multi-level 3－D transportation network

從道路線來看，圖1中高架道路交叉口處與地面道路多處相交和自交。但從實地影像可以清晰地看出，高架道路是在地面道路上方穿過，而高架本身也是由多層高架、上下匝道和地面道路組成的復雜結構，拓撲關系從投影上看十分復雜。為此，在建立導航數據庫時，引入虛交點概念，制訂規則來構建立體交通網絡拓撲結構，如圖2所示。

圖2 虛交點與實交點示意圖Fig.2 The schematic diagram of real and virtual intersection

虛交點，即2條道路在視覺上相交，但現實中并不相交的虛擬交點，如圖2中圓形點所示。實交點，即相對于虛交點而言，為道路在現實中的真實交點，如圖2中三角形點所示。在構建立體網絡拓撲時，訂立規則:道路在實交點處必須打斷，在虛交點處不可打斷，以此來保證道路網的拓撲正確性。

2)道路隔離帶設置

許多道路為規范行駛，設定中央隔離帶，以鐵柵欄或花壇等來隔離對向行駛的車輛，最基礎最簡單的隔離帶就是地面的雙黃線。為了方便道路網路徑規劃，減少算法復雜情況處理，對于設計有中央隔離帶的道路，統一將其拆分為2條平行道路，分別設定其行駛方向，避免出現算法計算時在隔離帶處掉頭的情況，規范行駛路線，如圖3所示。

圖3 隔離帶道路轉雙線道路Fig.3 Transfer from isolation belt road to two-lane road

3)多層次道路設計

國家標準規范中，道路由于其寬度、車道數、承重、材料、里程等不同而分為不同等級。在導航數據庫設計的時候，依然要考慮道路等級，畢竟道路級別越高的道路越暢通，載重限高的范圍也比較寬泛，適合消防車緊急出動。需要注意的是非地面道路，如高速公路、高架公路、快速路等。非地面道路通常速度快、路面好、級別高，但存在一個致命的問題，就是因為其離開地面，所以靈活性并不好，一旦錯過上下出口，就要繞行很遠的距離。更嚴重的是，如果出現擁堵，那將寸步難行，沒法補救。因此，必須在道路網絡里進行分類，將非地面道路和地面道路加以區分，用來在一定條件下設定非地面道路的可行或限行 (如高架上出現擁堵狀況)。

4)屬性信息設計

除道路本身的幾何數據和拓撲關系，為完善路徑規劃的細節以及考慮到未來數據的更新，每條道路路段都附有屬性信息。屬性信息大致分為3類:路段本身信息、交通信息、數據庫更新信息。

路段本身信息，即道路本身屬性，如道路名稱，等級等;交通信息指的是人為附在道路上的相關信息，如行進方向，轉彎限制，車輛限制等;數據庫更新信息則記錄了路段的采集時間，歷史更新記錄，更新方式等信息。

2.3 路徑分析功能設計

路徑分析功能采用經典的Dijkstra算法，并加以優化［3］。同時加入多因素對道路權值進行綜合評價，最終選取最優路徑作為結果返回，具體流程如圖4所示。

首先建立道路關系的有向圖。將每一個道路交叉路口看作是圖節點，路段看做是連接圖節點的路徑，而道路權值則代表了穿過路徑所用的成本，其中最簡單的成本就是道路長度，路段長度越長則通過的成本越高。考慮到多重因素，則可利用多因子建立綜合評價矩陣來確定每條路段的具體成本。

圖4 路徑規劃流程Fig.4 The flowchart of path planning

道路權值的綜合評價因子有2種類型，一是成本要素;一是限制要素。成本要素表示該要素對道路起到了加速或阻礙作用，如前文提到的道路長度;限制要素則是判斷類型，即當滿足該條件時道路可以通行，當不滿足該條件時，道路不可通行，如道路的單行限制，其規定了道路的車輛行進方向，一旦反向，則該道路不可通行;又如轉彎限制，當路口限制左轉行駛時，則對于左轉車輛來說，該路不通。

因此，在建立評價矩陣時，首先根據限制要素，判斷通行與否，再利用成本要素確定通行路段的成本，最終根據矩陣計算的權值來規劃最優路徑。

3 實驗及結果展示

基于上述方法，最終設計算法，設計兩點驗證其結果，如圖5所示。

圖5 兩點間路徑規劃結果Fig.5 Path planning results between two points

圖5為輸入起點、終點之后得到的兩點間最優路徑規劃結果。一是圖面上左側點為起點，右側點為終點的行進路線;二是起始點相反。從結果路線來看，兩者規劃出的路線并不相同，雖然看起來起點終點并未移動，但該段道路是有中央隔離帶的城市主干道，在數據庫中用單方向雙線道路表示，從起點出發，必須達到交通路口才可能轉彎或掉頭，因此形成了這一狀況，而現實證明，2條路徑規劃結果符合道路網絡實際要求。劃方案，并為方案排序，按成本從低到高返回結果，便于用戶進行統籌派車。

圖6 多點路徑規劃結果Fig.6 Path planning results between multi-points

4 結語

本文針對快速開展消防救援的需要，以上海交通的實際情況出發，從系統模塊、數據庫建設及算法設計方面介紹了消防地理信息系統中路徑規劃的設計方案，并予以實驗展示。在接到火災報警時，能夠及時完成多支救援小組到著火點的路徑規劃，并進行排序返回，便于合理配置;對于各支救援小組，則可以根據自己所在位置規劃到著火點的具體路徑，方便行動，從實驗結果和具體應用上來看，符合消防救援路徑規劃的要求。結合大型艦船實際情況和條件限制，如通道設計、救援優先級、火災類型、損管應急預案等，改進和完善算法，可有效實現艦上人員最快、最優直達火災區域實施滅火救援的目標。

［1］管光東.海戰·事故·艦船破損［M］.北京:國防工業出版社，1997.

［2］公安部消防局編.中國消防年鑒.2012［M］.北京:中國人事出版社，2012.

［3］朱霽平，茍永華，廖光煊.城市火災撲救調度的最佳路徑分析［J］.火災科學，2002，11(4):201－205.