李 攀 周兆軍 劉慶杰

1(防災(zāi)科技學(xué)院信息工程學(xué)院 河北 三河 065201) 2(防災(zāi)科技學(xué)院繼續(xù)教育學(xué)院 河北 三河 065201)

0 引 言

我國是自然災(zāi)害發(fā)生比較頻繁的國家,針對海量的災(zāi)害相關(guān)數(shù)據(jù)存在種類多、范圍廣、數(shù)據(jù)復(fù)雜的問題,如何應(yīng)用大數(shù)據(jù)技術(shù),進行數(shù)據(jù)規(guī)律的挖掘,進行預(yù)判,提高數(shù)據(jù)資源的價值,為相關(guān)研究人員提供評價和應(yīng)急決策支持,是非常有必要的。因此,基于統(tǒng)籌協(xié)調(diào)體制、屬地管理體制、社會力量參與機制、信息共享機制及監(jiān)督考核機制[1-3],建立一套應(yīng)急災(zāi)備救助管理系統(tǒng),有利于社會力量統(tǒng)籌,組織綜合領(lǐng)導(dǎo)力量,更好地處理應(yīng)急救災(zāi)工作。如何在自然及次生災(zāi)害發(fā)生時,進行實時響應(yīng)是一個亟待解決的問題,應(yīng)急管理部門需要通過救災(zāi)軟件系統(tǒng),進行受災(zāi)人員救援安排,交通、電力、水利、通信和醫(yī)療等部門部署,統(tǒng)一物資配送和專家實時決策協(xié)同會商等工作。

1 業(yè)務(wù)需求

本項目通過對自然災(zāi)害的調(diào)研和分析,結(jié)合現(xiàn)實需求,應(yīng)用大數(shù)據(jù)技術(shù)[3-8],設(shè)計的應(yīng)急災(zāi)備統(tǒng)籌救助系統(tǒng),是一個基于多維大數(shù)據(jù)、多部門、多職能、多方向的整體統(tǒng)籌管理平臺,從圖1中可以看出,系統(tǒng)包含的數(shù)據(jù)類型、涉及部門及人員非常廣泛,且邏輯流程頗為復(fù)雜多樣,每一個關(guān)節(jié)都對處理的準(zhǔn)確性、時效性有非常高的要求,因此需要對以下難點和關(guān)鍵技術(shù)進行思考,找到合適的解決辦法。

圖1 應(yīng)急災(zāi)備統(tǒng)籌管理流程

1.1 數(shù)據(jù)獲取集成問題

本項目需要將應(yīng)急管理部門、地方政府等相關(guān)行業(yè)和領(lǐng)域的數(shù)據(jù)進行匯總和集成才能進行后續(xù)的分析決策,其中包括了交通、環(huán)保、醫(yī)療、建筑、水電氣、建筑和道路等多方面的數(shù)據(jù),存儲數(shù)據(jù)量之大,超過常規(guī)大數(shù)據(jù)的范疇,而且基礎(chǔ)大量數(shù)據(jù)需要靠人工采集,這也給數(shù)據(jù)庫建立和數(shù)據(jù)集成,帶來了巨大瓶頸。通過元數(shù)據(jù)映射及冷熱數(shù)據(jù)緩存機制,建立與對應(yīng)部門的平臺接口,實現(xiàn)數(shù)據(jù)的匯總響應(yīng)模式。通過基層人員移動終端App的推廣使用,使得數(shù)據(jù)實時錄入更加方便快捷。

1.2 數(shù)據(jù)流實時傳輸分析問題

為實現(xiàn)實時的決策響應(yīng),需要數(shù)據(jù)流的傳輸效率足夠高,信息響應(yīng)速度快,若用傳統(tǒng)的匯總再計算模式,顯然已經(jīng)不合適,需要考慮不僅僅使用主流的分布式計算,同時要發(fā)揮最大算力,帶動本地邊緣計算層,完成快速響應(yīng)的計算,節(jié)省傳輸?shù)膶嶋H,以及核心運算能力。本文應(yīng)用Hadoop架構(gòu)的Spark提供流計算引擎,同時利用邊緣計算技術(shù),讓各終端設(shè)備也發(fā)揮算力,提高計算效率。其中邊緣計算技術(shù)在處理本系統(tǒng)的數(shù)據(jù)時,通過讓各分類數(shù)據(jù)聚集在各硬件終端的處理分析,使得使用端與數(shù)據(jù)段距離更接近,減少了一部分?jǐn)?shù)據(jù)上傳下載到云中心的時間和處理功能,從而縮短了計算時間。在硬件成本上相對減少,各個終端的硬件不再只是收發(fā)數(shù)據(jù),參與計算后建設(shè)了數(shù)據(jù)中心的硬件投入成本,使得總成本較云數(shù)據(jù)中心降低。因為數(shù)據(jù)減少了上下行,使得云中心不僅硬件負(fù)荷降低,而且所需要的帶寬也隨之降低,不再需要極高的網(wǎng)絡(luò)帶寬支持。邊緣計算還因為能降低收發(fā)頻次,降低了延遲級別,使得程序響應(yīng)更高效迅速。面對不同終端用戶的角色不同,導(dǎo)致各終端的應(yīng)用功能出現(xiàn)本地化、個性化,這是為了可以隨時調(diào)整,改善用戶體驗。

