0 引言

宁波市科技局（地震局）承担政府抗震救灾指挥部办公室的职能，在整个政府应急体系中起着运行枢纽及业务支撑作用，责任大，任务重，事项多。合署办公的机构性质及全局动员的应急体制，又决定了该局地震应急组织体系与其常态不一致，且参与人员多，活动范围大。开发建设一套方便实用的协同工作系统，以辅助支持全局系统的应急工作，可以有效提高整体的地震应急处置效率。

目前，国内尚没有适用于市县地震应急的协同工作系统，相关软件仅适用于灾情调查、震情发布、现场工作、应急响应等相关方面。如张翼等（2014）开发的基于PDA的四川灾情速报系统，刘钦等（2015）开发的12322地震灾情速报处理系统，贾宁（2016）开发的地震灾情信息上报系统，适用于灾情调查统计工作，利用这些系统，分布在各地的防震减灾助理员将收集到的灾情信息通过网络传送至后端系统，并通过实时筛选、统计后，提供查询、展示服务，为相关部门决策提供及时、有效的灾情信息服务。叶佳宁等（2014）开发的地震信息微信自动发布系统，夏仕安等（2013）开发的基于Android智能手机的震情信息发布平台，适用于震情发布工作，通过EQIM数据库获取地震三要素，再通过微信、短信等方式发布到指定用户，提高了社会公众的震情知情权。武汉地震工程研究院有限公司等开发的地震现场灾情调查与指挥调度系统，马一夫（2015）等开发的地震现场烈度调查信息服务系统，适用于现场震害评估工作。该系统由移动终端、通信网络和指挥中心等3部分组成，参加某次地震事件应急现场工作的人员，可以通过系统开展信息采集、震害评估、烈度发布等一系列业务工作及人员调度、实时沟通、资料查询等辅助工作。浙江省地震局开发的微信版地震应急预案分派系统，适用于地震应急响应启动阶段，包括应急通知发布、人员签到、职责推送等功能。上述软件不适合于市县地震部门的应急工作，但其相关设计与实现却为市县地震应急协同工作系统的开发提供了参考。

企业微信（腾讯，2016）是腾讯公司于2016年4月推出的基础办公沟通工具，主要适用于企业或组织与内部员工、上下游合作伙伴建立连接，并相对快速、低成本地实现高质量的移动轻应用。它拥有一些基础办公功能，还提供了强大的2次开发接口。基于企业微信开发地震应急协同工作系统具有以下3个方面的优势：①机动灵活。既可以在PC端使用，也可以在智能手机等终端使用，文件传输无缝对接，自动同步，符合地震应急工作机动的特性；②成本相对低廉。企业微信跨平台，无须开发多个版本，部分通用功能可以直接利用平台提供的原生功能或在此基础上开发；③便于推广。既可以独立安装企业微信APP，也可以通过微信关注“微工作台”后使用，后者拥有与微信同样的操作界面，易学易用，方便在不同需求的人群中推广。

本文在借鉴相关软件功能的基础上，从市县地震部门地震应急处置工作实际出发，基于企业微信，设计并实现了包括震情服务、灾情服务、应急服务、工作报告、资料查询、通知公告、实时沟通等7个方面功能的地震应急工作助手软件，为市县地震部门地震应急信息沟通、资料查询、流程办理等提供了统一平台。

1 需求分析

通过分析宁波市科技局（地震局）系统地震应急的参与群体、关键业务、主要流程及工作要求，确定地震应急工作助手软件的功能需求。

1.1 组织体系及个人信息查询服务

系统能够以目录树的形式显示局系统地震应急的组织架构，该架构包括指挥部、工作组、人员等3层（图 1），并显示个人信息、通信信息及应急职责信息。可以根据需要，对组织架构层次、信息、组成及人员信息进行增加、删除、修改、查询等操作。

1.2 震情相关信息推送查询服务

地震发生后，系统可以自动接收震情信息，并实时向全体人员推送，推送的内容包括发震时间、地点、震源深度、震级等，展示方式为图文信息列表与地图定位2种形式。应急过程中，根据震情研究进展，可以按需上传有关此次地震的构造分析、趋势判断、余震统计等资料，相关人员可以按需查询。全体人员能够实时接收震情信息，并按需通过关键字进行搜索或查询。

1.3 应急响应启动支持服务

