政府应急预案管理系统

1 概述

1.1 项目背景

近年来，我国一些自然灾害、安全生产、环境污染等事件频频发生。如2008年的特大冰雪灾害、汶川地震灾害，2010年的玉树地震灾害、舟曲泥石流灾害、王家岭煤矿透水事故及三鹿奶粉事件、瓮安群体性事件，都给人民群众生命财产安全带来了巨大的损失和严重的威胁。每一次事件的发生都牵动着党中央、国务院和全国各族人民的心，有些事件甚至引起国际的广泛关注。成功应对突发事件，就会把一场灾难，转化为一次机遇，更加凝聚人心；如果应对失误，就会酿成更大的灾难，就会丢失民心，失去民意。应对突发事件的能力和绩效，已经成为考验政府公共管理水平和行政能力的重要标志。同时，加强应急管理信息化建设是加快应急管理队伍建设，提高应急管理工作水平和应急处置能力，有效预防事故发生，减少和控制事故扩大的重要手段。

1.2 项目目标

根据政府的紧急事件的处置机制，建设一套辅助政府应急预案管理的信息系统，系统遵照危机管理理论，平战结合，平时进行应急预案的编制、管理和完善；在突发事件发生时，快速检索和匹配预案，指导工作人员完成应急响应的协调、联络和监督等工作；在突发事件处置完成后，及时进行善后处理及对事件进行评估并对预案进行修正，从而不断完善和提升政府应对公共事件处理的能力，为政府应对突发公共事件提供重要信息保障。

第1页 共40页

2 系统功能需求

系统功能结构图

2.1 预案模版管理

预案模版是编制应急预案的基础，相当于应急预案的提纲和目录。系统根据不同预案类型对预案模版进行管理，也可以根据事件类型对预案模版进行管理；管理内容包括模版基本信息以及模版的目录结构、目录类型，在预案编制时编制人员选择相应的预案模版，系统自动对预案模版和预案索引进行绑定，编制人员就可以根据模版大纲编制预案内容，管理功能包括对预案模版的基本信息和目录结构类型进行添加、修改、删除、修改等管理。

第2页 共40页

2.1.1 预案模版基本信息管理

定义预案模版的各项基本信息，包括名称、版本号、编制单位、编制时间和使用说明等。模版基本信息是模版在模版库中的唯一信息，包括模版编号和模版版本号，在预案编制时通过预案基本条件检索匹配到预案模版，从而根据模版索引检索到模版目录。

2.1.2 预案模版编制管理

预案模版各项内容的增加、修改和删除，包括模版的各层次级别目录树、目录项的类型（如文本、列表

第3页 共40页

等）等功能。预案模版编制管理是对模版的目录结构、层次级别顺序以及类型的定义，在模版基本信息创建后模版本身是没有模版目录，需要编制人员根据预案需要进行定义，可以按预案类型或者事件类型进行模版定义，选择模版索引后系统跳转到模版目录定义界面，编制人员在界面中定义不同的目录名称、目录顺序以及目录类型，定义完成后提交到系统后台，系统根据定义把目录索引和模版索引进行绑定并保存到模版库中形成完整的预案模版。

2.1.3 预案模版基础数据配置管理

包括预案模版的分类管理和目录类型管理。 系统在交付使用时，已内置了一些常用的类型和目录。在未来的系统使用过程中，用户可利用此项功能，自行灵活定义各种不同类型的预案和预案目录，以适应不同预案编制的需要。预案模版基础数据配置是预案模版目录的重要组成部份，基础数据主要是包括应急资源、成员单位及职责、应急专家、应急救援队伍等需要数字化格式化的内容输入目录，所有的目录都有相应的索引，在预案模版定义时选择相应的基础目录信息跟预案模版索引进行绑定，这样所有基础目录通过索引绑定形成各种结构的预案模版。

预案分类管理：

目录类型管理：

第4页 共40页

2.2 预案编制管理

系统根据应急预案中的要素信息，提供结构化的应急预案信息、响应事件、应急资源配置、处置程序等信息要素的输入和变更等界面功能，并能按照用户工作习惯方式友好地回显预案内容。

用户在编制数字预案时选择预案模版，按照向导提示编制，也可以参照某项预案进行修改编制。系统支持数字预案保存、修改、删除功能。

应急预案制作还包括电子地图方案制作接口，通过该接口可在电子地图上进行定位、标注和文字的编写，进行编辑和布置应急预案的人力和资源安排。

用户可以上传和下载与编制预案相关的附件，编辑简要说明。系统自动记录上传和下载的时间。

第5页 共40页

2.2.1 预案基本信息管理

应急预案的基本属性，包括编号、名称、版本、类型、编制部门、编制人和使用说明等。预案基本信息是预案在系统中唯一信息，包括预案编码、预案版本号，在预案编制时通过条件检索到预案并进入编制工作，在突发事件应急处置时通过事件名称、事故类型等条件到预案基本信息库中检索匹配所需要的预案启动进行应急处置工作，编制人员在创建预案基本信息时在创建界面输入基本信息相关项提交到系统后台，后台获取操作人员提交的基本信息并自动分配预案索引保存到预案基本信息库中，同时操作人员也可以对预案基本信息进行修改、删除等操作，系统根据操作人员选择的预案索引对数据库中的基本信息进行相关项的更新和删除操作。

