引言

我国是全球地震灾害最严重的国家之一，破坏性地震造成的人员伤亡、财产损失以及各种次生灾害令人触目惊心。从汶川地震、玉树地震和芦山地震等数次大地震的应急救援实践可知，震后迅速获取灾情信息，对于提高灾情研判、指挥决策和应急救援的效率具有重大意义。

地震发生后，震区社会公众直面灾情，能够迅速获取一手灾情信息，但专业知识的欠缺和震后情绪的波动，很大程度上影响了公众提供灾情信息的准确性。地震工作者虽有专业的地震知识，但需要坚守岗位，在提供灾情信息的时效性上不尽如人意，而现场工作队可能数小时之后才能赶赴震区开展灾情采集工作。由此可见，协调灾情信息上报的时效性与准确性尤为重要。基于上述考虑，我们设计了基于12322平台的江苏省地震应急灾情速报系统（以下简称“基于12322的灾情速报系统”）。

1.   需求分析

地震发生后，政府及地震部门需要在第一时间了解地震影响的大致范围以及大概的伤亡情况等信息，我们称之为“地震应急灾情”。相较于民政部门后期开展震后紧急救助、灾民安置和恢复重建等需要详细准确的灾情信息，地震应急灾情最重要的特点是时效性，具体伤亡人数等信息的准确性则是其次的。越早掌握地震应急灾情，地震部门越能更早地为政府的应急救援工作提供有价值的对策建议。

2007年，12322特服号码被工信部批准作为防震减灾公益号码使用。“12322热线”成为地震部门面向社会提供防震减灾公益服务的窗口，采用人工与语音结合的方式提供防震减灾咨询服务，在发布地震震情、应急公告以及接收地震灾区群众灾情报告等工作中获得良好的效果。此后，许多学者基于“互联网+12322特服号码”开展了研究，帅向华等（2009）基于“12322”特服号码建立了防震减灾公益服务短信技术平台，该平台不仅可以获取上报的灾情信息，同时还可向普通民众普及地震知识、发布震情信息、辟除谣言等；刘钦等（2015）设计了基于移动终端的12322地震灾情上报处理系统，该系统能够基于百度地图获取带有地理位置信息的灾情，通过Android App和网页展示2种方式，自动生成12322灾情上报短信及灾情反馈微博。

为了震后迅速掌握地震应急灾情，给灾情研判工作提供初步的依据，我们迫切需要一套简单、实用、易操作、易推广的灾情收集软件，能够迅速进行灾情邀请短信的发送、接收、数据处理和基本影响范围展示。

2.   软件设计

2.1   设计目的

考虑江苏省可能面临中强地震的情况，结合对江苏及周边地区历史地震的分析总结，系统采用手机短信和微信上报2种公共通信方式。在江苏及周边地区发生地震后，通过各地灾情速报员上报的短信消息快速获取地震灾情信息，迅速掌握灾区大致范围；通过各地地震工作者微信上报较为专业具体的灾情信息，掌握更加准确、详细的灾害情况，为地震应急救援工作提供依据。

2.2   模块划分

系统设计了短信版和微信版2大模块。

短信模块主要面向非地震系统人员，通过手机短信形式向社会灾情速报员发送灾情邀请短信，灾情速报员只需简单回复灾情代码即可。本系统沿用帅向华等提出的1—4级灾情代码，分别代表：“1”无震感或震感轻，“2”有震感无破坏，“3”有破坏无伤亡，“4”破坏重有伤亡。灾情代码简单、易懂、易掌握。短信手段能够保证信息收集的广泛性和信息获取的时效性。

微信模块主要面向地震系统工作人员，通过微信企业号推送地震信息及完成灾情收集工作。微信上报功能支持自动定位，且支持文字、图像、视频、语音等多媒体信息反馈，能够为应急决策收集更加详尽的灾情资料。

2.3   工作流程

系统工作流程如图 1所示。地震发生后，由省级用户触发地震事件，短信模块和微信模块可同时工作，针对不同用户收发灾情信息。收集的灾情信息经过进一步数据处理，成为符合规范的地震应急灾情，并在地图上进行展示。

图 1  系统工作流程

Figure 1.  System workflow

下载: 全尺寸图片 幻灯片

2.4   管理模式

系统采取“共同使用、共同维护”的原则，面向省、市、县3级用户开放。省级用户作为最高级别管理员，管理市级用户和所有微信版灾情速报员信息，具有修改短信手机号段及创建地震事件等管理功能；市级用户管理下属区县级用户信息，在行政区划有所变动时，及时对区县用户进行更新；区县级用户主要负责本区县内所有灾情速报员的录入、更新及维护。