由于傳統(tǒng)的云計算模式需要將涉密數(shù)據(jù)上傳至云計算中心,為數(shù)據(jù)傳輸帶來很大的風(fēng)險。因此,在邊緣計算中,本項目采用身份認(rèn)證協(xié)議,加強統(tǒng)一認(rèn)證、跨域認(rèn)證和切換認(rèn)證技術(shù)的研究,以保障用戶在不同信任域和異構(gòu)網(wǎng)絡(luò)環(huán)境下的數(shù)據(jù)和隱私安全。

1.3 多元化多應(yīng)用支持

因為面對的業(yè)務(wù)有些彼此獨立,但是更多的數(shù)據(jù)模型相互交叉,算法又互相關(guān)聯(lián),所以面臨的問題是多種應(yīng)用服務(wù)開發(fā),及對應(yīng)的UI快速開發(fā),傳統(tǒng)架構(gòu)已經(jīng)完全無法滿足,更加無法跟上后續(xù)的追加需求,以及擴展應(yīng)用的快速部署。本文使用SpringCloud后臺架構(gòu)[9-11],結(jié)合Vue.js的前后端分離架構(gòu),使得開發(fā)更快速高效。

1.4 算法模型支持

系統(tǒng)面對的多元化問題,需要對應(yīng)各種應(yīng)急疏散算法、物資統(tǒng)籌算法進行算法結(jié)合,這里需要考慮算法的快速實現(xiàn),以及處理結(jié)果的實時反饋,需要開發(fā)對應(yīng)的算法進行封裝,提供這些算法嵌入接口,為各行業(yè)專家、調(diào)用數(shù)據(jù)、整合調(diào)試模型,提供完善的數(shù)據(jù)平臺,及展示層接口。

2 系統(tǒng)設(shè)計與實現(xiàn)

2.1 系統(tǒng)架構(gòu)

應(yīng)急災(zāi)備統(tǒng)籌救助系統(tǒng),是基于前后端分離的多層次開發(fā)架構(gòu),后端采用分布式微服務(wù)架構(gòu)SpringCloud,前端采用Vue.js開發(fā)框架,實現(xiàn)前后端分離開發(fā),便于快速擴展及系統(tǒng)維護,系統(tǒng)架構(gòu)圖如圖2所示。

圖2 系統(tǒng)架構(gòu)圖

(1) 數(shù)據(jù)層。本系統(tǒng)涉及多種數(shù)據(jù),應(yīng)用的數(shù)據(jù)庫包括:關(guān)系型數(shù)據(jù)庫MySQL和Oracle、非關(guān)系型數(shù)據(jù)庫MongoDB、日志型數(shù)據(jù)庫Redis,還有大數(shù)據(jù)存儲的Hadoop架構(gòu)、Http服務(wù)、Ftp服務(wù)、算法模型庫和行業(yè)專業(yè)庫等。還提供元數(shù)據(jù)庫,將各種其他行業(yè)的管理平臺綜合庫,映射數(shù)據(jù)到本數(shù)據(jù)庫中,節(jié)約數(shù)據(jù)存儲空間,提高運行效率。

(2) 服務(wù)層。需要結(jié)合多種關(guān)系型數(shù)據(jù)庫、非關(guān)系型數(shù)據(jù)庫、元數(shù)據(jù)庫和分布管理多種數(shù)據(jù)源,進行專業(yè)化地搭建。具體包括數(shù)據(jù)庫服務(wù)、算法服務(wù)、硬件接口服務(wù)、文件服務(wù)、元數(shù)據(jù)映射服務(wù)、FTP服務(wù)和日志服務(wù)等。該服務(wù)層的搭設(shè),使得數(shù)據(jù)快速流通,方便存儲,可以高速、便捷、有效地傳遞到上層。

(3) 管理層。提供對應(yīng)服務(wù)層的系統(tǒng)管理應(yīng)用,對服務(wù)層的注冊服務(wù),進行實時動態(tài)管理,包括數(shù)據(jù)管理、中間件管理、接口管理、流程管理、映射管理、模型管理、備份管理等。因為底層采用微服務(wù)架構(gòu),所以對應(yīng)的管理層模塊對應(yīng)著新注冊的服務(wù),需要實時動態(tài)添加。后續(xù)可以快速擴展,通用性很強。