第6页 共40页

2.2.2 预案编制管理

根据预案模版的目录结构，逐项填写相应的预案内容。系统支持所见即所得的编辑方式，即在界面上编辑文字的各种格式，未来文本输出时可原样输出。

预案编制是编制人员在创建了预案基本信息之后对预案内容进行填写的功能，编制人员在内容编制时选择需要编制的预案，系统跳转到编制界面并从预案模版库中提取系统中所有已经编制好的预案模版，编制人员选择预案模版，系统后台获取预案索引以及预案模版索引到数据库中提取该模版的所有目录信息（目录顺序、目录结构、目录类型），后台再对提取的目录索引跟预案索引进行绑定并保存到预案库中同时展示到系统前台，预案目录就已经产生，编制人员根据目录对预案内容进行编制并保存到预案库中，预案在编制的过程中不同的内容就会要用到不同的目录模版，这也是预案模版预案已经定义好的，比如预案编制依据、目的等内容一般都是文字性描述，文字性内容填写到文本编辑中；比如组织成员单位及职责、应急人员、应急专家等相关内容在应急处置时是需要从预案库中进行提成，数字格式化的内容在预案编制时需要进行数字化格式化录入，以方便在预案启动进行应急处置时系统能快速提取。

文本录入：

列表录入：

第7页 共40页

2.2.3 预案预览及导出

在编制过程中，可随时通过预览功能，查看预案编制的基本情况。也可以通过导出功能，获得该预案的word文档。预案预览及导出功能是系统根据用户需要生成一份和预案文本文件同样格式的预案，系统根据操作人员选择的预案索引到预案库中进行数据检索，对符合索引条件的预案信息进行提取并提交给系统后台按照预案目录先后顺序层次结构进行处理生成网页文件和word文档，最终展示在系统界面中供用户进行查看阅读或者导出到操作人员所指定的位置。

第8页 共40页

2.2.4 预案发布管理

预案编制完成后，通过预案发布功能使预案正式投入使用，同时系统也对预案进行锁定不能进行修改及修订工作，未经发布的预案，在应急事件处置中不能使用，操作人员可以正常的对预案内容进行修改修订工作。预案发布时操作人员选择需要发布的预案进行发布，系统根据预案索引到预案库中进行数据检索并对符合索引条件的预案状态进行锁定，操作人员不能再对预案进行相应的修改修订工作，同时也代表该预案已经编制完成，在突发事件应急处置时可以匹配并可以启动已经发布的预案进行事件应急处置工作。

2.2.5 预案任务库管理

任务是处置突发事件的各项具体行动或措施，有的任务相互间还具有先后顺序或逻辑关系。任务信息管理实现了任务内容、任务责任单位和责任人、任务所需资源、任务执行步骤、任务执行标准等信息进行管理，提供了预案任务配置及任务信息录入和任务岗位、资源配置等功能，支持预案-任务的关联关系查询和检索。

任务责任矩阵可以明确各项任务主体的责任关系和职责，明确责任者、协作者、配合者、支持者的任务分工。系统提供的功能可使用户设置每项任务的相关方及其责任类型和职责内容，并可按责任矩阵的形式展现给操作者。

任务资源矩阵可以明确各项任务所需的资源类型、数量等内容。用户可使用系统提供的功能设置每项任务的资源，并可按资源矩阵的形式展现给操作者。

对各成员单位的任务进行统一的管理，在预案编制过程中从任务库里选择成员单位的任务进行关联。

第9页 共40页

2.3 预案启动管理

2.3.1 预案检索匹配向导

突发事件发生后，可通过预案检索匹配向导功能，方便快捷地查询相关预案，找到最为合适的预案并启动执行。

向导的主要过程包括：预案快速检索、地图定位、预案级别研判和预案启动等过程。

第10页 共40页

2.3.2 预案地图定位

可通过预案地图定位功能，在地图上标注突发事件的发生地点并把地理位置坐标信息保存到数据库中，也可以通过地图强大的查询功能查询事发地点周边不同距离范围内的基本情况，包括应急救援力量、危险源和脆弱设施等信息通过图标和列表二种方式展示给指挥人员，以便指挥人员以及其他应急人员在处置突发事件时了解事发地相关信息，有利于掌握并合理、科学的对事件进行处置，尽可能的减少人员伤亡、财产损失。

2.3.3 预案快速检索

可通过下拉列表模式，快速检索预案。 ? 下拉列表模式：

下拉列表主要是检索预案的标题信息，输入关键字后，系统根据关键字到数据库中检索预案库，对符合条件的预案通过下拉列表弹出，快速显示匹配到的预案，选择下拉列表的内容后，可直接进入该预案。

第11页 共40页

2.3.4 预案级别研判

预案级别研判在突发事件时根据指挥人员选择的预案，系统根据预案索引自动检索数据库中预案响应级别，把符合条件的响应级别信息在系统中进行展示供指挥人员根据事件情况进行级别研判，同时系统也根据响应级别启动预案，把预案中预置成员单位级职责、相关救援队伍、专家、应急人员信息检索展示出来进行应急处置。