为规范管理、保证信息安全，各级用户只能向本级行政辖区内的灾情速报员发送灾情邀请短信，即省级用户可对全省所有灾情速报员发送灾情邀请短信，市级用户只能对本市下属区县灾情速报员发送灾情邀请短信，区县级用户只能对本区县灾情速报员发送灾情邀请短信。与此同时，3级用户可以查看全省所有灾情速报员上报的灾情信息。

2.5   技术手段

系统基于已有的12322短信号码资源，使用江苏省地震局专用扩展号码123220032作为统一短信收发号码，采用WebService封装灾情短信接口，以及三大运营商的短信通讯接口协议，通过消息中间件进行数据传输，信息服务传递模型如图 2所示。

图 2  短信息传递示意图

Figure 2.  Message transmission diagram

下载: 全尺寸图片 幻灯片

地震邀请短信发送与接收、灾情信息展示与发布等功能采用J2EE技术、基于SSH2框架进行开发，使用JDBC访问系统平台内部的Oracle数据库。同时，信息自动推送技术基于B/S架构进行研发，为信息的高效服务提供保证。

本系统部署在H3C UIS8000刀箱服务器中，使用H3C FlexServer B590刀片，采用H3C CAS云计算平台进行管理。利用刀片服务器易扩展、易恢复的特性，最大程度地保证了系统运行的稳定性。系统同时支持内外网访问，方便各类网络环境用户的需求。

2.6   设计特色

（1）系统根据手机号码所属运营商（移动、联通、电信）分别从不同的接口收、发短信，保证了信息传输的畅通。

（2）短信模块中设置灾情速报员地理位置预录入功能。在录入灾情速报员信息时，需要同时在地图上标注灾情速报员的常驻位置，定位后系统自动转换为经纬度坐标存入数据库。地震发生后，灾情速报员无需回复所在地点，可直接通过手机短信上报1—4级灾情代码。如灾情速报员出差或休假，其所在位置与预录入位置相差较远，则回复灾情信息时只需增加所在区县名和街道名即可，系统会通过地名库匹配的方式进行自动定位。

（3）设置省、市、县3级用户管理模式。3级用户分工明确，各司其职，相互配合，各自独立。省级用户主要负责技术系统的维护和管理工作的推动，市、县级用户负责灾情速报员信息的维护及管理工作的执行。

3.   功能实现

面向省、市、县3级用户，系统设计了灾情邀请短信发送、回复信息处理、信息数量统计、短信/微信地震应急灾情简报生成和地图展示等功能模块。

3.1   灾情邀请短信发送

省级用户建立地震事件后，省市县3级用户均可向本级行政辖区内的灾情速报员发送灾情邀请短信。以图 3南京市用户登入界面为例，南京市用户可在列表中勾选本市所有灾情速报员进行信息发送，但没有权限向其它地市的灾情速报员发送信息。

图 3  灾情邀请短信发送界面（以南京市为例）

Figure 3.  Message sending interface (Nanjing as an example)

下载: 全尺寸图片 幻灯片

3.2   上报信息处理

灾情速报员上报信息后，系统将利用信息识别、信息过滤、关键词索引等技术自动对反馈信息进行甄别、分析和分组。上报成功的信息可在地图上直接展示，不符合规范或是包含不能识别地名的信息将被单独列出，以便后续对灾情速报员开展二次培训。上报信息处理界面见图 4。

图 4  上报信息处理界面

Figure 4.  Information processing interface of reported messages

下载: 全尺寸图片 幻灯片

3.3   上报人员短信数统计

系统可按地震事件、运营商或起止时间对回复短信进行统计，并利用柱状图直观地显示江苏省13个地市或某地市管辖区县回复率的对比情况。在“短信详情统计”模块中可查看回复列表，包含姓名、手机号码、归属地及回复数等详细信息，并可转为excel格式导出（图 5）。

图 5  上报人员短信数统计界面

Figure 5.  Statistical interface of reported messages

下载: 全尺寸图片 幻灯片

3.4   地震应急灾情短信报告

系统根据每个地震事件收集的地震灾情信息，自动生成实时灾情报告，内容包括地震三要素、发送邀请短信数、上报有效灾情信息数量、各级别灾情短信数目统计等（图 6）。生成的灾情报告可导出为word格式文件，用于实际地震应急工作中的信息上报。

图 6  地震应急灾情短信报告界面

Figure 6.  Interface of earthquake-emergency-disaster message report

下载: 全尺寸图片 幻灯片