(4) 業(yè)務(wù)層。指系統(tǒng)管理的具體業(yè)務(wù)模塊,面對應(yīng)急災(zāi)備出現(xiàn)的情況,分別考慮了生活物資管理、醫(yī)療物資管理、運輸通道管理、避難場所管理、傷亡管理、水電氣管理和人員調(diào)配管理等大模塊,具體的業(yè)務(wù)在模塊中細(xì)分,可以應(yīng)對地震、火災(zāi)、洪水、瘟疫、化學(xué)泄漏等大型應(yīng)急情況,方便調(diào)用物資、統(tǒng)籌人力、安排避難場所、預(yù)測災(zāi)情、快速反應(yīng)等功能。

(5) 應(yīng)用層。按照不同人員的使用需求,根據(jù)實際情況,開發(fā)對應(yīng)App或者網(wǎng)頁管理終端,包括嵌入式設(shè)備等不同平臺,實現(xiàn)從高層管理到基層實施人員的數(shù)據(jù)互通、消息傳導(dǎo)、快速決策及實時監(jiān)督功能。

系統(tǒng)采用跨平臺方案,可以將服務(wù)后臺和應(yīng)用前端,部署在不同的數(shù)據(jù)服務(wù)器、算法服務(wù)器、物聯(lián)網(wǎng)終端,及多操作系統(tǒng)(包括Windows、Linux、Unix)和多種手機終端(IOS及Android),實現(xiàn)數(shù)據(jù)及應(yīng)用跨平臺互通、跨系統(tǒng)互聯(lián)、實時反饋問題、實時決策的功能,為快速應(yīng)急救災(zāi)響應(yīng)、提供寶貴的時間。

2.2 系統(tǒng)功能

應(yīng)急災(zāi)備統(tǒng)籌救助系統(tǒng)具備生活物資管理、醫(yī)療物資管理、運輸通道管理、避難場所管理、傷亡管理、水電氣管理和人員調(diào)配管理等主要功能模塊,面對突發(fā)的地震、火災(zāi)、洪水、瘟疫、化學(xué)泄漏等大型應(yīng)急情況,可以合理地調(diào)配人員物資,統(tǒng)籌規(guī)劃物資救助。

在主管理模塊中,快速獲取當(dāng)前的基本信息。對當(dāng)前城鎮(zhèn)區(qū)域的受災(zāi)情況、醫(yī)療物資、生活物資,及上下級反饋信息數(shù)量,得到全面了解。

(1) 生活物資管理。通過對米面糧油、衣物、帳篷等必備生活物資的統(tǒng)計管理,形成生活物資庫存統(tǒng)計、出入庫統(tǒng)計、缺貨報警等功能,實現(xiàn)地區(qū)的生活物資管理,方便存儲、調(diào)配、人員運輸以及發(fā)放。

(2) 醫(yī)療物資管理。通過對醫(yī)院、藥房、醫(yī)用倉庫的物資統(tǒng)計管理,形成醫(yī)療物資庫存統(tǒng)計、出入庫統(tǒng)計、缺貨報警等功能,實現(xiàn)地區(qū)醫(yī)療物資的管理,同時通過醫(yī)護人員信息檔案的建立,合理調(diào)配醫(yī)生護士的執(zhí)勤考核、休假等時間規(guī)劃。

(3) 運輸通道管理。通過對高速、鐵路、機場的信息管理,建立災(zāi)情實時運輸指揮中心,尤其面對救災(zāi)人員、物資的應(yīng)急快速通道,方便物流調(diào)配。尤其需要考慮地震火災(zāi)等特殊情況,出現(xiàn)道路橋梁坍塌,需要重新規(guī)劃計算道路的時刻,保證物資第一時間運輸?shù)较嚓P(guān)地點。面對瘟疫等特殊情況,能快速計算道路封鎖點,實時通過攝像頭監(jiān)控人員出入情況,快速高效地實現(xiàn)封城行動。

(4) 避難場所管理。通過對地鐵、大型商場地下室、防空洞、開放避難場所的信息統(tǒng)計,形成避難場所管理,方便快速分散或聚集人群,實現(xiàn)人員物資的集中調(diào)配,實現(xiàn)各個基層分區(qū)的集中力量,快速應(yīng)對災(zāi)情。

(5) 傷亡管理。需要獨立于醫(yī)院體系的管理模塊,實現(xiàn)對受傷人群、死亡人群的快速統(tǒng)計管理,實現(xiàn)數(shù)據(jù)實時更新、基層快速匯報、數(shù)據(jù)實時發(fā)布、人員情況統(tǒng)計、尸體快速處理等功能,使得應(yīng)對地震、火災(zāi)、瘟疫等災(zāi)情時,根據(jù)不同需求,快速聚集傷者或是隔離患者。

(6) 水電氣管理。根據(jù)地區(qū)的水電氣情況,匯總統(tǒng)計災(zāi)情中受損情況、泄漏情況及高危地區(qū)信息,使得決策層能通過多圖層GIS,調(diào)配人員和物資、避難場所,使得人、物、地與高危地區(qū)的遠(yuǎn)離。