2.3.5 预案上报流程

可随时查看事件上报流程以及上报领导、联系电话等信息。

事件上报流程查阅是系统根据当前突发事件所启动的应急预案响应级别而从突发事件上报流程库中匹

第12页 共40页

配到相应级别的上报流程。

上报流程的每个环节都有上报单位以及岗位，系统根据上报单位以及岗位到数据库中找到上报人的姓名、联系电话、单位电话、值班电话等信息，如数据库中有多上报人联系信息则一一查询并展示到上报流程中。

2.3.6 预案启动

突发事件时根据事件类型和等级等条件自动搜索预案库并启动，将该预案相关信息展示给指挥人员和应急处置人员。系统提供二种方式启动应急预案，分别以导航式启动和自动匹配方式启动预案。 导航式启动预案分为三步：

预案检索：系统根据指挥人员输入的关键字自动到预案库中检索到符合条件预案，如检索到多个预案时需要指挥人员选择相应的预案；

预案级别研判：指挥人员根据突发事件情况参照预案中的响应级别条件选择响应级别。 上报流程：系统根据指挥人员选择的预案以及预案响应级别从数据库中检索到符合条件的上报流程以及流程中所关联到的上报单位、上报人、联系方式。 自动匹配启动预案：

自动匹配式启动预案是系统根据管理人员前期预置的匹配条件、匹配指标数据，在突发事件时根据指挥人员输入的突发事件类型、事故人员、人员伤亡、财产损失等情况自动检索数据库中预案及响应级别启动预案。

第13页 共40页

2.4 应急处置管理

2.4.1 应急处置预案生成

应急处置预案生成根据当前系统所启动的预案从预案库中以及资源配置库中提取应急处置要素，预案要素包括突发事件报案信息、事件基本信息、事件上报流程图、成员单位及职责、应急通讯录、专家资源、救援队伍、事件处置进展以及下一步相关措施等内容。

事件报案信息、事件基本信息和上报流程图内容是根据事件名称、事件类型以及响应级别综合条件从事件库以及流程库检索提取。

成员单位及职责、应急通讯录、专家资源、救援队伍是根据当前突发事匹配启动预案索引到资源配置库中进行检索提取。

第14页 共40页

第15页 共40页

2.4.2 事件基本信息管理

突发事件录入包括报案人基本信息的录入和突发事件本身基本信息的录入。 报案人基本信息包括报案人姓名、单位、报案时间、报案电话，报案内容。

突发事件的各种基本信息管理，包括事件的名称、类型、级别、描述、伤亡情况、财产损失情况等。输入事发地址后系统根据中文地址快速在地图上定位，电子地图切换到事件地点。事故原因、人员伤亡情况以及财产损失情况填写项系统提供快速填写模版以方便填写人员快速填写，节约填写时间。

2.4.3 成员单位及职责

预案启动后，预置的各种成员单位及职责将自动通过短信的方式分发到各个成员单位负责人。成员单位职责分发后，同时系统也会自动记录职责分发时间以及详细职责，指挥人员可以通过系统提供的短信等方式，

第16页 共40页

督促提醒成员单位负责人。

成员单位接到任务后，应根据行动的进度，及时上报任务状态信息，状态包括已接收、已出发、已到位、已控制和已完成等，在指挥中心就能够非常清楚的看到各成员单位的情况，便于进一步的行动部署。

作为成员单位的任务信息的上报手段可以有多种，如通过手机短信的特殊编码实时上报信息等，技术手段的完善和管理制度的约束，确保任务执行的实时信息能够及时地反馈到指挥中心。

2.4.4 应急通讯录查阅检索

在突发事件应急处置时预案启动后，预案中预置的所有应急人员信息从数据库中检索出来，指挥人员可以利用系统中提供的短信以及电话等自动或人工的方式联系通知应急人员前往事发地点以及在事件处置过程中所需要负责的任务及职责。同时系统会对指挥人员通知应急人员的时间以及应急处置任务等其它指示指令信息进行自动和手工记录，也对应急人员在现场及处置过程中反馈的信息进行记录，给指挥人员在应急处置过程中能合理有效的进行指挥。

第17页 共40页

2.4.5 专家资源信息查阅检索

在突发事件应急处置时预案启动后，预案中预置的所有专家资源信息从数据库中检索出来，指挥人员可以利用系统中提供的短信以及电话等自动或人工的方式通知专家前往事发地点以及在事件处置过程中所需要负责的任务及其它信息，为行动争取更多的时间，减少更少的损失。

系统会对指挥人员通知专家人员的时间以及应急处置任务等其它指示指令信息进行自动和手工记录，同时也对专家在现场及处置过程中反馈的信息进行记录，给指挥人员在应急处置过程中能合理、高效的进行指挥，在事件总结起到评估作用。

2.4.6 救援队伍信息查阅检索