地震发生后，系统需要支持以下应急响应过程：①管理员通过系统向全体人员推送启动应急响应通知，内容包括地震信息及响应级别；②全体人员通过系统签到，表明是否能够到岗应急；③系统实时统计并显示应急人员到岗情况；④系统根据人员到岗情况及事先确定的A、B岗设置方案，自动完成应急人员编组；⑤根据编组情况，向每位应急人员推送对应的应急职责。应急启动后，若再有应急人员零星到岗，系统会自动触发岗位安排程序，对相应的A、B岗人员进行调整，并推送做过相应调整的职责信息。

1.4 灾情采集统计及查询服务

地震发生后，全体人员可以通过手机、平板电脑等终端上报当地灾情信息，该信息包括位置信息及人员死亡、人员受伤、人员埋压被困、房屋损毁、崩塌、滑坡、道路拥堵中断、火灾、危险品泄漏等9类灾害发生情况以及其他信息，信息载体包括照片、音视频及文字描述等（表 1）；系统实时分地域、时间段2种方式进行统计，并通过标题列表及地图定位2种形式展示灾情信息；也可以由系统管理员手动统计后通过图文列表展示。全体人员可以通过关键字查询灾情原始报告及各类统计信息。

1.5 工作报告撰写及流转服务

地震应急期间，市局指挥部各工作组需要定期撰写各类工作报告并在全体应急人员之间交流。系统需要设定各类工作模板，辅助起草人员撰写报告，并支持报告从组员撰写、组长审核（包括审核通过、退回修改等状态）到内部发布的流转过程。相关人员可以通过关键字查询发布的各类报告。

1.6 应急资料上传查询服务

地震应急前后，系统管理员在后台上传文件请示、预案方案、新闻通稿等3个方面的资料，全体应急人员可以在前端进行查阅、下载，具体包括关键字查询、图文信息查阅及word格式导出等。

1.7 通知发送服务

地震应急期间，相关应急人员可以通过系统向相关工作组或任意群体人员发送包括图片、文字、视频、音频、定位等类型的通知信息。

1.8 实时沟通服务

全体应急人员两两之间，可以任意沟通、交流；任意人员可以申请组成群组并交流。

2 概要设计 2.1 系统架构设计

系统采用B/S结构的软件体系，服务器采用Windows Server2008 R2系统、ASP.NET MVC开发环境、SQL server2008 R2数据库平台建设部署。Browser前端采用html5整合企业微信API功能。系统基于4层架构搭建，数据层直接对数据库进行增、删、改、查操作；网络层主要负责构建数据模型，映射、调用数据层；应用层包括业务逻辑和数据传输对象；用户层人机交互界面用来承载Web页面控件，生成Web应用程序。系统架构如图 2所示。

2.2 系统功能设计

系统分为企业微信系统和后台管理系统2部分。企业微信系统作为前端，主要作用是用户交互、页面结构及功能呈现，主要使用对象为全体用户，包括市局指挥部应急人员、区（县）市指挥部联络员及防震减灾助理员。后台管理系统作为后端，主要作用是支撑、辅助、保障系统功能实现，包括基础数据录入、算法支撑及系统审计、系统设置等，主要使用对象为系统管理员。

2.2.1 企业微信系统

企业微信端以企业微信APP为基础，分成7个模块（图 3）。其中，第1、7、8项需求可以直接使用通信录、通知公告企业微信的2项原生功能，这里不再详述。其他5项需求需要使用企业微信API自行开发。

（1）震情服务模块。该模块主要功能是推送最新震情，提供震情及相关信息查询，包括最新地震、震情目录、专题信息、震情设置4个子模块：①最新地震。实时接收最新发生地震的震情信息，以地震三要素为标题，定位地图为图标。点击标题可显示详细内容，包括发震时间、地点、震级、震源深度及震中位置在地图中的展现；②震情目录。以目录形式，列出设定时间段，设定地域、震级范围内的震情信息，分为标题列表、地图定位2种形式。其中，标题列表按照时间倒序排列，可根据关键字进行查询。地图定位按照震中位置显示，点击后可显示详细信息；③专题信息。以标题列表形式，按照时间倒序列出与指定地震事件相关的构造背景、趋势判断等信息。点击可以显示完整信息内容，包括文字及图片，并可以word格式导出。标题可以根据关键字进行查询。上述信息通过后台系统上传；④震情设置。提供上述第1、2项震情信息的时间段、地域、震级范围设定，以及夜间的免打扰设置，仅管理员有此权限。

