地震預警信息快速發布系統研究1

蔡 寅 張 明 趙 瑞 尹玉振 李 紅

1）中國地震局地球物理研究所，北京 100081

2）山東省地震局，濟南 250014

引言

現今，地震預報仍沒有實現重大突破，地震預警系統（Earthquake Early Warning System，EEWS）是世界上公認的能夠有效減輕地震災害的新技術手段之一（Xu等，2017；Festa等，2018）。地震預警信息發布系統需要在破壞性地震波到達前，以最小的延遲，通過最便捷的方式，告知用戶最精準的地震信息，達到緊急避險和決策應對的目的（Gasparini等，2014；Cauzzi等，2016）。作為服務于民生的“最后一公里”，預警信息的快速發布是整個地震預警系統在社會服務中的重要體現（蔡寅等，2016）。

自2004年開始，在全國范圍內運行的地震速報信息共享服務系統（Earthquake Instant Messenger，EQIM）實現了省級臺網與國家臺網之間地震速報信息的交換與共享，并以短信的方式快速發布（楊陳等，2009）。地震預警系統僅能提供數秒或數十秒的預警時間，若以短信方式發送預警信息，一方面短信的固有延遲性已經不能滿足公眾對信息時效性的需求，另一方面所有短信用戶接收到的信息是完全一致的。然而，由于用戶所在區域場地的差異以及距離震中遠近的不同，致使所受到地震的破壞程度也有所差異，地震預警系統對于不同位置的用戶所推送的預警信息也不盡相同。因此，需要考慮其它方式實現地震預警信息的快速發布。

近年來，隨著互聯網技術的發展，尤其是移動互聯網的普及，基于地理位置的信息服務（Location Based Services，LBS）逐漸成為1種新興的增值業務形式，為用戶提供與所在位置有關的服務（劉成，2013；Vanjire等，2014）。面向公眾的地震預警恰恰與用戶所在的位置信息有極大的關系，如果有效地結合LBS與GIS（Geographic Information System，地理信息系統）2種技術，融合地理信息數據與用戶位置信息，將能夠為用戶提供網絡化與個性化的地震預警信息服務（趙慶展等，2015）。

本文針對移動互聯網用戶與桌面用戶，通過分析對比，選擇MQTT協議與JSON技術作為服務端與客戶端的數據交互方式，提出1種支持海量并發式的地震預警信息推送架構，設計并實現了一體化地震預警信息發布系統。經綜合測試，系統能夠為各類互聯網用戶提供基于位置的地震預警信息服務，在破壞性地震波到達前，為公眾緊急避險爭取了最大限度的自救時間。

1 系統總體架構

地震預警信息發布系統由服務端與客戶端2部分組成。服務端完成地震預警信息的實時推送，客戶端獲取預警信息后進行前端展現報警?？蛻舳酥饕嫦蛞苿踊ヂ摼W用戶與桌面用戶設計開發，因而又細分為移動端與桌面端，分別選用Android與WebGIS平臺作為開發環境。從整體架構角度分析，系統為C/S（Client/Server，客戶端/服務器架構）與B/S（Browser/Server，瀏覽器/服務器架構）的混合架構。系統借鑒了經典的三層架構設計模式，增加了服務層，實現邏輯層多類用戶預警參數計算與數據層多種數據源間的服務封裝與數據交互，目的是將數據資源與分析展現的完全解耦，為今后接入不同的終端設備或平臺用戶提供可擴展的服務接口（Mantas等，2015）。系統邏輯架構如圖1所示。

圖1 地震預警信息發布系統邏輯架構 Fig.1 The logical architecture of earthquake early warning information rapid release system

數據層由內部數據庫與外部數據源組成。其中，內部數據庫以用戶信息數據庫為主體，通過多種定位方式（GPS、Wi-Fi、移動通信網絡）獲取用戶位置信息，將其與用戶的基礎數據、所在位置的場地響應數據及地理信息數據（離線數據）進行關聯，提供給上層進行預警參數計算及信息展示；外部數據源主要由提供發震時刻、震中位置、極震區烈度等信息的震源參數數據庫和提供實時地理信息的在線式地圖數據組成。

服務層負責完成數據層與邏輯層之間的數據交互，通過封裝標準Web Service接口服務，自動適配各類數據源，實時獲取數據層資源，將震源參數及用戶信息以多線程的方式發送給邏輯層。對用戶的反饋數據或更新的定制信息，服務層將其保存至數據層的用戶信息數據庫，作為系統日志進行管理。針對混合型邏輯架構，融合2種交互技術，實現多類終端海量用戶的高并發信息服務。