在突发事件应急处置时预案启动后，预案中预置的所有应急救援队伍从数据库中检索出来并显示在系统界面上，包括队伍名称，负责人、联系电话、值班电话，队伍人员数据以及队伍介绍信息，指挥人员可以利用系统中的功能通过短信以及电话等方式自动或人工的方式通知队伍负责人员前往突发事件事发地址以及在事件处置过程中所需要负责的救援任务及其它信息，为行动争取更多的时间，减少更少的损失。

系统会对指挥人员通知救援队伍负责人的时间以及救援任务等其它指示指令信息进行自动和手工记录，同时也对救援队伍相关人员在现场及救援过程中反馈的信息进行记录，给指挥人员在应急处置过程中能合理、高效的进行指挥，同时也为救援赢得更多的时间。

第18页 共40页

2.4.7 预案文本信息查阅检索

系统提供不同方式查看阅读预案信息，主要包括格式化和文本化查看二种，供系统使用人员可随时调阅该预案的文本内容，系统根据当前应急处置时所启动的应急预案从数据库中调出生成当前所属预案的文本内容，和原来文本同样格式，方便习惯看文本文字预案人员进行查看阅读。

第19页 共40页

2.4.8 事件上报流程查阅

可随时查看事件上报流程以及上报领导、联系电话等信息。

事件上报流程查阅是系统根据当突发事件所启动的应急预案响应级别而从突发事件上报流程库中匹配到相应级别的上报流程。

上报流程的每个环节都有指定的上报单位以及岗位，系统根据上报单位以及岗位到数据库中找到上报人的姓名、联系电话、单位电话、值班电话等信息，如数据库中有多个上报人联系信息则全部查询并展示到上报流程中。

2.4.9 事故处置总结填写

指挥人员对事故的处置过程、处置情况、处置结果进行详细的记录。

2.4.10 事故处置报告生成

应急响应过程中，提供软件工具和手段对相关应急预案执行过程进行全程跟踪监控，并记录执行过程中下达的指令的执行反馈信息，支持事后回朔和总结。具体包括对预案启动处理、预案升级处理、事件关闭处理、执行过程记录、生成执行报告，实现以下功能：

突发事件时启动相应预案，分类显示任务列表和应急资源。

记录预案和任务执行过程中的指令和反馈信息，并可随时调整任务和资源。 根据现场情况进行预案升级。

启动应急预案后，对联动单位执行情况进行监控。

事件处理完毕后关闭预案，对事故的报案人、基本信息、处置过程、处置结果生成事件报告并提供打印。

第20页 共40页

2.4.11 预案关闭

事件处置完毕后关闭相应的预案。

第21页 共40页

2.5 资源配置管理

应急资源包括应急处置装备和物资，是应对突发事件的重要保障。完善的应急资源管理，是提高应急管理综合水平的关键。

应急资源管理是对应急资源的基本信息、位置信息和非结构化信息进行分类管理。基本信息是为了更方便检索，位置信息是为了直观展现应急资源的地理位置，非结构化信息是为了包含更多结构化信息所没有包含的信息。

应急资源管理除了对应急资源的属性信息进行管理外，还对应急资源的使用过程进行管理。在预案等业务流程进行处理过程中，也会对应急资源的状态、位置、数量等属性进行操作，如应急资源的部署和撤回等。

应急资源的监控管理主要是对应急资源状态和位置进行管理，使得指挥人员能够准确地知道应急资源的分布情况和使用情况。

系统提供方便的应急资源查询功能，通过电子地图接口，操作者可以很方便地从信息系统和电子地图两个层面查询应急资源的相关信息。

应急资源的合理调配体现在三个方面：

第一是应急资源与预案的关联：在预案中根据不同任务调用不同的应急资源进行处理，它提出了需要哪些应急资源，需要多少。这就要求应急资源要和预案和预案任务进行关联，确保在预案启动的时候能够快速的取得应急资源的需求列表，减少差错和遗漏，为行动赢得时间。

第二是基于电子地图的应急资源检索和分配：根据需求列表，调度人员可以本着就近的原则调取相应的应急资源，提高响应速度。

第三是应急资源的使用和信息的反馈：应急资源在使用过程中状态会不断地发生变化，

第22页 共40页

随着任务的进程，应急资源使用情况被不断的上报到指挥中心，指挥中心能够依据应急资源信息的反馈情况及时调整和补充应急资源，确保应急资源的充分合理地使用。

应急预案中的相关应急资源的管理，包括应急单位、应急队伍、应急岗位、危险源、应急人员、应急车辆、应急物资和应急资料等等。

2.6 系统管理 2.6.1 用户管理

系统登录用户的信息和密码等内容的管理。

第23页 共40页

2.6.2 部门管理

政府相关部分的组织结构管理。

2.6.3 角色管理

系统中的角色管理。一个用户可以有多个角色，一个角色可以有多个权限，角色将权限累加到用户。

第24页 共40页

2.6.4 权限管理

系统用户可操作的系统功能。

2.6.5 栏目管理

系统界面右侧的功能目录树的层级管理。

第25页 共40页

第26页 共40页

3 系统设计

3.1 设计原则

为确保项目建设目标的实现，遵循如下的建设原则：

? 规范性：系统的设计遵循国家安全应急管理体系的业务架构和与之配套的应急管理信息系统架构，