（2）应急服务模块。该模块主要功能是支持应急响应启动过程，从应急通知接收，到签到反馈，再到岗位安排、职责推送，直至应急工作组编组完成。包括应急通知、到岗统计、人员编组、我的职责4个子模块：①应急通知。实时接收系统管理员通过后台推送的应急响应通知，该通知包括地震事件名称（地震三要素）及启动的响应级别。通知附有“签到”按钮，成员可以根据实际情况进行签到；②到岗统计。实时显示全体应急人员的签到情况，包括签到人员和未签到人员统计；③人员编组。显示各个工作组中承担各个应急岗位的人员，由系统根据到岗人员及事先设定的A、B岗和岗位替换方案确定人员编组；④我的职责。显示根据人员编组情况，向每位成员推送的对应应急岗位说明书，该说明书包括在本次地震应急响应中的岗位、职责及分时段应急任务。

（3）灾情服务模块。该模块为全体应急人员提供灾情获取、报送、统计、展示服务，包括灾情急报、急报查询、灾情统计3个子模块：①灾情急报。灾情录入、报送页面同表 1的灾情信息模板，应急人员按照模板填报后，可以选择暂存，也可以选择报送；②急报查询。提供逐条查询急报信息的页面，分标题列表及地图展示2种形式。前者默认以报送位置+灾情作为标题，后者通过地图中的圆点表示灾情所在位置，点击某条或某点，均可显示上述详细信息。标题列表还可以根据关键字进行查询；③灾情统计。提供地域统计、时间轴统计、人工统计3种形式的实时统计结果。地域统计即按区（县）市及乡镇进行统计；时间轴统计即按照地震发生后的0.5 h、1.0 h、2.0 h、2.0 h、4.0 h、8.0 h、8.0 h、8.0 h、24 h的时间间隔进行统计；人工统计即管理员根据灾情急报按照一定的侧重点统计后，手动编辑生成。

（4）工作报告模块。该模块为各工作组提供工作报告上传、审核、查询、下载、导出服务，包括工作报告、我的报告、报告查询等3个子模块：①工作报告。提供报告模板，选择模板类型，按模板填报内容后，可以选择暂存和提交。暂存为存于本地终端，提交为上传至后台，并出现在接收人报告列表中；②我的报告。有“我发送”和“我收到”2个模块，“我发送”模块为该用户（起草人）暂存或提交的报告。“我收到”模块为该用户（审核人）接收到的报告。报告按照时间顺序以标题列表形式排列，包括标题、起草人、提交时间、状态、是否可编辑等5类信息。依据报告起草、审核流程，状态信息分为暂存、未审核、通过审核、退回（后3种为提交后的状态）等。点击某条报告，可显示详细信息。提供根据关键字进行查询的服务；③报告查询。提供经过接收人审核的报告查询服务。按照时间顺序以标题列表形式排列，点击某条可显示详细信息。提供根据关键字的查询服务。提供报告的word文件导出功能。

（5）资料查询模块。该模块分文件请示、预案方案、新闻通稿3个子模块，可分别提供这3类资料的查询、查阅、下载、导出服务。按照上传时间先后以标题列表的形式排列，点击可显示详细信息。提供根据关键字的查询服务。

2.2.2 后台管理系统

后台管理系统分为4个模块，见图 4。

（1）企业微信模块。该模块为企业微信官方后台与企业后台的对接模块。其中，企业微信设置子模块用于与企业后台对接的企业号基本信息设置。企业微信应用子模块、企业微信部门子模块、企业微信成员子模块分别用于企业微信官方后台与企业后台在应用、部门、成员上的同步，以使得企业后台能够控制企业微信前端。

（2）管理中心模块。该模块为企业后台的管理模块。其中，组织机构子模块用于管理后台系统的部门、岗位、成员。应用管理模块用于后台系统应用的基本信息管理及启用状态设置。任务调度子模块用于管理、调度后台管理的各项任务。系统审计子模块用于显示登录、操作、接口、错误等各项系统日志。

（3）地震应急模块。该模块主要功能是支撑前端应急签到、职责推送、工作报告、灾情报告统计等应急功能的实现。应急通知子模块用于推送应急响应通知。应急岗位子模块用于管理市局系统所有的应急岗位，包括所属组别、名称、职责及岗位说明书。岗位安排子模块用于管理每个应急岗位的A、B岗人员，即每个应急岗位对应的A、B岗人员的常态岗位。灾情急报子模块用于管理所有人员上传的灾情急报信息；工作报告子模块用于管理所有人员上传的工作报告。