邏輯層以預警信息消息傳遞模塊為核心，面向各類終端用戶的服務請求，支持海量用戶的并發接入操作，通過服務層將每一報的震源參數向下保存至數據層的用戶信息數據庫。同時，將震源參數以服務的方式提供給基于位置的預警參數計算模塊。計算模塊結合用戶所在的地理位置和場地響應因子，快速估算每個在線用戶的地震預警信息，向展現層提供需要推送的預警信息。此外，邏輯層負責與服務層建立持久化連接，確保預警信息推送的高可用性。

展現層分別面向Android和Web平臺用戶，實現基于GIS和LBS的地震預警信息的可視化展現，在客戶端以地震波動態擴散、聲音振動報警以及倒計時提醒等多種方式提示用戶緊急避險。雖然兩大平臺實現預警信息發布的技術不盡相同，但兩者在信息展現的方式和用戶體驗的效果上仍保持一致。

2 數據交互方式

一般情況下，地震預警系統僅能為公眾提供幾十秒甚至幾秒的避險時間，每提前1s接收到地震預警信息，都將有效減少更多的人員傷亡與經濟損失。這就意味著預警信息發布對系統響應時間有較高的需求，需要考慮信息從服務端至客戶端傳輸的各個環節中降低時間延時，因此，選擇1種高效的數據交互機制至關重要。

2.1 與Android端數據交互

目前，基于Android移動平臺的主流信息推送方案有3種：C2DM（Cloud to Device Messaging，云端推送）、MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸協議）及XMPP（Extensible Messaging and Presence Protocol，可擴展通訊和表示協議）。其中，C2MD是谷歌公司為應用開發者提供的1項服務，實現從服務器向Android應用程序發送數據，但信息發送過程需要綁定谷歌賬號，在國內使用具有一定局限性；XMPP協議技術成熟，標準化程度高，功能強大，具有較強的可擴展性，但其缺點是數據負載過重，導致終端流量及電量消耗過高（關慶余等，2014）；MQTT協議1種輕量級的基于代理的發布、訂閱消息傳輸協議，目前已成為物聯網傳輸標準協議之一，由于其低功耗、數據包較小（固定報頭僅為2字節）、分布式等特點，MQTT成為實現移動應用的理想選擇，因此，也是地震預警信息推送的首選解決方案（許金喜等，2015）。

實現MQTT消息代理的開源項目較多，但在實際應用中表現各異。本文從CUP占用率及數據傳輸延時的角度，對比測試了目前主流代理服務器在支持不同用戶數量方面的表現。參與測試的代理服務器包括Apollo 1.7、ActiveMQ 5.10.0、Mosquitto 1.3.5及RabbitMQ 3.4.2。在相同的硬件環境下（CPU：E8400 3.00GHz，內存：4GB），各代理服務器CPU占用率及數據傳輸延時的結果如圖2、3所示，ActiveMQ因無法支持2000個以上的用戶同時并發信息，其測試結果在圖中并未標出。

圖2 MQTT服務器CPU占用率測試結果 Fig.2 Test result for the CPU occupancy of MQTT servers

圖3 MQTT服務器響應延時測試結果 Fig.3 Test result for response latency of MQTT servers

測試結果表明，Mosquitto在資源占用率、數據傳輸延時及并發用戶支持數量等方面的表現均為最優。RabbitMQ并發能力極大地依賴于CPU性能，當每秒并發數超過8000時，CUP占用率超過70%，出現內存溢出現象；當Apollo每秒并發操作超過1萬個時，系統延時快速增長，超過2萬后，系統延時超過1s，不能滿足業務需求；盡管CPU占用率較高，但Mosquitto仍然能夠支持6萬個用戶的并發操作，數據延時也小于1s，但超過6萬用戶時，會出現內存溢出，其可能的原因是Mosquitto自身單線程的處理方式，6萬用戶為處理上限，這也解釋了雙核CPU使用率始終處于50%水平的現象。

2.2 與Web端數據交互

盡管XML（Extensible Markup Language，擴展標記語言）早已成為業界公認的Web數據交換的標準格式，但服務端和客戶端都需要占用大量資源，消耗大量時間來解析XML文件，導致整體效率較低。與XML不同，JSON（JavaScript Object Notation，JavaScript對象表示法）作為1種輕量級的數據交換格式，更加簡單和靈活，對元素的定義也更加精練，占用更小的空間資源，易于機器的解析和生成。并且，JSON是與編程語言無關的普通文本文件，不需要編譯和執行，這些特性使JSON成為地震預警信息發布Web端的首選數據交換格式（韓敏等，2010）。以1條預定義的預警信息的為例，JSON所用的字節數明顯小于XML格式，代碼對比見表1。