系统的开发、上线和后期维护，遵循相应的系统集成和软件工程的技术规范。

? 开放性：系统接口在遵循规范性原则的基础上，可以集成不同设备厂商、系统或平台供应商、软

件供应商的产品。

? 先进性：引入国际先进的安全生产和应急管理的理念，采用成熟先进的技术、产品和管理手段，

以保障系统符合国际的标准和规范，具有高效、全面和稳定的特性。

? 安全性：充分考虑整个系统运行的安全策略和机制，可以根据不同的业务要求和应用处理，设置

不同的安全措施。

? 扩展性：系统必须提供标准的和开放的应用接口及丰富的开发工具，以便集成现有的和将来的生

产和管理系统，实现对投资的保护，防止重复建设。

? 简单实用有效：系统是面向安全生产和应急管理的，在操作上应力求简单实用，高效便捷，同时，

针对管理人员级别的不同，提供的功能也有所侧重和差别。 ? 总体规划，分步实施的原则。

第27页 共40页

3.2 系统总体架构

? 网络通讯层

整个系统的底层是信息系统的基础设施，这包括计算机网络及通讯设施、主机服务器及存储系统、视频监控系统、视频会议系统、大屏幕数据演示系统，以及操作系统、数据库管理系统及网络通讯基础设施等，这些是系统最基本的运行基础。 ? 信息资源层

数据是整个系统的基础，基础数据经过采集、处理、标准化、传输、存储，形成系统资源库，为系统提供了高效的业务分析、决策、交换、共享的数据环境。

应急指挥需要多部门、多系统联动配合，如果彼此孤立，不能实现信息共享，就会形成的“信息孤岛”。造成缺乏可比数据、缺乏分析、缺乏管理。难以获得全面的业务信息，就会影响业务和决策的效率和准确性。通过提供应用整合服务、业务整合服务、数据整合服务连接相关职能部门的系统、业务、数据，最大程度的解决信息孤岛，最大限度地利用现有的数据资源。 ? 应用支撑层

应用支撑层的设计直接影响系统的稳定性、安全性及可靠性等重要因素，南京雅信科技集团有限公司凭借多年的软件开发经验，采用基于SOA的低耦合，高内聚的设计思想，基于开放的标准在该层部署应用部件，为系统高效、可靠的运行提供保障。 ? 应用层

应用层围绕事件的生命周期，从隐患、发生、发展、消除和善后处理等进行全过程管理，功能包括值班管理、预案管理、资源管理等。 ? 综合门户

综合门户系统建立了一个灵活、规范的信息组织管理平台和全网范围的网络协作环境，实现集成的信息采集、内容管理、信息搜索，能够直接组织各类共享信息和内部业务基础信息，面向不同使用对象，通过门

第28页 共40页

户技术实现个性化服务，从而实现初步的信息整合；门户不同的用户提供个性化、服务，实现用户的统一认证、统一管理，提供实时信息访问及多系统协同工作。

3.3 基于SOA的体系架构 3.3.1 SOA架构介绍

面向服务的体系结构（service-oriented architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。

对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需（On demand）业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。

3.3.2 SOA与应急管理系统

作为应急预案流程处理，势必会涉及到跨组织跨地域的多单位多部门的协同工作，不同的单位在拥有诸多构建在不同技术元素的业务系统的现状下，要实现跨越系统的流程集成，要以什么作为首要的选择依据呢 ？

答案是“标准”和“架构”，IT技术发展到今天，再没有什么比面向服务的架构(Service Oriented Architecture，简称SOA)更加合适去作为这样的解决方案了，通过借助BPM对SOA计算模型中BPEL标准的实例化和做相应拓展，应急预案流程完全能够实现业务流程的跨系统集成。

第29页 共40页

3.3.3 SOA架构的优势

? 围绕服务而不是应用来组织企业IT ， SOA 提供了如下关键的好处：. 提高业务和IT 的生产效率、

敏捷性和速度 ... 与有经验的SOA 提供商进行合作还有一个好处，企业可以获得对构造组件、企业域（ domains ）、服务和规范数据模型的参考经验。

? 它可以将IT架构抽象出来，而把IT系统实现的功能以服务形式表示出来，每种服务都清晰地表现

出其业务价值，这些服务的顾客（既可能在公司内部，也可能是公司的某个业务伙伴或供应商）就可以得到这些服务，而不必考虑其后台的具体实现技术。

? SOA的出现改变了人们编写应用软件的方式，它要求开发人员将应用设计为服务的集合，并充分考

虑现有服务的重用以及如何让新开发出的服务能被其他项目重用。“单独的”、“独立的”、“封装完善的”服务所具有的一个关键好处是可以采用多种不同的方法重新组合它们以形成新的应用。 ? 应用开发上的好处：编码灵活性 可基于模块化的低层服务，采用不同组合方式创建高层服务，从

而实现重用。此外，由于服务使用者不直接访问服务提供者，因此服务实现方式本身也是灵活的。 ? 明确开发人员角色 可以充分发挥开发人员的长处，提高开发效率。例如，熟悉BES的开发人

员可以集中精力在重用访问层上；协调层开发人员则无须特别了解BES的实现，而是把精力放在解决高价值的业务问题上。