(7) 人員調(diào)配管理。通過基層人員信息統(tǒng)計、醫(yī)療人員信息統(tǒng)計、運輸運力人員統(tǒng)計、警力統(tǒng)計等數(shù)據(jù)的匯集,快速完成巨大的工作量,使得人、物、地、路,都在實時通過快速響應(yīng)算法的支持下, 快速合理地分配工作量,實現(xiàn)精確到個人的工作量調(diào)集,工作路線,工作情況匯總發(fā)布。

(8) 其他管理模塊。包括監(jiān)察體系,決策體系,是嵌入到每個具體工作流中的,面對不同角色用戶提供不同的功能。

3 系統(tǒng)方案

3.1 數(shù)據(jù)模型

本系統(tǒng)根據(jù)數(shù)據(jù)繁雜、海量的數(shù)據(jù)量、傳輸計算數(shù)據(jù)量大的特點,設(shè)計了以元數(shù)據(jù)庫為核心,映射各個職能部門及核心數(shù)據(jù)庫的方式,快速讀取響應(yīng)關(guān)鍵數(shù)據(jù),并形成冷熱數(shù)據(jù)緩存,提高數(shù)據(jù)加載效率。對HDFS數(shù)據(jù)采用分布式技術(shù)存儲,大塊非格式化數(shù)據(jù),采用文件服務(wù)器結(jié)合非關(guān)系型數(shù)據(jù)庫的方式,進行數(shù)據(jù)庫的記錄編輯操作。數(shù)據(jù)中間件采用主流的OneProxy、Cobar、Protobuf等中間件進行數(shù)據(jù)傳輸。

3.2 關(guān)鍵技術(shù)

在設(shè)計開發(fā)過程中特別采用了一系列技術(shù)創(chuàng)新手段,為系統(tǒng)的開發(fā)及使用提供了有力的支持:

(1) 數(shù)據(jù)庫映射字典的快速映射技術(shù)。數(shù)據(jù)映射技術(shù)(Data Mapping)是將數(shù)據(jù)字段從源文件映射到與其相關(guān)的目標(biāo)字段的過程[12]。數(shù)據(jù)管理需求和數(shù)據(jù)映射軟件的功能,可以使用數(shù)據(jù)映射來完成一系列數(shù)據(jù)集成和遷移任務(wù)。

過去手工記錄數(shù)據(jù)映射記錄已經(jīng)無法應(yīng)對現(xiàn)在復(fù)雜多樣的情形。舊的數(shù)據(jù)管理方式缺乏透明度,不能跟蹤數(shù)據(jù)模型中不可避免的變化。手工映射還意味著手工編寫轉(zhuǎn)換代碼,這既耗時又充滿錯誤,因此需要從多方面改進:

① 分析人員和架構(gòu)師的透明性。由于數(shù)據(jù)質(zhì)量對于分析結(jié)果的準(zhǔn)確性起到核心作用,所以數(shù)據(jù)分析師和架構(gòu)師需要對數(shù)據(jù)的來源和目的地有一個精確的、實時的視圖。數(shù)據(jù)映射工具提供了對被映射的數(shù)據(jù)結(jié)構(gòu)的公共視圖,以便分析人員和架構(gòu)師都能看到數(shù)據(jù)內(nèi)容、流和轉(zhuǎn)換。

② 復(fù)雜格式優(yōu)化。由于來自不同數(shù)據(jù)源的大量數(shù)據(jù)流,數(shù)據(jù)兼容性成為一個潛在的問題。好的數(shù)據(jù)映射工具通過提供內(nèi)置的工具來簡化轉(zhuǎn)換過程,以確保復(fù)雜格式的準(zhǔn)確轉(zhuǎn)換,從而節(jié)省了時間并減少了人為錯誤的可能性。

③ 減少更改數(shù)據(jù)模型。數(shù)據(jù)地圖不是一成不變的。數(shù)據(jù)標(biāo)準(zhǔn)、報告要求和系統(tǒng)的變化意味著映射需要維護。有了基于云的數(shù)據(jù)映射工具,涉眾就不再有丟失更改文檔的風(fēng)險。好的數(shù)據(jù)映射工具允許用戶在更新映射時跟蹤更改的影響。數(shù)據(jù)映射工具還允許用戶重用映射,因此不必每次都從頭開始。

數(shù)據(jù)映射是數(shù)據(jù)管理過程的重要組成部分,沒有正確映射,數(shù)據(jù)在移動到目的地時可能會損壞。在數(shù)據(jù)遷移、集成、轉(zhuǎn)換和填充數(shù)據(jù)倉庫時,數(shù)據(jù)映射的質(zhì)量是充分利用數(shù)據(jù)的關(guān)鍵。數(shù)據(jù)映射的步驟主要包括以下幾步:

步驟1定義。定義要移動的數(shù)據(jù),包括表、每個表中的字段以及字段移動后的格式。對于數(shù)據(jù)集成,還定義了數(shù)據(jù)傳輸?shù)念l率。

步驟2映射。將數(shù)據(jù)匹配源字段映射到目標(biāo)字段。

步驟3轉(zhuǎn)換。如果一個字段需要轉(zhuǎn)換,轉(zhuǎn)換公式或規(guī)則將被編碼。

步驟4測試。使用來自源的測試系統(tǒng)和樣本數(shù)據(jù),運行傳輸以查看它是如何工作的,并根據(jù)需要進行調(diào)整。

步驟5部署。一旦確定數(shù)據(jù)轉(zhuǎn)換正在按計劃工作,就安排一次遷移或集成活動。

步驟6維護和更新。對于正在進行的數(shù)據(jù)集成,數(shù)據(jù)映射是一個活的實體,當(dāng)添加新數(shù)據(jù)源、數(shù)據(jù)源更改或目標(biāo)更改時,它需要更新和更改。

數(shù)據(jù)映射規(guī)范是一種特殊類型的數(shù)據(jù)字典,它顯示了一個信息系統(tǒng)的數(shù)據(jù)如何映射到另一個信息系統(tǒng)的數(shù)據(jù)。創(chuàng)建數(shù)據(jù)映射規(guī)范可以幫助項目團隊避免許多潛在的問題,這些問題往往在開發(fā)后期或用戶驗收測試期間出現(xiàn),并且會影響項目進度。這些聽起來和項目遷移可能很相似,事實也的確如此。兩者之間的主要區(qū)別是,在數(shù)據(jù)遷移項目完成后,不再使用或維護原始源數(shù)據(jù),而在數(shù)據(jù)集成項目完成后,則維護兩個數(shù)據(jù)源。

傳統(tǒng)的數(shù)據(jù)字典,是對數(shù)據(jù)庫的數(shù)據(jù)模型中的數(shù)據(jù)對象和模型進行描述。數(shù)據(jù)字典的建立,需要開發(fā)人員根據(jù)數(shù)據(jù)庫設(shè)計需求人為制定。但本項目中涉及數(shù)據(jù)類型多、數(shù)據(jù)項龐大,各種結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)都大量存在,不同數(shù)據(jù)庫的模式不同,數(shù)據(jù)結(jié)構(gòu)也各有差異,所以需要一套自定義的數(shù)據(jù)字典,盡量匹配原有各種數(shù)據(jù)庫的各種對象字段模型。此外,跨行業(yè)數(shù)據(jù)種類繁多,響應(yīng)的數(shù)據(jù)管理模塊交差調(diào)用,混合管理,導(dǎo)致后續(xù)進入的數(shù)據(jù)難以快速結(jié)合已有數(shù)據(jù)的使用。

以上技術(shù)細(xì)節(jié)詳見數(shù)據(jù)快速映射流程圖,如圖3所示。

圖3 數(shù)據(jù)快速映射流程

本文采用次級域分類結(jié)合SVM方法,對不同數(shù)據(jù)庫表中的數(shù)據(jù)對象,進行多層次劃分,并加以映射到已有標(biāo)準(zhǔn)庫。對未能識別關(guān)鍵字段的數(shù)據(jù)對象,根據(jù)內(nèi)容的詞頻進行SVM分類,映射到對應(yīng)標(biāo)準(zhǔn)庫。最終仍未能識別的數(shù)據(jù)對象,根據(jù)自身類型,添加到數(shù)據(jù)字典中,建立對應(yīng)域及字段,實現(xiàn)數(shù)據(jù)映射融合的過程。通過自分類字典技術(shù),實現(xiàn)快速索引方法,使得開放接口的人員,可以將新數(shù)據(jù)快速插入數(shù)據(jù)庫,進行數(shù)據(jù)映射,并快速整合進入應(yīng)用方法中。

應(yīng)急災(zāi)備統(tǒng)籌救助系統(tǒng)采用Oracle集成云服務(wù)Integration Cloud Service[13-14],結(jié)合研發(fā)的快速映射技術(shù),對來自于物流、交通、水電氣、地震、火災(zāi)等多種數(shù)據(jù)進行匯總分析。實際情況中,因跨行業(yè)數(shù)據(jù)種類繁多,響應(yīng)的數(shù)據(jù)管理模塊交差調(diào)用,混合管理,導(dǎo)致后續(xù)進入的數(shù)據(jù)難以快速結(jié)合已有數(shù)據(jù)的使用。這里我們采用了自分類字典技術(shù),實現(xiàn)自己的一套快速索引方法,使得開放接口的人員,可以將新數(shù)據(jù)快速插入數(shù)據(jù)庫,進行數(shù)據(jù)映射,并快速整合進入應(yīng)用方法中。