3.5   上报信息展示

以“天地图”作为地理底图，系统将所有回复信息定位在地图上，点击上报信息点可查看上报人员姓名、手机号、上报内容等详情，方便对异常点信息进行核实，还可根据上报灾情的点位信息手动绘制不同影响等级的范围圈。

3.6   微信模块

地震事件建立的同时，微信企业号“苏震12322”模块会自动启动，向所有关注用户推送地震信息及震区背景资料。地震系统工作人员作为微信版灾情速报员，通过微信中的“灾情上报”功能向系统反馈灾情信息，本模块支持文字、图片、视频及语音方式上报灾情信息（图 7）。

图 7  微信公众号界面

Figure 7.  Interface of official WeChat account

下载: 全尺寸图片 幻灯片

4.   应用效果及改进

基于12322的灾情速报系统自建成以来，多次在真实地震及应急演练中收集灾情，如2017年4月12日浙江杭州临安4.2级地震、6月9日盐城射阳3.2级地震、6月27日华东片区地震应急演练以及9月6日盐城东台3.0级地震应急工作，均取得了较为理想的效果。

以6月9日盐城射阳3.2级地震为例，当晚22时04分技术人员收到江苏省地震台网测定的正式结果后，迅速启用12322灾情速报系统进行灾情收集工作，于22时04分58秒创建地震事件，22时06分向全省灾情速报员发送灾情邀请短信，10分钟内收到60条有效上报灾情信息，对应急工作的开展起到积极的辅助作用。

此次射阳3.2级地震，共收到608条上报灾情信息，其中有效上报信息334条，1类灾情信息332条，2类灾情信息2条，经过电话核实，确认了此次地震无破坏情况，灾情速报员有较强震感。灾情收集结果如图 8、9所示，出于对灾情速报员的隐私保护，姓名和联系方式做了模糊处理。

图 8  灾情速报员成功上报的地震灾情

Figure 8.  An example of successfully reported earthquake disaster information from reporter

下载: 全尺寸图片 幻灯片

图 9  利用基于12322的灾情速报系统收集的地震应急灾情

Figure 9.  The damage information collected by the disaster reporting system based on 12322

下载: 全尺寸图片 幻灯片

在总结此次地震应急工作时，我们发现了本系统存在的一些问题：

（1）灾情速报员人数分布不均，如连云港市录入了1200多名灾情速报员。

（2）系统架构不稳定，当一次性收发短信数过多时，容易造成拥塞，从而出现漏发漏收现象。

（3）灾情速报员回复不积极且正确率低，有些灾情速报员认为是日常演练，随意回复灾情，在电话沟通后才重新回复真实灾情。

（4）上报灾情信息中有效信息只占55%，说明还有相当一部分灾情速报员不了解如何正确上报灾情信息，总结一些常见的错误上报信息见表 1。

表 1  常见错误分析

Table 1.  Common error analysis

上报失败信息示例	错误分析
江苏·连云港·东海县·山左口乡·北古寨村：1	未按规定格式回复，应为：“1东海县山左口乡”
灌云圩丰镇无震感	未按规定格式回复，应为：“1灌云县丰镇”
通州区石港镇1	未按规定格式回复，应为：“1通州区石港镇”
1，南通外向型农业综合开发区(如东)	不符合回复规范，应有区县名、乡镇名

下载: 导出CSV 

| 显示表格

针对上述现象，我们对系统的功能及管理进行了优化：

（1）要求每个乡镇或街道至少有1名灾情速报员，针对连云港市的情况，从系统中删除责任心不强的灾情速报员，精简人员，避免某个点的灾情速报员上报信息堆叠导致无法查看。

（2）对系统架构进行优化，收发短信的后台增加分组收发功能，避免短信拥塞现象。

（3）及时总结出现次数较多的错误，由市局传达给区县用户，对灾情速报员进行二次培训。同时不断改进技术手段，通过地名库匹配与在线查询相结合的方式提高系统容错率。

目前，系统运转良好，能够正常收发短信及对上报信息进行数据处理，对地震应急工作有序、高效地开展有较好的帮助。

5.   结语

地震灾情收集是开展地震应急救援工作的基础。本系统利用传统的手机短信和即时互通、流媒体内容共享的微信企业号服务2种手段，实现地震应急灾情的快速采集，基本满足震后较短时间内开展地震应急工作的需求。虽然技术系统仍有待完善，但管理方面的推进更加重要，只有同时做好技术保障和管理服务，才能最大程度地发挥12322平台的作用，最终为防震减灾事业做出应有的贡献。