? 支持多种客户类型 借助精确定义的服务接口和对XML、Web服务标准的支持，SOA可以支持

多种客户类型，包括PDA、手机等新型访问渠道。

第30页 共40页

? 更易维护 服务提供者和服务使用者的松散耦合关系及开放标准的采用使得系统的维护变得更

容易。

? 更好的伸缩性 依靠服务设计、开发和部署所采用的架构模型实现伸缩性，服务提供者可以彼此

独立地进行调整以满足服务需求。

SOA带来管理上的优点：管理员可以直接管理开发人员所构建的相同的服务，这远胜于以往管理单个应用的方式，通过分析服务间的交互，SOA可以帮助企业了解何时以及为什么业务逻辑被切实执行了，这使管理员或分析师能够有针对性地优化业务流程。

3.4 系统功能框架

3.4.1 网络通讯层

整个系统的底层是信息系统的基础设施，这包括网络及通讯设施、主机服务器及存储系统、视频会议系统、大屏幕数据演示系统，以及操作系统、数据库管理系统及网络通讯基础设施等，这些是系统最基本的运行基础。

第31页 共40页

3.4.2 信息资源层

数据是整个系统的基础，基础数据经过采集、处理、标准化、传输、存储，形成系统资源库，为系统提供了高效的业务分析、决策、交换、共享的数据环境。

应急指挥需要多部门、多系统联动配合，如果彼此孤立，不能实现信息共享，就会形成的“信息孤岛”。造成缺乏可比数据、缺乏分析、缺乏管理。难以获得全面的业务信息，就会影响业务和决策的效率和准确性。通过提供应用整合服务、业务整合服务、数据整合服务连接相关职能部门的系统、业务、数据，最大程度的解决信息孤岛，最大限度地利用现有的数据资源。

3.4.3 应用支撑层

应用支撑层的设计直接影响系统的稳定性、安全性及可靠性等重要因素，正邦高科凭借多年的软件开发经验，采用基于SOA的低耦合，高内聚的设计思想，基于开放的标准在该层部署应用部件，为系统高效、可靠的运行提供保障。

3.4.4 应用层

应用层结合应急指挥中心的实际情况以及项目设定的目标，通过预案编制、预案管理、资源管理、事件管理、预案执行管理、统计分析和GIS定位等功能，来完成通州区应急指挥中心预案管理系统的建设。

3.4.5 综合门户

综合门户系统建立了一个灵活、规范的信息组织管理平台和全网范围的网络协作环境，实现集成的信息采集、内容管理、信息搜索，能够直接组织各类共享信息和内部业务基础信息，面向不同使用对象，通过门户技术实现个性化服务，从而实现初步的信息整合；门户不同的用户提供个性化、服务，实现用户的统一认证、统一管理，提供实时信息访问及多系统协同工作。

第32页 共40页

3.5 系统网络架构

3.5.1 应急值守

应急值守是指应急预案管理的日常工作，包括预案编制、查询和应急资源维护等功能。应急值守人员通过PC访问Web服务器，登录系统并使用相应系统功能。此部分功能为本期项目重点实现的功能。

客户端采用PC并通过局域网与服务器连接，通过IE浏览器访问系统。由于系统集成了百度地图功能，因此，要求客户端电脑能够访问百度地图网站。

3.5.2 应急指挥

应急指挥是指突发事件发生后，启动相应的预案，指挥调度各种资源，完成相应的应急响应工作，包括事件管理、预案启动、预案执行和预案关闭等功能。应急指挥人员通过PC访问Web服务器，登录系统并使用相应系统功能。此部分功能为本期项目试用的功能。

客户端采用PC并通过局域网与服务器连接，通过IE浏览器访问系统。由于系统集成了百度地图功能，因此，要求客户端电脑能够访问百度地图网站。

3.5.3 应急处置

应急处置是指应急响应的联动人员，通过手机客户端和短信等方式，从指挥中心获取各种事件信息和应急任务信息，并将任务执行的情况，通过手机及时反馈给应急指挥中心。此部分功能是未来系统功能扩展的方向之一。

客户端应采用智能手机（安卓、IOS或WP7等）并开通GPRS/3G网络功能，通过手机上安装的客户端

第33页 共40页

软件与服务器进行通信。

3.5.4 Web服务器/数据库服务器

Web服务器是主要用于系统应用程序的部署。用户通过浏览器访问Web服务器，Web服务器根据用户的请求，访问数据库服务器，获取相应的信息后，形成网页并反馈给用户。

系统硬件配置：建议采用两台独立的服务器分别作为Web服务器和数据库服务器，未来随着用户数的增加和业务复杂程度的提高，可采用更多的服务器来分摊系统的压力。由于预案管理系统的短信模块需要通过Internet发送短信，所以，Web服务器需要有Internet的访问权限。这也是将Web服务器和数据库服务器分离的一个原因，避免数据库服务器直接暴露在外网，造成数据不安全。

系统软件配置：数据库管理软件方面建议系统采用Oracle 11g数据库，可为系统提供更高性能的数据管理功能。若用户考虑成本问题，本系统也可采用MySQL5等开源的数据库软件。系统操作软件方面建议采用Linux 5.4企业版操作系统，更为稳定，更少的病毒威胁。Web应用服务器软件方面建议采用免费的开源系统。