（4）内容管理模块。该模块用于支撑前端查询类栏目的增加、编辑、删除及查询操作。其中，栏目管理子模块用于管理栏目，目前查询类栏目包括监测信息、预案方案、文件请示、新闻通稿等。内容管理子模块用于管理各栏目下的图文信息。配置管理子模块用于配置内容的审核及查看权限。

2.3 系统数据库设计

根据系统自身的业务逻辑及系统各功能模块之间的相互关系和数据信息建立数据库。数据库包括3类数据表，第1类用于前端企业微信系统管理，以WX作为前缀，包括用户、标签、素材、信息等各类表；第2类用于后台系统管理，以HT作为前缀，包括用户、登陆、日志、应用等各类表；第3类用于支撑自建业务应用，以EQ作为前缀，共8张表。因篇幅所限，只详述第3类表，表名及关键字段见表 2。

3 详细设计与实现

按照概要设计，下面介绍震情服务、应急服务、灾情服务、工作报告等4个关键模块的详细设计方案及其关键环节的实现。

3.1 震情服务

最新的震情信息来自浙江省EQIM震情信息交换与共享服务系统。该系统不支持与地震应急工作助手直接通讯，而是将震情信息推送到专业服务器上的震情数据库中。因此，本系统通过定时任务计划访问震情数据库，获取到地震数据后，根据设定的条件去过滤地震信息，符合条件的信息存入震情数据同步表。然后，通过调用企业微信的“消息推送”功能发送图文信息。具体流程见图 5。图 6显示的为实现效果。地震定位图片首先通过经度与纬度信息在高德在线地图上标注，然后截图保存到本地后，显示静态图片。点击后，跳转至URL所示的地址。震情目录数据来源于本地服务器的“震情数据同步表”，在企业微信端通过文字列表和在线地图 2种模式显示。地图模式，主要通过调用高德地图API，显示震情设置范围内的震中分布图。地图以中国地图为中心，可任意放大、缩小。地图调用circleMaker方法，通过经纬度值在地图中绘制震中。点击某点的震中，通过建立并调用getDetail(item.Id)函数，显示详细信息。详细信息页面打开后，与最新震情的内容及格式一致，包括图文信息。专题信息在后台通过内容管理模块添加专题文章，企业微信端读取专题信息并展示。过滤的条件通过震情设置页面由管理员进行设定。有效范围以当前位置为中心，设定的千米数为半径，筛选圆内地震进行发送，震源深度、震级都是根据设置要求发送的最小值。由于地震目录较多，在地图及列表模式显示震情目录时可以设置条数。夜间免打扰模式开启时，会在指定时间段内静默发送，可以设置静默的时间段。以上数据使用DTO模式传输，在保存数据前使用ViewBag判断是否为管理员账户，以防未经授权的修改。通过基于httpclient的post方法，读取表单数据，存入用户警报设置表。

3.2 应急服务

应急通知子模块在企业微信通知公告应用基础上开发，实现较为简单，这里不再展开叙述。到岗统计子模块在企业微信的签到应用基础上开发，用户点击签到后，相关信息写入“用户签到表”，客户端实时读取表中数据并显示。

应急岗位安排分成2个过程，首先，应急启动期结束后（发送应急公告半小时之后）的集中安排（注：预案要求应急人员半小时内响应），具体流程见图 7。系统首先从“应急岗位表”中读取首个岗位，再从“用户签到表”中读取对应人员的到岗信息，对应A岗人员已签到的，由该人员承担该岗位；否则，由对应B岗人员承担该岗位。如果对应A岗、B岗均未签到的，则无人承担，出现暂时空缺。随后，读取第2个岗位，如此循环，直到所有岗位都读取完毕。安排结束后，将岗位安排写入“到岗信息表”，并输出到“到岗信息”页面，同时推送每个人的应急职责到“我的职责”页面。之后签到1个，安排1个。有人员签到即触发后续岗位安排程序，具体流程见图 8。首先，审验是否有对应A岗，如果有，再审验对应B岗人员是否已签到，如果已签到，则B岗卸任，该人员承担，同时更新对应A岗的到岗信息，并推送该人员及与该人员互为A、B岗人员的职责信息；如果未签到，则直接承担，同时更新对应A岗、对应B岗的到岗信息，同时更新该人员的职责信息。如果没有对应A岗，则审核是否有对应B岗，如果有，则审核作为A岗承担该应急岗位的人员是否已签到，如果已签，则无需该人员承担应急岗位，并发送提醒信息；如果未签到，则该人员以B岗身份承担该应急岗位，同时更新应急B岗到岗信息，并重新推送该人员的职责信息。如此循环，直到所有人员都到岗为止。实现效果见图 9。