(2) 數(shù)據(jù)壓縮技術(shù)。數(shù)據(jù)中存在大量文檔、圖片、表單等數(shù)據(jù),如果都以原始格式存儲,會占用巨大空間。這里采用文字提取、圖片壓縮、重復(fù)文件合并等方法,減少文件數(shù)量,節(jié)省存儲空間,并將常見文檔轉(zhuǎn)存成makrdown格式,方便進行文件比對和查詢。

(3) 快速擴展算法池。在救災(zāi)系統(tǒng)實際應(yīng)用時,面對海量的數(shù)據(jù)源,及實時的大數(shù)據(jù)流,需要快速對數(shù)據(jù)進行清洗、校對、標(biāo)準(zhǔn)化分析及特定算法分析。這時再從無到有編寫算法,或者每個算法都有加以驗證,每個數(shù)據(jù)都重新清洗后再進行計算的話,會對應(yīng)急響應(yīng)時間造成重大延誤。所以需要一套通用的底層算法庫進行業(yè)務(wù)支撐,同時提供標(biāo)準(zhǔn)的輸入輸出API接口,方便開發(fā)人員快速調(diào)取數(shù)據(jù)倉庫的各種數(shù)據(jù)。并支持?jǐn)?shù)據(jù)發(fā)布及算法發(fā)布,開發(fā)人員可隨時上傳自己算法的動態(tài)庫,并添加輸入輸出說明,供其他部門人員實時調(diào)用。同時最新完成的算法結(jié)果,也可以隨時保存,并作為下階段算法的輸入數(shù)據(jù)調(diào)用。

面對應(yīng)急情況,在數(shù)據(jù)已經(jīng)匯總的情況下,需要進行數(shù)據(jù)分析和預(yù)測,由于實際情況不同,不可能套用經(jīng)典公式萬事通,需要實時修正模型,調(diào)整因子,這時就需要給相應(yīng)行業(yè)專家,提供調(diào)用數(shù)據(jù)的公共接口,及編寫算法,進行內(nèi)部運輸預(yù)測的算法平臺,同時能夠快速嵌入用戶上傳算法,實現(xiàn)關(guān)于災(zāi)情的預(yù)測分析(如余震預(yù)測、疫情預(yù)測等)。

算法池底層以C++標(biāo)準(zhǔn)庫搭建,并以此為基礎(chǔ)封裝了各個不同類型的算法庫為底層算法庫,如以Boost C++程序庫、Eigen線性算術(shù)模板庫為基礎(chǔ)的core算法庫,以VXL矩陣運算庫為基礎(chǔ)的vxl算法庫,以O(shè)penCV計算機視覺庫為基礎(chǔ)的 ocv算法庫,以 PROJ4 地圖投影庫為基礎(chǔ)的proj算法庫,以VisCL為基礎(chǔ)的vcl算法庫,和以ceres-solver非線性優(yōu)化庫為基礎(chǔ)的cer算法庫。

在此之上設(shè)計的algorithm plugin manger模塊,可以將底層算法庫的統(tǒng)一輸入輸出接口封裝,用戶即可以方便快捷地開發(fā)自己的算法,為應(yīng)急事件的各種數(shù)學(xué)模型預(yù)測提供理論支撐。計算過程中,引入Pipeline技術(shù),使得各項數(shù)據(jù)從讀取、執(zhí)行、返回等各項業(yè)務(wù),分別獨立于并行的算法模塊,極大地提高計算運行效率。

比較典型實用的算法模型,如物資統(tǒng)籌,可以在不同倉庫庫存統(tǒng)計和消耗的情況下,根據(jù)受災(zāi)人數(shù)和物資需求,快速計算出每日物資消耗量、需求量,利用交通物流數(shù)據(jù)的支持,預(yù)測出附件調(diào)集物資的最短途徑,及遠(yuǎn)程采購輸送物資的交通規(guī)劃,及倉庫物資的合理分配存儲,結(jié)合運輸隊伍的實時命令,對救災(zāi)物資的未來使用規(guī)劃,進行數(shù)據(jù)預(yù)測,提早進入決策。

(4) 移動端快速收發(fā)。為了使每個基層工作人員,都能實時接收指揮,了解工作進度,需要對前方基層工作人員的手機或其他電子設(shè)備,提供信息發(fā)布窗口,發(fā)布每個指令實時上傳下達(dá),實現(xiàn)突發(fā)狀況迅速匯報,迅速響應(yīng)的應(yīng)急處理機制。