3.5.5 短消息网关

短消息是指手机短信。系统支持短信网关集中发送短信的功能，一般用于通知和提醒。短信网关的实现方式采用与短信服务商合作，申请专用的短信号码和短信通道，如106XXXXX，系统通过调用短信服务商的短信发送服务端口，向短信服务商提交短信发送的内容和接收者，由短信服务提供商将短信发出。

短信功能模块安装在Web服务器上。未来随着新的业务功能的增加（如手机功能）和安全性要求的提升，可增加单独的外网应用网关，将短信模块部署到应用网关。

3.5.6 其他应用系统接口

应用系统可预留接口，未来与其他内部办公系统（如OA系统等）进行对接。 接口方式可采用API或Web Service等多种方式。

3.6 应用系统架构

3.6.1 基于B/S的应用系统架构

本方案采用B/S三层体系结构来构架整个系统。由三部分组成：客户机、应用服务器、数据库服务器。客户机上只需要安装浏览器，它负责处理与用户的交互和应用服务器的交互。应用服务器负责处理业务逻辑，具体地说就是接受客户机方应用程序的请求，然后根据业务逻辑将这个请求转化为数据库请求后与数据库服务器交互，并将与数据库服务器交互的结果传送给客户机方的应用程序。数据库服务器软件根据应用服务器发送的请求进行数据库操作，并将操作的结果传送给应用服务器。

B/S三层结构有许多内在的优点： 逻辑界限清晰。中间层允许用户把全部业务逻辑从另外的两个层中移到中间层的一个功能模块中定义实现，这样各层之间相对独立使得其中某一层的改变不影响到其他层。因而，当用户需求发生变化的时候，开发人员可以很容易地控制变更的范围，从而达到及时快速修改的目的。

第34页 共40页

三层体系结构架构的系统也有利于资源的优化。由于一个系统功能被分为三个部分，因此可以根据各层负载情况，可升级以相应的硬件平台来满足不断增加的负载需求，使得系统具有良好的可扩展性。

三层结构与传统的客户端—服务端结构相比，我们可以在开发过程中在Client，Web Application Server，DB Server间均衡的分布应用负担，如在DB Server中使用触发器，存储过程简化页面查询负担，在Web Application Server中充分利用中间件相关技术，以编译的执行方式代替脚本的解释执行方式提高了存取速度。在客户端应用一定量的客户端脚本如提交校验，对话框预览等降低了服务器的负担。

由用户表现层向业务逻辑层发出请求，然后业务逻辑层决定使用哪个数据源来满足其请求。通过使用相同的调用接口，商业逻辑层就可以对任何可用的数据源访问。

增强和提高信息的安全性。访问特权可以指定或内置于二个层次的每一个层次中，以便提供二个级别的安全性。

3.6.2 基于Java的Spring程序框架

Spring 是一个开源框架，是为了解决企业应用程序开发复杂性而创建的。框架的主要优势之一就是其分层架构，分层架构允许您选择使用哪一个组件，同时为 J2EE 应用程序开发提供集成的框架。

Spring 框架是一个分层架构，由 7 个定义良好的模块组成。Spring 模块构建在核心容器之上，核心容器定义了创建、配置和管理 bean 的方式，如图所示。

组成 Spring 框架的每个模块（或组件）都可以单独存在，或者与其他一个或多个模块联合实现。每个模块的功能如下：

1) 核心容器

核心容器提供 Spring 框架的基本功能。核心容器的主要组件是 BeanFactory，它是工厂模式的实现。BeanFactory 使用控制反转 （IOC） 模式将应用程序的配置和依赖性规范与实际的应用程序代码分开。

2) Spring 上下文

Spring 上下文是一个配置文件，向 Spring 框架提供上下文信息。Spring 上下文包括企业服务，例如 JNDI、EJB、电子邮件、国际化、校验和调度功能。

3) Spring AOP

通过配置管理特性，Spring AOP 模块直接将面向方面的编程功能集成到了 Spring 框架中。所以，可以很容易地使 Spring 框架管理的任何对象支持 AOP。Spring AOP 模块为基于 Spring 的应用程序中的对象

第35页 共40页

提供了事务管理服务。通过使用 Spring AOP，不用依赖 EJB 组件，就可以将声明性事务管理集成到应用程序中。

4) Spring DAO

JDBC DAO 抽象层提供了有意义的异常层次结构，可用该结构来管理异常处理和不同数据库供应商抛出的错误消息。异常层次结构简化了错误处理，并且极大地降低了需要编写的异常代码数量（例如打开和关闭连接）。Spring DAO 的面向 JDBC 的异常遵从通用的 DAO 异常层次结构。

5) Spring ORM

Spring 框架插入了若干个 ORM 框架，从而提供了 ORM 的对象关系工具，其中包括 JDO、Hibernate 和 iBatis SQL Map。所有这些都遵从 Spring 的通用事务和 DAO 异常层次结构。

6) Spring Web 模块

