基于多維大數據預測的應急災備統籌救助系統研究

李 攀 周兆軍 劉慶杰

1(防災科技學院信息工程學院 河北 三河 065201) 2(防災科技學院繼續教育學院 河北 三河 065201)

0 引 言

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

1 業務需求

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

圖1 應急災備統籌管理流程

1.1 數據獲取集成問題

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

1.2 數據流實時傳輸分析問題

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

由于傳統的云計算模式需要將涉密數據上傳至云計算中心,為數據傳輸帶來很大的風險。因此,在邊緣計算中,本項目采用身份認證協議,加強統一認證、跨域認證和切換認證技術的研究,以保障用戶在不同信任域和異構網絡環境下的數據和隱私安全。

1.3 多元化多應用支持

因為面對的業務有些彼此獨立,但是更多的數據模型相互交叉,算法又互相關聯,所以面臨的問題是多種應用服務開發,及對應的UI快速開發,傳統架構已經完全無法滿足,更加無法跟上后續的追加需求,以及擴展應用的快速部署。本文使用SpringCloud后臺架構[9-11],結合Vue.js的前后端分離架構,使得開發更快速高效。

1.4 算法模型支持

系統面對的多元化問題,需要對應各種應急疏散算法、物資統籌算法進行算法結合,這里需要考慮算法的快速實現,以及處理結果的實時反饋,需要開發對應的算法進行封裝,提供這些算法嵌入接口,為各行業專家、調用數據、整合調試模型,提供完善的數據平臺,及展示層接口。

2 系統設計與實現

2.1 系統架構

應急災備統籌救助系統,是基于前后端分離的多層次開發架構,后端采用分布式微服務架構SpringCloud,前端采用Vue.js開發框架,實現前后端分離開發,便于快速擴展及系統維護,系統架構圖如圖2所示。

圖2 系統架構圖

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

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

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

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

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

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

2.2 系統功能

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

在主管理模塊中,快速獲取當前的基本信息。對當前城鎮區域的受災情況、醫療物資、生活物資,及上下級反饋信息數量,得到全面了解。

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

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

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

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

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

(6) 水電氣管理。根據地區的水電氣情況,匯總統計災情中受損情況、泄漏情況及高危地區信息,使得決策層能通過多圖層GIS,調配人員和物資、避難場所,使得人、物、地與高危地區的遠離。

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

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

3 系統方案

3.1 數據模型

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

3.2 關鍵技術

在設計開發過程中特別采用了一系列技術創新手段,為系統的開發及使用提供了有力的支持:

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

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

① 分析人員和架構師的透明性。由于數據質量對于分析結果的準確性起到核心作用,所以數據分析師和架構師需要對數據的來源和目的地有一個精確的、實時的視圖。數據映射工具提供了對被映射的數據結構的公共視圖,以便分析人員和架構師都能看到數據內容、流和轉換。

② 復雜格式優化。由于來自不同數據源的大量數據流,數據兼容性成為一個潛在的問題。好的數據映射工具通過提供內置的工具來簡化轉換過程,以確保復雜格式的準確轉換,從而節省了時間并減少了人為錯誤的可能性。

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

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

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

步驟2映射。將數據匹配源字段映射到目標字段。

步驟3轉換。如果一個字段需要轉換,轉換公式或規則將被編碼。

步驟4測試。使用來自源的測試系統和樣本數據,運行傳輸以查看它是如何工作的,并根據需要進行調整。

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

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

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

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

以上技術細節詳見數據快速映射流程圖,如圖3所示。

圖3 數據快速映射流程

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

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

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

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

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

算法池底層以C++標準庫搭建,并以此為基礎封裝了各個不同類型的算法庫為底層算法庫,如以Boost C++程序庫、Eigen線性算術模板庫為基礎的core算法庫,以VXL矩陣運算庫為基礎的vxl算法庫,以OpenCV計算機視覺庫為基礎的 ocv算法庫,以 PROJ4 地圖投影庫為基礎的proj算法庫,以VisCL為基礎的vcl算法庫,和以ceres-solver非線性優化庫為基礎的cer算法庫。

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

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

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

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

圖4 NER建模流程

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

圖5 NER模型測試效果圖

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

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

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

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

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

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

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

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

⑥ 路線:根據諸多影響條件,實現最短路徑規劃,實現車/人不空駛、燃料不空耗、運力最大化、路線最短的高效運力統籌。

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

(i= 0,1,…,n)

(1)

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

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

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

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

圖6 物資配送傳統方案圖

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

圖7 物資配送優化算法流程

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

圖8 物資配送優化路線圖

4 結 語

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