3.3 灾情服务

灾情服务应用的流程见图 10。灾情急报首先选择地震事件，每次灾情统计都是针对最新的地震事件。地理位置信息由手机等终端自动获取；如不准确，可以手动选择。灾情报告的标题由系统自动生成，默认为具体位置名称加上“灾情”。灾情类型为表 1中所示9项，报送时，勾选相应类型，并填报数量即可，详细描述项填报具体的文字说明。在实现上，表单设计选用企业微信提供的资源“WeUI for Work”，地理位置选择使用微信提供的位置信息API。设计灾情报告表用于逐条存储急报信息。在急报查询页面读取表中数据，并在客户端通过标题列表和地图定位2种方式展示。灾情统计应用利用手动、地域、时间轴3种形式统计上报的灾情。手动统计由管理员根据各地报告的灾情信息，按照相应时间间隔，在线下手动统计，生成灾情简报，并上传至后台，由客户端读取后台数据并显示。地域统计通过逐条读取灾情报告表中的数据，判断行政区域值Area，分类进行累加后存入本地服务器数据库，最后通过view类进行显示。时间轴统计也是通过逐条读取灾情报告表中的数据，将发震时间作为时间轴起点StartTime，再按照设定时间间隔通过AddHours进行筛选，每条事件item都需要通过时间核验才能出现在对应的时间轴中，时间轴中显示的是灾情的发生地点及其详细描述，按照报送时间先后排列。实现效果见图 11。

3.4 工作报告

根据各个应急工作组的职能，研究确定监测信息、现场信息、值守信息、综合信息等4类专用报告的内容提纲及固定格式，并将其固定为模板。再另加一类“其他报告”，不预设内容提纲和固定格式，将其作为不可预计类报告的模板。每类模板通过企业微信提供的资源“WeUI for Work”建立前端表单。通过建立ReportTypeId类，区别报告类型。用户选择报告类型后，显示相应类型的表单框架。数据填报后，再基于HTTP的post方法，向指定的url提交数据。最后，通过function(data)函数，判断是否提交了有效的数据。如果是，则暂存或提交；否则，则提示“提交失败”及错误的数据表项。最终报告存入工作报告表。报告内容由模板与数据2部分组成，模板以文件形式存在，读取数据填入模板文件相应位置，即为最终的信息。文件内容可以通过word格式导出，方便进一步编辑。在实现上，通过建立FileResult类，将存在服务器上的文件模板及数据组合后发送给客户端。通过判断ReportTypeId值，确定报告类型，对应载入相应的模板。与数据合并后, 保存到文档流中，最后使用Response.BinaryWrite输出该文件。我的报告中“我发送”及“我接收”页面内容，通过工作报告表中的添加人（CreateUserId）及审核人（PermissionUserId）信息予以区分。全部报告通过IsPermission值确定状态，其中，0为未审核，1为已审核，2为审核不通过，3为暂存。报告查询页面内为已审核通过（IsPermission为1）的报告。实现效果见图 12。

4 结束语

地震应急工作助手软件系统从市县地震部门工作实际出发，能够满足地震应急处置全流程关键环节、通用业务的使用需求，包括破坏性地震发生初期的震情快速发布、灾情报告统计；应急响应启动期间的应急通知发布、人员签到统计、工作组编组、职责任务推送；应急处置期间的工作报告审核交流、资料上传查询、人员实时沟通；应急结束后的通知发布、人员签退、资料归档等等，可以起到有效支持部门应急处置工作的作用。多次地震应急演练使用实践也表明，该系统能在较大程度上提高地震应急处置效率及规范化程度。但目前系统是第1版，在功能设计及实现细节上仍存在一些问题和不足，较突出的有以下2方面：一是易用性有待提高，没有提供帮助文档及使用示例，对用户使用过程中产生错误的提示较笼统、含糊，无法帮助用户正确理解；二是部分功能细节有待完善，如资料归档仅考虑了按地震事件分类，未考虑工作报告按工作组分类、灾情报告按地域分类等更加完善的做法；再如，出于保密考虑，对市局应急人员、区（县）市联络员及防震减灾助理员的使用权限划分有待于进一步细化、完善。以上问题需要在后续版本中改进提高。