Web 上下文模块建立在应用程序上下文模块之上，为基于 Web 的应用程序提供了上下文。所以，Spring 框架支持与 Jakarta Struts 的集成。Web 模块还简化了处理多部分请求以及将请求参数绑定到域对象的工作。

7) Spring MVC 框架

MVC 框架是一个全功能的构建 Web 应用程序的 MVC 实现。通过策略接口，MVC 框架变成为高度可配置的，MVC 容纳了大量视图技术，其中包括 JSP、Velocity、Tiles、iText 和 POI。

Spring 框架的功能可以用在任何 J2EE 服务器中，大多数功能也适用于不受管理的环境。Spring 的核心要点是：支持不绑定到特定 J2EE 服务的可重用业务和数据访问对象。毫无疑问，这样的对象可以在不同 J2EE 环境 （Web 或 EJB）、独立应用程序、测试环境之间重用。

第36页 共40页

3.6.3 系统主要实体关系图

从图中可以看出系统主要实体之间的关系。

应急预案是系统的核心，应急预案的制定来自于应急预案模版，包括静态信息和应急任务，静态信息管理用于预案的文档管理和内容检索，应急任务用于突发事件的处置和管理。

应急任务与应急资源关联，通过任务调度应急车辆、应急物资和应急队伍等应急资源，而应急任务本身的责任单位，也通过应急单位赋予。

当突发事件发生时，会与应急预案进行关联，同时记录应急预案的处置过程，相应的资源调度过程，也会进行记录。

系统用户通过权限管理，对系统的不通实体拥有不通的操作权限。应急任务的接受者，也是应急系统的一个用户，拥有对应急任务的操作权限，用于查阅任务和任务反馈。

第37页 共40页

3.6.4 系统数据结构

根据实体关系可以进行系统数据库结构的设计。

系统的实体关系与数据库的详细设计，将在项目进行过程中，根据具体需求而进行调整和设计，最终以《系统设计说明书》的形式提交给用户。

3.6.5 系统开发环境

1) 系统开发语言（JDK）：Java 1.6 2) 集成开发环境：MyEclipse 5.1.1 GA 3) 应用服务器：Tomcat 6.0 4) 数据库管理软件：Mysql5 5) 文档管理：WinCVS 2.0

3.7 数据备份

系统数据丢失不仅会导致系统文件、数据库文件等相关数据的丢失，而且会使整个企业的业务瘫痪，造成不堪设想的后果。因此，有效的保护现有数据，使得系统稳定运行显得尤为重要。当人为因素（如：误操

第38页 共40页

作）、硬件故障及其它不可预见因素造成数据丢失、系统瘫痪发生时，保证及时有效的恢复系统和数据，使系统得以正常运转，将损失减小到最低，则是关心的问题。

解决上述问题最为根本的的办法就是数据备份。因此，数据备份已成为信息系统中不可或缺的重要组成部分。所以若想对数据进行可靠的备份，必须选择专门的备份软、硬件，并制定相应的备份及恢复方案。 根据系统数据备份需要专门附带一个外部数据备份存储设备，定期(每周五晚上十二点)对数据库数据进行热备份，数据在存储设备上存储时间为三十天，并定期对数据存储空间进行检查，以确保存储设备空间能满足数据备份需要。

3.8 系统接口 3.8.1 对外提供接口

本系统通过Web Service的方式对外提供接口，调用方通过SOAP协议将包含用户/密码/请求信息等特定结构和内容的XML信息发送到接口服务器，接口服务器解析并验证用户身份后，根据请求信息进行相应的数据库操作，并将结果以特定结构的XML反馈给调用方。

对外可提供的接口视具体需求而定，主要包括：预案查询和资源查询等。

3.8.2 外部接口调用

本系统可通过API和Web Service等方式调用其他系统提供的功能接口，获取其他系统的数据信息。 对外部接口调用视具体需求而定，主要包括：视频信息、电子政务信息、110指挥中心报警信息、气象预报信息等等。

3.9 系统安全 3.9.1 系统部署位置

由于系统的客户端和Web服务器需要访问Internet，所以，系统应部署在政府的外网网络中。 目前暂不需要与政务内网进行直接的信息交换，如果未来需要直接交换数据，则需要增加物理隔离的安全设备（如安全网闸），在保证安全的情况下进行互联互通。

3.9.2 防火墙安全策略

由于Web服务器需要与Internet连接，因此，需要在Web服务器与外网之间增加防火墙设备，以保证系统安全。

Web服务器和数据库服务器应添加到防火墙的DMZ区进行保护，既需要防止外网的非法攻击和入侵，又需要方式内网用户的非法访问。

Web服务器开放Internet访问权限，但可限制只访问特定的域名或IP地址以及特定的端口。Internet访

第39页 共40页

问Web服务器，则可完全禁止。

数据库服务器禁止所有的外网访问和访问外网。

3.9.3 用户访问安全

目前系统采用用户名/密码的方式进行用户身份校验。

未来如果对内部用户有更高的安全级别要求，可采用硬件加密的方式（如USB KEY盘）进行用户身份的认证。项目实施

第40页 共40页

本文来源：https://www.bwwdw.com/article/jjup.html