表1 XML與JSON格式預警信息代碼對比 Table1 Code format of early warning information between XML and JSON

相對XML，1條JSON格式的預警信息即減少了75字節的數據量，當用戶量和數據量增大后，其優勢更加突出。在元素規模較大的情況下，JSON傳輸所消耗的時間遠遠小于XML；隨著測試預警信息元素數量的逐漸增加，JSON的傳輸速率沒有明顯變化，而XML出現線性增長的趨勢，如圖4所示。此外，客戶端需要對服務器端傳來的數據進行反序列化才能獲取有效的數據。XML自身基于文檔對象模型（Document Object Mode，DOM）樹結構，進行反序列化時需要考慮父節點和子節點的相應解析，這為反序列化過程增加了難度（于京等，2012）；而基于JavaScript腳本語言的JSON，自身語法非常簡潔，屏蔽了DOM解析的復雜度，大大降低了反序列化時的冗余度，反序列化時間也明顯小于XML，如圖5所示。因此，采用JSON作為數據交換格式，可以最大限度地降低通訊延遲，有利于提高系統的響應速度，保證預警信息的時效性。

圖4 不同元素數量的傳輸延時測試結果 Fig.4 Test result for response latency between XML and JSON

圖5 反序列化耗時測試結果 Fig.5 Test result for time consuming of anti-serialization between XML and JSON

3 核心邏輯設計

3.1 服務端設計

地震預警信息服務端軟件從震源參數數據庫獲取參數信息（發震時刻、震中位置、震級、震中區烈度），根據不同接收終端的信息傳輸協議，將參數信息推送至各類客戶端接收軟件。當服務端獲取來自不同數據源的地震預警信息后，首先進行數據解析，對需要發布的信息進行編碼轉換，形成標準化的預警信息；其次，根據不同客戶端的數據交互方式，按照MQTT協議及JSON數據格式封裝為地震預警信息包，分別并發推送至移動端與Web端。推送完成后，監聽客戶端的反饋信息，判斷信息是否推送成功，如推送成功，則創建預警信息服務日志，否則重新推送，直至獲得正確的反饋信息。地震預警信息發布服務端的邏輯流程如圖6所示。

3.2 客戶端設計

地震預警信息客戶端軟件在接收到預警信息后，對數據進行解析計算，形成向用戶展現的圖形要素，在前端進行可視化展現。當客戶端啟動應用服務后，首先向服務端發送服務請求，訂閱預警信息包，通過定時發送心跳包與服務端保持長連接；同時，獲取客戶端位置信息，根據定位精度的不同，定位方式優先級依次為GPS定位、Wi-Fi定位和移動網絡定位。當客戶端接收到服務端推送的地震預警信息后，將結合客戶端此時的位置信息，分別按公式（1）—（3）計算震中距D、用戶所在位置烈度I和對P波、S波的預警時間TP、TS，以逐秒動態的方式在前端進行展現，并通過聲音或震動方式進行報警，同時向服務端發送響應包，完成1次預警信息發布的完整過程。地震預警信息發布客戶端的邏輯流程如圖7所示。

圖6 地震預警信息發布服務端邏輯流程 Fig.6 The logical flow chart of server-side

其中，D為震中距（km）；（α1，β1）為用戶所在位置的經緯度坐標；（α2，β2）為震中位置的經緯度坐標；R為地球半徑，設定為6371km。

其中，I0為震中烈度。

其中，VP、VS分別為P波、S波的傳播速度（km/s）；Tnow為當前時間；Teq為發震時間。

圖7 地震預警信息發布客戶端邏輯流程 Fig.7 The logical flow chart of client-side

4 系統實現與測試

根據上述系統總體架構及核心邏輯設計，開發實現了地震預警信息發布系統。根據各子系統部署所在物理位置及用戶類別的角度，從服務端、客戶端及綜合管理3方面進行功能劃分。服務端子系統與綜合管理子系統分別包含5個子模塊，客戶端子系統功能模塊較多，共包含25個功能模塊。系統功能模塊樹狀圖見圖8。

圖8 地震預警信息發布系統功能模塊樹 Fig.8 The function tree component of the earthquake early warning information rapid release system

為檢驗軟件系統是否符合預期目標，在對系統的功能模塊及兼容性測試后，重點對軟件的實時性及可靠性進行測試，確定系統運行時服務端與客戶端的性能表現。測試方式是在虛擬機的環境下，部署服務端軟件，模擬每30s向客戶端推送預警信息，并發用戶量為2萬以內的隨機數，連續推送24小時，通過響應時間（從服務端發送預警信息到客戶端收到預警信息并展現所需的時間）與信息接收率2方面測試系統的整體性能。針對Android客戶端軟件，增加了耗電量的測試。

