地震预警信息快速发布系统研究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部分组成。服务端完成地震预警信息的实时推送，客户端获取预警信息后进行前端展现报警。客户端主要面向移动互联网用户与桌面用户设计开发，因而又细分为移动端与桌面端，分别选用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架构下桌面端信息接收软件，通过在客户端离线缓存地理信息数据，降低系统对互联网数据的依赖，提升系统的实时性。同时，进一步优化系统架构，增加广播、卫星等通讯方式，确保在互联网中断的极端情况下，仍能快速发布预警信息，增强系统的鲁棒性。

致谢：感谢审稿专家对本文提出的修改建议，使系统的架构设计趋于合理，文章的逻辑性更加严密。