(5) 應(yīng)急情況快速判斷。在實際應(yīng)用中,因為每個基層人員都會持有終端,可以快速提交突發(fā)情況的匯報,為了使海量的匯報數(shù)據(jù),根據(jù)緊急情況,排序并分類發(fā)送給相關(guān)職能部門,需要提供對匯報的文字進行自然語言處理,通過語音識別、中文自動分詞、詞性標(biāo)注、文本分類、信息檢索、信息抽取、機器翻譯的各種方法,將簡單匯報中的關(guān)鍵信息,提取并標(biāo)識緊急程度,通知相關(guān)人員,使其在短時間內(nèi)快速處理。本系統(tǒng)采用命名實體識別法(NER)[15],模型采用Spacy NER模型。本文對一些常用地名、人名、重點動名詞進行模型的訓(xùn)練,通過訓(xùn)練數(shù)據(jù)的輸入,和數(shù)據(jù)標(biāo)簽的建立,完成成熟模型的建立,應(yīng)用于實際工作。數(shù)據(jù)建模流程如圖4所示,x1為時間分詞,通過模型a1處理得到概率為y1,x2為地點分詞,通過升級模型a1得到模型a2處理得到概率為y2,x3為事件分詞,通過升級模型a2得到模型a3處理得到概率為y3。

圖4 NER建模流程

如圖5所示,經(jīng)過模擬測試,以最近的新聞為測試數(shù)據(jù),識別其中的關(guān)鍵字為紅色區(qū)域,再分類提取出時間、地點、事件、緊急程度等信息。然后根據(jù)情況,判斷是否需要立刻推送應(yīng)急處置。

圖5 NER模型測試效果圖

(6) 救災(zāi)物資配送算法。傳統(tǒng)配送算法,不會考慮物資緊急程度,沒有在算法模型中的權(quán)重參數(shù),所以會選擇的最優(yōu)配送路線,會是以距離進行判斷,并且不會考慮完全相反的兩個方向(P2、P9)的優(yōu)化路線。面對物資不同,路線各異的情況,傳統(tǒng)方法最先會考慮的是分別配送,每個都滿載物資,實現(xiàn)運能最大化,同時選擇最近距離點優(yōu)先配送,滿足時間要求,所以以表中數(shù)據(jù)為例,P1出發(fā)的運輸車,最先會前往P4運送物資,然后才是P2、P3、P9。而遠(yuǎn)處的P5、P6、P8目的地,因為傳統(tǒng)方法沒有考慮中途補貨算法,所以必須排出兩個運力才能實現(xiàn)最優(yōu),即排出另外一個運輸車,從P7倉庫出發(fā),按距離遠(yuǎn)近,先后前往P6、P5、P8。這樣雖然保證了運輸量的滿載,但是未能保證時間上優(yōu)先考慮P5。同時因為使用了2個運力,這在平時的正常生活環(huán)境中不存在太多人力物力和時間的浪費,甚至和平時期可以每個地點排出10個運輸車同時運輸,但是面對救災(zāi)應(yīng)急的情況下,時間、運能、消耗的單位運力才是應(yīng)該著重考慮因素。

為了滿足受災(zāi)人群的生活醫(yī)療條件,配送重癥醫(yī)療物資、急救醫(yī)療物資、救援設(shè)備物資等,以最小成本實現(xiàn)效率最大化,本文以效率為優(yōu)先考核指標(biāo),按配送救災(zāi)物資量、運輸成本(路程及時間)、人力成本為參照指標(biāo),實現(xiàn)應(yīng)急配送算法。

該算法要素包括2個方面,首先優(yōu)先級條件為:區(qū)分物資需求的優(yōu)先級,如重癥病人需求藥品等,按優(yōu)先級安排運力人力;然后物資內(nèi)容主要是配送物資的重量,大小、形狀、包裝、材質(zhì)及運輸要求,具體如下:

① 接收人:計算并合適的接收人員,分配人工。

② 人力:運輸物資的人力資源,包括司機、裝卸工、特種操作人員等。

③ 車輛:運輸中調(diào)用的車輛,按大小、載重、容積、是否特種車輛等。

④ 倉庫庫存:不同倉庫的庫存量,根據(jù)需求,調(diào)入調(diào)出,庫存低于警戒線的時候需要提示補貨。

⑤ 燃料:統(tǒng)計車輛燃料及油耗,適時需要根據(jù)估計的燃料消耗,修改路線,前往最短路徑的加油站。

⑥ 路線:根據(jù)諸多影響條件,實現(xiàn)最短路徑規(guī)劃,實現(xiàn)車/人不空駛、燃料不空耗、運力最大化、路線最短的高效運力統(tǒng)籌。

本文按照救災(zāi)緊急程度優(yōu)先,然后結(jié)合節(jié)約里程法,提供最大運力,節(jié)省救災(zāi)時間。因此所有條件在優(yōu)先級一直情況下統(tǒng)計運力,應(yīng)該以優(yōu)先級不同的物資統(tǒng)籌裝車,然后按級別定制優(yōu)先配送物資,結(jié)合路徑規(guī)劃,實現(xiàn)運力最大化。根據(jù)以上分析,本文定義運力計算公式如式(1)所示。