4.1 Web端

Web端地震預警信息發布軟件整體采用RIA（Rich Internet Application，富客戶端應用）模式，通過Java語言完成JSON數據包的反序列化處理，對解析后的數據，采用HTML5語言實現WebGIS功能與地震預警信息的疊加展現。富客戶端應用模式不僅降低了系統部署的復雜度和服務端的計算壓力，提高了系統整體響應速度，同時也實現了無刷新的動態展現的預警信息，給用戶帶來更好的操作體驗。

Web端預警信息發布軟件能夠對震源信息進行滾動發布，標注用戶位置（Wi-Fi網絡定位）與震中位置，計算地震預警信息，通過動態的形式展現P、S波擴散過程，并以倒計時方式配合聲音報警提示用戶預警時間，如圖9所示。通過24小時連續測試，客戶端在Wi-Fi網絡環境下的平均響應時間為460ms。由于網絡狀態相對穩定，測試結果未出現丟包或二次推送的情況，客戶端能夠100%接收到預警信息。

圖9 WebGIS端預警信息發布效果 Fig.9 Actual effect map of the early warning information release in WebGIS

4.2 Android端

Android端地震預警信息發布軟件基于Android操作系統原生開發，采用ViewStub動態布局顯示技術完成用戶界面設計，有效減少了對資源的占用，降低了信息接收的延遲。通過調用高德開放平臺的地圖數據，構建地理信息數據資源，完成預警信息、位置信息及地理信息的疊加渲染。用戶可根據需求定制預警服務內容，設置交互模式及信息接收方式，滿足各種場景下對地震預警信息的需求。

在接收到預警信息后，移動端預警信息發布軟件首先以振動及聲音報警的形式提醒用戶查看信息，同時自動彈出地震預警基本信息頁面，如圖10（a）所示。用戶可以點擊查看地震波擴散的動態過程，如圖10（b）所示。為統一客戶端軟件的風格，在顯示內容與展現形式上與Web端基本一致。

為充分反映不同網絡環境下的系統響應時間，分別選擇Wi-Fi和4G無線網絡環境進行24小時連續測試。在Wi-Fi網絡環境下，系統的平均響應時間為318ms，客戶端能100%接收到預警信息；在4G網絡環境下，由于網絡波動較大，系統的平均響應時間為705ms，查詢系統日志記錄發現有1.7%的預警信息通過二次推送完成，一定程度上增加了系統的響應時間。

圖10 移動端預警信息發布效果 Fig.10 Actual effect map of the early warning information release in Android

最后，采用AccuBattery軟件，測試Android端軟件的耗電量。在空載狀態下，即Android客戶端程序在后臺運行，定時發送心跳包保持與服務端的長連接，選取發送時間間隔為5分鐘，經24小時連續測試，消耗電量為24.08mAh。按照一般手機電池容量為3000mAh計算，Android端軟件每天的電量消耗占比小于1%，幾乎可以忽略不計。

5 結論

本文基于互聯網技術，面向移動端及桌面端用戶，提出了地震預警信息發布系統總體架構設計方案。通過對比分析，選定MQTT協議及JSON格式作為服務端與客戶端數據交互方式。根據業務需求，結合GIS及LBS技術，設計并實現了核心邏輯流程與系統功能模塊。最后，通過綜合測試，驗證了該系統在實時性、可靠性等方面的優勢。

該地震預警信息發布系統具有如下特點：①兼容性，預警參數計算與各類數據源之間完全解耦，通過協議自動適配，支持多類預警數據源的接入；②靈活性，系統基于服務組件架構模型開發，各類用戶可根據需求最大化的配置、定制系統服務；③可靠性，利用專有信息傳送機制，有效降低了系統總體延時，確保預警信息發布的時效性和可靠性。面向大規模互聯網用戶應用時，有較高實時性要求的混合架構應用系統，具有一定的實際應用價值和參考借鑒意義。

當發生較大地震時，震源區的通訊設施可能被損毀，震源區用戶將無法接收到地震預警信息，因此，系統仍有改進的空間。在接下來的工作中，將增加C/S架構下桌面端信息接收軟件，通過在客戶端離線緩存地理信息數據，降低系統對互聯網數據的依賴，提升系統的實時性。同時，進一步優化系統架構，增加廣播、衛星等通訊方式，確保在互聯網中斷的極端情況下，仍能快速發布預警信息，增強系統的魯棒性。

致謝：感謝審稿專家對本文提出的修改建議，使系統的架構設計趨于合理，文章的邏輯性更加嚴密。