(i= 0,1,…,n)

(1)

式中:I、II、III指不同優(yōu)先級的物資類別;V指同一優(yōu)先級內(nèi),運輸物資量(不同種類物資按體積、重量、數(shù)量無法分開統(tǒng)計,這里統(tǒng)一規(guī)劃為車輛占用運載量);T指運輸本物資耗費單位時間;D指運輸本物資耗費路程公里數(shù);S指本車運輸效率比,即單位時間內(nèi)運輸距離最短,運輸效率比最大。

本文中運輸配送地方有9個,分別為P1,P2,…,P9,這9個地點之間的距離由K1,K2,…,K9表示,這些地點之間距離長度如表1所示。

表1 運輸配送地點距離表 單位:km

按傳統(tǒng)方案,如圖6所示,將兩個不同倉庫中物資發(fā)送7個地區(qū),方向各不一致,需要兩輛運輸車,往返共計14次里程,其中空跑7次?？偫锍蘐otal1=(K1+K2+K3+K4)×2+(K5+K6+K7)×2=98.22km。

圖6 物資配送傳統(tǒng)方案圖

在本文算法中添加了權(quán)重因子,并假想緊急情況環(huán)境下的運力缺失,目的是在最少運力情況下實現(xiàn)救災(zāi)物資的快速到達(dá)。因此,只派出一輛車,通過中途循環(huán)補給的方法,使得完成任務(wù)的總里程減少,路上沒有空車空駛里程,盡量保證運輸車在運送物資。同時根據(jù)物資的權(quán)重,盡量實現(xiàn)了I級物資優(yōu)先運送,II、III級相對延續(xù)。這里同時要在物資優(yōu)先級、運輸物資量、運輸時間、運輸里程、最短路程中加以建模判斷,盡量滿足I級物資優(yōu)先,同時滿足要求的運輸量。這也是為什么示意圖中P1出發(fā)的運輸車先前往P2,但并未立即前往P5的原因,因為這樣意味著運往P5的物資可能因為與P2的物資占用同樣的運能,而產(chǎn)生不足,同時跳過了P3、P4在運送路線上造成了時間和路程的浪費。所以最優(yōu)路線經(jīng)計算后得出,完成P2后,經(jīng)過P3、P4,前往P7倉庫補充物資,再以滿載量前往P5,這樣就能滿載P5的物資需求,同時沒有浪費時間,多走路程,浪費運力。這樣就保證了在緊急情況下,系統(tǒng)調(diào)配了最少的人手,消耗盡量少的時間,走最短路程,向相關(guān)目標(biāo)運輸必須的物資數(shù)量,實現(xiàn)了應(yīng)急救災(zāi)的核心意義,即困境擇優(yōu),運力發(fā)揮最大化,具體算法流程如圖7所示。

圖7 物資配送優(yōu)化算法流程

優(yōu)化后的路線如圖8所示,一輛運輸車,歷經(jīng)10次運程即可實現(xiàn),總里程Total2=K1+K2+K3+K4+K5+K6+K7+K8+K9+K10=72.05km。通過實驗對比,顯然本文提出算法計算的總里程Total2比傳統(tǒng)算法計算總里程Total1縮小26.17 km,同時減少使用了一個運輸車,因此節(jié)約了運力,提高了運輸效率。

圖8 物資配送優(yōu)化路線圖

4 結(jié) 語

本文通過對應(yīng)急災(zāi)備情況的整體考慮,結(jié)合實際產(chǎn)生的問題,經(jīng)過仔細(xì)分析,進行了科學(xué)合理的架構(gòu)設(shè)計,以及關(guān)鍵技術(shù)的選用,從而構(gòu)建了基于前后端分離架構(gòu)的應(yīng)急災(zāi)備統(tǒng)籌救助系統(tǒng),實現(xiàn)多種災(zāi)情的應(yīng)急處置。系統(tǒng)具備良好的可擴展性,實現(xiàn)了信息共享、數(shù)據(jù)快速處理、算法精準(zhǔn)分析、管理功能扁平化、業(yè)務(wù)流程簡單化、監(jiān)督工作透明化的多種功能。在實際接口的算法中,通過自主研發(fā)的分級物資配送算法,實現(xiàn)了按優(yōu)先級配送,對比傳統(tǒng)的點對點運輸路線,新的方法符合最短路徑原則,通過新的優(yōu)化配送路徑算法,既保證了物資的及時送達(dá),又最大程度上提高了運輸效率,節(jié)省了配送時間。同時通過NER算法模型的匹配,實現(xiàn)了基層匯報數(shù)據(jù)的自然語言文字提取,并根據(jù)模型的訓(xùn)練標(biāo)簽,迅速提取關(guān)鍵字,識別出文字的重點內(nèi)容,判斷緊急程度,實現(xiàn)基層與高層的文本匯報快速響應(yīng)機制。